|
History
| Log In
|
|
|
|
Hi Dennis,
I'm sorry but I didn't see this issue. Thanks to help us. 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 ? This is what I have so far. The name of the property is of course open to debate.
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 :
A/ To test the new plugin you must download/install it : B/ Recreate the ant script (maven ant) and define your dependencies in the build.properties like : Craig, for the problem with clean target, I think that we can : 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 Hi Craig,
What about 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 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. 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.
Applied. Thanks to Craig McClanahan for the idea, and to Dennis Lundberg for patchs.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Major
Allow URL substitutions in generated build.xml files
.
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.