Consider the challenge of moving from import wildcards that we made a few years ago.
A common practice used to allow this package declaration at the top of a class:
import com.this.that.*;
The above import statement works, but it now we do the following, which has always been a bit harder to maintain. We do it because it is helpful.
import com.this.that.MyClass;
import com.this.that.YourClass;
import com.this.that.HisClass;
import com.this.that.HerClass;
It is now easier to do this with Eclipse, but even when it wasn't, we still went through the effort to avoid potential confusion.
But in the case of classpaths, we are still at the wildcard stage, as evidenced by this easy to do classpath declaration from our current build.
<fileset dir="${deploy.server.path}/lib">
<include name="*.jar"/>
</fileset>
If you look in this directory, there are 65 jars in that directory !!!!!! Wow. Or at least there are, in a default deploy...
All you gotta do is plop a bunch of jars in that lib directory, you don't even have to have the foggiest idea of what jar does what. You can even plop two jars that compete with each other and cross your fingers, and with any luck, it will still work.
Now consider the more tedious affair of using Maven.
In case you haven't actually Mavenized a project, this is a total PITA. No random plopping of jars into a lib directory. You actually have to think, and there is a dis-incentive for getting jars that you may not need, as it takes some time for each jar. Please note that each jar must be versioned, and each jar must be placed in the maven repository, either the keelframework.org/maven repository, or the local one, or the ibiblio.org/maven repostitory.
<fileset dir="${MAVEN_HOME}/repository">
<include name="keel/jars/keel-core-2.0ea1.jar"/>
<include name="keel/jars/keel-server-2.0ea1.jar"/>
<include name="avalon-framework/jars/avalon-framework-4.1.4.jar"/>
<include name="commons-beanutils/jars/commons-beanutils-1.6.jar"/>
<include name="commons-collections/jars/commons-collections-2.1.jar"/>
<include name="commons-lang/jars/commons-lang-1.0.1.jar"/>
<include name="commons-logging/jars/commons-logging-1.0.3.jar"/>
<include name="regexp/jars/regexp-1.2.jar"/>
<include name="patternmachine/jars/patternmachine-0.5-dev.jar"/>
<include name="metasync/jars/metasync-0.5-dev.jar"/>
</fileset>
Imagine the tedious affair of making this 65 lines long, complete with the placement of all the jars there, the careful versioning of each, and choice between versions where using externally provided jars. Yeouch! That is easily a day's worth of work, if not more.
Much easier to plop a bunch of jars in a lib directory and be done with it !
CONCLUSION:
Lots more work in the setup/transition phase. No solution is offered for this PITA.
On the other hand, it does provide a lot more benefits, just as there are benefits to not using the wildcard in import declarations. The question is, can we get over this rather labor intensive hump?
I have a start at placing the jars in keelframework.org/maven. Let me know if there are others that you need to place there. Adam, Shash, and Michael also have write permissions to that folder.
http://keelframework.org/documentation Keelgroup mailing list [EMAIL PROTECTED] http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
