blob: 0e035b7a0a908194535ea44a586954a62ec56b35 [file] [log] [blame]
------
Introduction
------
Kristian Rosenvold
------
2013-07-24
------
~~ Licensed to the Apache Software Foundation (ASF) under one
~~ or more contributor license agreements. See the NOTICE file
~~ distributed with this work for additional information
~~ regarding copyright ownership. The ASF licenses this file
~~ to you under the Apache License, Version 2.0 (the
~~ "License"); you may not use this file except in compliance
~~ with the License. You may obtain a copy of the License at
~~
~~ http://www.apache.org/licenses/LICENSE-2.0
~~
~~ Unless required by applicable law or agreed to in writing,
~~ software distributed under the License is distributed on an
~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
~~ KIND, either express or implied. See the License for the
~~ specific language governing permissions and limitations
~~ under the License.
~~ NOTE: For help with the syntax of this file, see:
~~ http://maven.apache.org/doxia/references/apt-format.html
${project.name}
This project aims to be a functional replacement for
{{{http://codehaus-plexus.github.io/plexus-utils/}plexus-utils}} in Maven.
It is not a 100% API compatible replacement though but a replacement <with improvements>:
lots of methods got cleaned up, generics got added and we dropped a lot of unused code.
Then there are additions, like
{{{./apidocs/org/apache/maven/shared/utils/logging/package-summary.html}styled message API}}.
Why?
plexus-utils consisted mostly of code that was forked from various apache projects.
maven-shared-utils is based on the original from the Apache sources.
Why not commons?
We would prefer code to use commons-* code where appropriate, but the plexus-utils became
slightly incompatible (different) from the commons over the years, so migrating is not
always a 1:1 operation. Migrating to maven-shared-utils is a 1:1 operation in most cases.
Relation to Commons-*
maven-shared-utils internally use {{{http://commons.apache.org/io/}commons-io}}. We shade all commons
classes into our own private package to prevent classpath clashes.
This is the reason why any public API in maven-shared-utils must
avoid to expose commons-io classes directly. Most times it's sufficient
to just create an empty subclass and expose that instead.
[]