Where's the branch that you're using for testing? I have a few questions but I'll look at the branch first.
On Oct 18, 2012, at 2:11 PM, Kristian Rosenvold <[email protected]> wrote: > 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] >> >> Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha
