Hi Thomas.
Ah, got the wrong guy ;)
I'm not a "Maven way" zealot.. I create and modify plugins so that maven fits my needs and not the other way around. Maven is an integration/building tool, (and a great one) not a religion.. not for me anyway. I have no problems at all twisting it and making it more adapted to "real life" (pronounce: typical-not-so-organized-company-produced-software-projects...) projects.
Take a look at my plugin then: named uber-dist. It resides on sourceforge. Maybe it can help you. This guy introduced properties for dependency for automatic dependency publishing with renaming capabilities (to eliminate the version for instance).
I am a team leader in a company that didn't have any clue about maven before me. I did though versionned the jars when I migrated the project from Ant to Maven. It was a little pain at the beginning but now, we rely on the central repository and the team never messes up now since all is driven though the project.xml. Our main project is not at all the perfect Maven project template. The main project builds I don't know how many artifacts, I have multiple sub-projects that uses the parent's sources as well as the parent's target. But everything works just perfectly now. Most of those projects were alive before Maven came in.
Here, take a look, an example on an "extended" dependency definition we use with the plugin:
<dependency>
<groupId>commons-digester</groupId>
<artifactId>commons-digester</artifactId>
<version>1.5</version>
<url>http://jakarta.apache.org/commons/digester/</url>
<properties>
<CMS.deploy>true</CMS.deploy>
<jar.dependency.dist.dir>lib/3rdparty/catalina</jar.dependency.dist.dir>
<jar.dependency.dist.name>commons-digester.jar</jar.dependency.dist.name>
<!-- NOTE: Required by struts.jar -->
</properties>
</dependency>
With these, you can deploy, in the subdirectory you want and the jar gets renamed. But, in terms of configuration management, you always know what exact version you need by looking at project.xml... not at the actual distribution since nearly all the jars gets renamed. Legacy stuff...
GLuck with your project then Eric.
The CMS.deploy tells upber
[EMAIL PROTECTED] wrote:
ok, I understand that it goes against all that Maven stands for :-)
But I wish there were some property that could be added on a per-dependency basis that would force Maven to download the dependency every build. Just for weird situations, like teams working on company projects don't want to get into versioning their jars.
Thanks again. Tom
Eric Giguere <[EMAIL PROTECTED] eotron.ca> To Maven Users List 02/02/2005 12:54 <[email protected]> PM cc Subject Please respond to Re: is there a way to force maven "Maven Users to always download a dependency? List" <[EMAIL PROTECTED] he.org>
Hi No, cannot. But I would suggest to version all your jars and maybe remove the versions at deployment if it is an issue.
We are using this technique and the jar compatibility nightmare (jars in cvs, versions clashing, etc) ended and never came back!
HTH. Eric.
[EMAIL PROTECTED] wrote:
forwarded or distributed in any other format. This communication is for
What if some jar files are not versioned (and maybe will never be versioned). Is there a way to force Maven to always go to the remote repositories to resolve dependencies?
I've tried SNAPSHOT, but that does not reload a dependency every time a build is executed.
Thanks for your help. Tom
This message is intended for the recipient only and is not meant to be
informational purposes only. It is not intended as an offer or
solicitation for the purchase or sale of any financial instrument, or
security, or as an official confirmation of any transaction. Putnam does
not accept purchase or redemptions of securities, instructions, or
authorizations that are sent via e-mail. All market prices, data and
other information are not warranted as to completeness or accuracy and are
subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of Putnam, LLC (DBA Putnam Investments)
and its subsidiaries and affiliates. If you are not the intended recipient
of this e-mail, please delete the e-mail.
--------------------------------------------------------------------- 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]
This message is intended for the recipient only and is not meant to be forwarded or distributed in any other format. This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument, or security, or as an official confirmation of any transaction. Putnam does not accept purchase or redemptions of securities, instructions, or authorizations that are sent via e-mail. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of Putnam, LLC (DBA Putnam Investments) and its subsidiaries and affiliates. If you are not the intended recipient of this e-mail, please delete the e-mail.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
