Rewrite Plexus Utils classes at the ASF from scratch

After talking with Stefan Bodewig (which shows up as @author in lots of the sources) and other commons guys I found out that a good part of the plexus-utils sources originally did came from ant. They then got pulled over to Avalon and plexus took them either from there or directly from Ant.

I thought it was largely delegating to commons? In most cases, they also have the same ancestry but have been improved more significantly since.

Yes, there are classes which are currently in Ant and in commons and mostly maintained by the same committers.

What I wanted to make clear is that quite a lot of the plexus-utils project is just a copy (+singular modifications) of ASF internal projects. So there is not much IP issue with those classes.

I think it is important to avoid forking anything, unless we expect to maintain it going forward. In the case of this class, it might be better to bridge to commons-exec: http://svn.apache.org/viewvc/commons/proper/exec/trunk/src/main/java/org/apache/commons/exec/OS.java?revision=672325&view=markup, or Ant itself (we can use shade to reduce the impact of the dependency tree).

The problem with Os.java is that plexus-utils got forked off a very old version of ant. The Ant version has much improved yet and got the fields made private, etc. So it's not really easy to just bridge.

If possible, then we should use commons projects and bridge over to them. I'll try to look at the Os.java from commons.

My main 'aha-effect' was that most of the plexus-utils classes are only wrongly declared (C) The Codehaus. This really got only very lately replaced the original '(c) Apache Software Foundation' as most classes are forks from:

• Ant
• commons
• Velocity
• Anakia
• maven-utils-1.x

And as such it's legally and also politically no problem to just take the sources back to the ASF SVN and we are not forced to rewrite everything from scratch without looking at the original sources.

edit: I'm not blaming Codehaus for anything, they just provided the hosting and have nothing to do with changing the license headers.

right, if there are originals in the ASF SVN we can certainly copy that across (probably with history) - but I'm suggesting it should be an exceptional case. I don't think Maven wants to take on maintaining any of this code unless we've exhausted any other options.

Are there any other cases at the moment that are copied / rewritten instead of bridged to existing code?

I think I've touched 5 classes yet and 4 of them are clearly forked from ASF projects and still 90% of that code remaining.

Check this locations for obvious hits:

• http://maven.apache.org/maven-1.x/xref/org/apache/maven/util/
• http://svn.apache.org/repos/asf/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/
• http://svn.apache.org/repos/asf/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition/
• http://svn.apache.org/repos/asf/commons/proper/exec/trunk/src/main/java/org/apache/commons/exec/

Of coure, sometimes you also have to grab back into the CVS archive. A good indicator is the @author tag. Commons dropped that around 2004, but plexus-utils most times still have them. An example: All classes with @author Stefan Bodewig are most certainly 1:1 forks from Ant.

Hi Mark,

I have created a test for the SelectorUtils class.
I enclose the svn diff as requested.
Also enclosed as patch created in eclipse.

I agree
with the submitted patch.

Mike/Michael

patch applied, thanks James and Michael!