Stephen, Some of these classes and methods don't fit into commons very well, or force us to get embroiled in some of the more baroque areas of commons (e.g. commons-vfs). My personal experience (very small) has been that it's not easy to sell new stuff to 'commons-xxx'. I'm all in favor of tests, and I also think that it's a worthwhile goal to sweep code back to Apache when there's no particular reason for it to be at codehaus. Perhaps a two-step process: get a complete set of functionality back into Apache, and then haggle with commons-pmc about unloading more of it onto them?
--benson On Sun, Aug 14, 2011 at 6:07 PM, Stephen Connolly < [email protected]> wrote: > 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] > >
