+1 on creating test cases.
What I had in mind the last few days: Move the whole p-u rewrite back to o.a.maven.utils under maven-shared. Then create a plexus-shim which just 1:1 subclasses their counterparts in maven.utils. As next step we can remove all plexus-utils and replace them with maven-utils again. All other libs will get the shim layer until they get updated. The plexus-utils shim might contain some compat code. LieGrue, strub --- On Sun, 8/14/11, Stephen Connolly <[email protected]> wrote: > From: Stephen Connolly <[email protected]> > Subject: Re: [DISCUSS] plexus-utils rewrite > To: "Maven Developers List" <[email protected]> > Date: Sunday, August 14, 2011, 10:07 PM > I still think that we need good test > coverage on any code that we > bring over though, so we can move towards the eventual goal > of > removing p-u entirely... otherwise all we are really doing > is building > a p-u clone @maven... and maven's focus should not be a p-u > clone, the > commons project should be able to host most of that > functionality. > > On 14 August 2011 23:02, Benson Margulies <[email protected]> > wrote: > > +1: I believe I found a few authored by current PMC > members and did the same > > thing. > > > > On Sun, Aug 14, 2011 at 2:42 PM, Mark Struberg <[email protected]> > wrote: > > > >> Heh, I now learned that a few are even almost 1:1 > copies from our own > >> maven-1 utils ;) > >> > >> Please compare the PathUtils from plexus-utils to > >> http://maven.apache.org/maven-1.x/xref/org/apache/maven/util/DVSLPathTool.html > >> > >> The only difference (beside 2 1-line bugfixes) are > 2 new methods which > >> Vincent Siveton (Maven PMC member) added. > >> > >> @Vince: Is it ok for you to just take this (the > latest revision before the > >> license change) and commit it into our sandbox > project [1]? txs! > >> > >> LieGrue, > >> strub > >> > >> [1] > >> https://svn.apache.org/repos/asf/maven/sandbox/trunk/plexus-utils-commons-bridge > >> > >> --- On Sun, 8/14/11, Stephen Connolly <[email protected]> > >> wrote: > >> > >> > From: Stephen Connolly <[email protected]> > >> > Subject: Re: [DISCUSS] plexus-utils rewrite > >> > To: "Maven Developers List" <[email protected]> > >> > Date: Sunday, August 14, 2011, 6:31 PM > >> > +1 > >> > > >> > - Stephen > >> > > >> > --- > >> > Sent from my Android phone, so random > spelling mistakes, > >> > random nonsense > >> > words and other nonsense are a direct result > of using swype > >> > to type on the > >> > screen > >> > On 14 Aug 2011 19:18, "Mark Struberg" <[email protected]> > >> > wrote: > >> > > Hi folks! > >> > > > >> > > I'm now grabbing deeper and deeper and > also browsed a > >> > lot of the > >> > plexus-utils svn history recently. And the > more I dig > >> > deeper, the more I'm > >> > seriously considering pulling over a few > sources 1:1. > >> > > > >> > > Quite a few of the plexus-utils classes > originally > >> > have been plain 1:1 > >> > forks from other Apache Software Foundation > projects. > >> > Namely: Ant, Avalon > >> > and Velocity. > >> > > Most of those sources until recently > even had the > >> > > "Copyright {year} The Apache Software > Foundation." > >> > header. > >> > > In most of the files only the last > commit changed this > >> > to > >> > > "Copyright The Codehaus Foundation." > >> > > > >> > > Imo this is just plain wrong, because > those sources > >> > (again: not _all_ > >> > plexus-utils classe, but quite a few!) are > definitly (C) > >> > ASF. > >> > > I wont go into details here, but I think > it's fairly > >> > safe that we just > >> > take those sources over to our new sandbox > project 1:1 and > >> > only need to > >> > rewrite the classes which are _not_ mainly > sources by an > >> > ASF project. > >> > > > >> > > wdyt? > >> > > > >> > > LieGrue, > >> > > strub > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > --------------------------------------------------------------------- > >> > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
