The short answer is - because it works :-)
But, seriously, what I want is somewhere to put my company's internal jar-files, i.e. framework stuff that other company products depend upon. These files should be shared between the developers inside the company. The products also depend upon publicly available jar-files like commons-logging and junit, which can be found at ibiblio.
Correct me if I'm wrong here, since I'm pretty new to Maven. Isn't maven.local.repo the place in the user's home-directory where Maven stores downloaded jar-files for use now and later?
Is there a better way to do this?
-- Dennis Lundberg
Carlos Sanchez wrote:
Hi,
The question is, why do you need your internal repoin a directory? Why don't you use maven local repo?
Regards
Carlos Sanchez A Coru�a, Spain
Oness Project http://oness.sourceforge.net
-----Original Message-----
From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: Thursday, July 15, 2004 11:21 PM
To: [EMAIL PROTECTED]
Subject: [maven ant plugin] Suggested improvement
Hi there
I've been trying out the maven ant plugin and compared the result with my normal ant build.xml files. It does a good job. However I have found something that could be improved.
Imagine that you are using your own repo for internal jar-files as well as a public one by setting something like this in your project.properties:
maven.repo.remote=file://G:/dev/maven,http://www.ibiblio.org/maven
Using this setup and running
> maven ant
produces a build.xml that doesn't work. The reason for this seems to be that the ant get task doesn't support the file: protocol. To make this work, I have made some modifications to the generated build.xml file. The modification is replacing the get tasks with copy tasks.
I browsed through the CVS for the maven ant plugin and discovered the place to make the change in:
http://cvs.apache.org/viewcvs.cgi/maven-plugins/ant/src/plugin
-resources/templates/build.jelly
Unfortunatelly I don't speak jelly, but I'll outline the general idea here if someone feels that this is something worth adding. The following java-jelly-pseudo-code would go in where the get-deps target is created.
---Start psedo code--- if(${repo}.startsWith("file://")) { String filerepo = ${repo}.substring(7); <j:forEach var="dep" items="${pom.dependencies}"> <!-- note: this is a valid use of artifactDirectory --> <copy file="${filerepo}/${dep.artifactDirectory}/${dep.type}s/${dep.
artifact}"
tofile="$${libdir}/${dep.artifact}"
preservelastmodified="true"
failonerror="false"
/></j:forEach>
}
else {
// The stuff we do today, i.e. create a bunch of get tasks.
<j:forEach var="dep" items="${pom.dependencies}">
<!-- note: this is a valid use of artifactDirectory -->
<get
src="${repo}/${dep.artifactDirectory}/${dep.type}s/${dep.artifact}"
dest="$${libdir}/${dep.artifact}"
usetimestamp="true"
ignoreerrors="true"
/></j:forEach>
}
---End psedo code---
What do you think?
-- Dennis Lundberg
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
