Maven 1.x Ant Plugin

I decided to try to make a patch for this issue. It's going rather well. To be backwards compatible I have added new property called maven.ant.use.get.properties that triggers this new behaviour. If the property is set to 'true' the following changes takes place.

maven.ant.use.get.properties=false
(exactly how things work today)
----------------------------------
...
<target name="get-deps" unless="noget" depends="init">
<!-Proxy settings works only with a JDK 1.2 and higher.->

<setproxy>
</setproxy>
<get dest="${libdir}/commons-logging-1.0.4.jar" usetimestamp="true" ignoreerrors="true" src="http://localhost/maven/commons-logging/jars/commons-logging-1.0.4.jar">
</get>
... (more get lines here)
</target>
...

maven.ant.use.get.properties=true
(works as per Craig's request)
----------------------------------
...
<property file="build.properties">
</property>
...
<target name="get-deps" unless="noget" depends="init">
<!-Proxy settings works only with a JDK 1.2 and higher.->

<setproxy>
</setproxy>
<property name="commons-logging-1.0.4.jar" value="http://localhost/maven/commons-logging/jars/commons-logging-1.0.4.jar">
</property>
<get dest="${libdir}/commons-logging-1.0.4.jar" usetimestamp="true" ignoreerrors="true" src="${commons-logging-1.0.4.jar}">
</get>
... (more get lines here)
</target>
...

If this seems like something you would consider adding to the ant plugin, I'll write some documentation for the new property and then I'll send a patch for review.

This is what I have so far. The name of the property is of course open to debate.

Hi Dennis,

I'm sorry but I didn't see this issue. Thanks to help us.
As soon as you'll send us the patch, I'll review it and apply it.

I have just one question. Why do you define a property to switch between the 2 implementations ? I don't see why the new one will not be backward compatible with the new one ?

The addition of the lines
<property file="build.properties">
</property>
might break someone's build.

If the user already have a build.properties file there that contains properties with the exact same name as the ones generated by the ant plugin.

But do you think that it will very probable that it'll happen ?? I'm not sure that a lot of people will define properties like ${artifactId}-${release}.jar=XXXXX ??

Dennis, I'll wait for users' comments.
Actually I applied your patch but :

• I didn't integrated the property to switch between the 2 implementations.
• I renamed properties used to override the url ${artifactId}.jar as it was defined in struts, jakarta-commons and others.
• It is not yet documented, so I don't close the issue.

A/ To test the new plugin you must download/install it :
maven plugin:download
-Dmaven.repo.remote=http://cvs.apache.org/repository
-DgroupId=maven
-DartifactId=maven-ant-plugin
-Dversion=SNAPSHOT

B/ Recreate the ant script (maven ant) and define your dependencies in the build.properties like :
commons-pool.jar=${commons-pool.home}/commons-pool.jar
...
...

Craig, for the problem with clean target, I think that we can :
1) download jars in another directory like ${project.home}/dl_lib
2) add a target like clean-all which delete the target and the dl_lib directories.

The problem with this, will be if the user changes a library and doesn't call the clean-all target. He'll have the 2 jars in the classpath
Do you have another idea ?

Hi Craig,

What about MPANT-21 to fix the problem with the "clean" ? Will it solve your problem to simplify the build for jakarta-commons and others ??

Hi Arnaud

I think that it is very unlikely that someone will run into problems with clashing properties.

We could invert the configuration property so that it defaults to true. That way if someone do run into problems with clashing properties they could set the config property to false to get back the behaviour of the ant-plugin v 1.8.1. It all depends on what the users say. But if you ask me we might as well skip the config property (like you have done).

Regarding the names of the properties in the generated build.xml file I I have thought about it some more now, and I realize that my first choice of property-names was wrong. I imagined that one would have one build.properties file for all projects, but since the build.properties file will be in the directory of one project, it make sense not to include the version number in the property name.

Hi Dennis,

Ok, I'll add your property with by default the new behaviour. As you say, it will allow the user to deactivate it.
I'll rename your property "maven.ant.use.properties" because in a future we could imagine that it'll be possible to use the properties for something else. I also don't test this property to generate the "get" command. It is always the same with the use of an ant property. The difference is only to load or not build.properties files.

I think also that we can add <property file="$${user.home}/build.properties"/> as it is done in a lot of ant scripts (jakarta-commons, struts, ..). With that a user will be able to use the same libraires for several projects.

I uploaded the new SNAPSHOT.

Here is some documentation for the new property.

Thanks a lot Dennis. I waited for your opinion abaout my last comment before to document this feature.
I must also document the properties syntax to override default dependencies.
I'll try to do it tomorrow and I'll close this issue.

I have tried the current cvs HEAD, sorry svn trunk, of the this plugin back and forth now, with and without the new property, and it works as expected.

Ok it's cool. thanks for your help.

Applied. Thanks to Craig McClanahan for the idea, and to Dennis Lundberg for patchs.