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]
>
>

Reply via email to