puh that's muddy. Actually the @since for the new package are all 0.1 now. We have no backward compat to bury with.
LieGrue, strub ----- Original Message ----- > From: Robert Scholte <[email protected]> > To: Maven Developers List <[email protected]> > Cc: > Sent: Sunday, October 21, 2012 6:45 PM > Subject: Re: status update maven-shared-utils > > We also need to do something with the @since-tags > I'm not sure if this doclettag only allows a numberic value, otherwise > I'd like to prefix it with plexus-utils. > > WDYT? > > Robert > > Op Thu, 18 Oct 2012 20:11:55 +0200 schreef Kristian Rosenvold > <[email protected]>: > >> All the plugin IT's pass with m-s-u trunk now, and I am finshed with > all >> the stuff I planned to do. >> >> I am well in progress on a replacement for Xpp3Dom. Initially we're > just >> looking at a compatible replacement >> in a different package that can be used as a replacement for 90-95% of the >> use cases. >> >> I think we should release "0.9" now or at least very soon, and > just give >> the Xpp3Dom stuff a couple of extra weeks and we can call that version 1.0 >> ;) >> >> Kristian >> >> >> 2012/10/15 Mark Struberg <[email protected]> >> >>> Guys, you rock! >>> >>> I also like to add my thanks to Stephen as he started the >>> plexus-utils-commons-bridge over in our sandbox. Without this work we > would >>> not have been able to do this so fast. Also a thanks to all guys who > helped >>> importing the stuff they wrote into this module. >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>> ----- Original Message ----- >>> > From: Kristian Rosenvold <[email protected]> >>> > To: Maven Developers List <[email protected]> >>> > Cc: >>> > Sent: Monday, October 15, 2012 8:37 AM >>> > Subject: Re: status update maven-shared-utils >>> > >>> > 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] >>> >> >>> >> >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
