Thanks Arnaud
So instead of having a shared directory on a file-server I would share a directory on a webserver. That way the developers can easily upload new release via the shared directory and Maven can easily download releases of company products from the webserver. Right?
I assume that the webserver can run https instead of http. For added security we could also limit the access of the maven directory at our webserver so that only our developers can access it.
Does anybody know if Maven understands basic authentication? I would rather have username/password access than restrict access by dns-name/ip-number.
-- Dennis Lundberg
Arnaud Heritier wrote:
A solution is to create a private repository for your company.
To do this you only need to have a web server where you publish your company's repository. You can also use maven-proxy (http://maven-proxy.codehaus.org/) to cache data from ibiblio.
Arnaud.
-----Message d'origine----- De : Dennis Lundberg [mailto:[EMAIL PROTECTED] Envoy� : samedi 17 juillet 2004 19:35 � : Maven Users List Objet : Re: [maven ant plugin] Suggested improvement
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]
--------------------------------------------------------------------- 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]
