I have been running m-s-u with the entire maven codebase loaded, basically analyzing all usages and deleting any code from m-s-u that is unused in maven. In a couple of cases I have also modified maven code to use commons code directly so we can avoid some code in m-s-u.
We discussed this on IRC and those of us present figured it would be a good idea to keep m-s-u at a minimum and *not* use this as a playground for adding all sorts of other nifty features we might feel like adding, both now and in the future. (I know this *sounds* so good, but it also sounds like wishful thinking ;) I also think it's desirable that m-s-u *NOT* support any use cases outside maven ;) I have in practice migrated "most" of the maven codebase to use m-s-u, and what remains is basically Xpp3Dom and its close "friends". (So while everything in org.codehaus.plexus.util.xml is deprecated, that's really only because we don't have Xpp3Dom yet) I only have a few things left before I'm "1.0" ready: A) Finish analyzing all the usages so I can trim m-s-u further down. We can always reinstate code if I delete too much ;) B) Make plugin it's run with m-s-u (decent progress has been made here, more or less finished) C) I am also considering just doing a clean reimplementation of Xpp3Dom and its companions, realistically it's not that many lines of code. Unsure if that is "1.0" material. Kristian 2012/10/14 Robert Scholte <[email protected]> > Hi, > > Mark, Kristian and I have made some good progress on the Maven Shared > Utils. > > The project has now 2 compile-scoped dependencies: commons-io-2.2 (final > 1.5 compatible version) and jsr305-2.0.1 (for the support of @Nonnull and > @Nullable) > Since we still think that Maven Shared Utils should not have any > dependencies, the commons-io is shaded. > > ReaderFactory and WriterFactory now return a Reader or Writer, the method > decides which implementation is used. Right now that is commons-io > > CollectionUtils has been removed, since there is a very small usage of it. > With generics this class has become useless. > > ExceptionUtils is nominated to be removed, since almost every Exception in > JDK5 can chain exceptions. For the few left we're looking if it is worth > to keep it here or let does project depend on the original plexus-utils > (different > package, so no class-collision) > > The whole org.apache.maven.shared.utils.**xml package is nominated to be > removed as well, since all its classes are deprecated. > > We're making heavy usage of generics, varArgs and other JDK5 specific > features. > > My opinion is that we need to remove all deprecated code, solve all TODO > comments before its first release.(the number of todo's is very small,6 in > main and 1 in test, and have either to do with method signatures or with > <=jdk1.4 issues.) > The reason is simple: with a new package this is the best moment to get > rid of some legacy code from the old plexus-utils which had to stay > backwards compatible. > > If you think there are other classes/methods which need to be discussed, > please let us know. > > > thanks, > > Robert > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > [email protected].**org<[email protected]> > For additional commands, e-mail: [email protected] > >
