Later this week (hopefully) I plan to do a UI-less plugin version of my repo webapp that uses Rendezvous[1] to discover repository peers, making this kind of thing a snap; you'll just type eg
maven rendezvous
and it will lauch jetty + a repo webapp and advertise itself on your LAN. You add that one repo into your build.properties, and it will make appropriate download requests to all of your peers. This way, as soon as one person in your group downloads or builds a jar, you all see it. Very cool.
- Baz
[1] http://www.strangeberry.com/java_rendevous.htm . Anyone know an ASL/BSD rendezvous implementation? This is LGPL so can't join the maven core.
Eelco Hillenius wrote:
Why not just set up a local webserver? That's what we do; works great. Another reason for doing this as that you can use Maven for combining your internal projects as well.
Here's how we do it:
Every developper has build.properties in his {user-home}. In this file:
maven.repo.remote = http://your-webserver-address
your can use all the repos you want using a comma seperated list.
To make our lives easier for now (we haven't set up a ssh server yet), we also wrote two custom targets like this:
<project xmlns:j="jelly:core" xmlns:ant="jelly:ant" xmlns:license="license" xmlns:maven="jelly:maven" xmlns:deploy="deploy" xmlns:resources="resources" xmlns:util="jelly:util" xmlns:doc="doc" xmlns:m="maven">
<goal name="jar:fsdeploy" prereqs="jar:jar" description="Install the jar in the local repository">
<ant:property name="maven.jar.to.deploy" value="${maven.final.name}.jar"/>
<ant:property name="jardir__" value="${maven.repo.central.fileserver}/${pom.artifactDirectory}/jars"/> <ant:mkdir dir="${jardir__}"/> <ant:echo>copy ${maven.jar.to.deploy} to ${jardir__}</ant:echo> <ant:copy file="${maven.build.dir}/${maven.jar.to.deploy}" todir="${jardir__}" overwrite="true" /> </goal>
<goal name="jar:fsdeploy-snapshot" description="Install the snapshot jar in the local repository">
<maven:snapshot project="${pom}"/> <j:set var="maven.final.name" value="${snapshotSignature}"/> <j:set var="maven.jar.to.deploy" value="${maven.final.name}.jar"/> <ant:echo>Building snapshot JAR: ${maven.final.name}</ant:echo> <attainGoal name="jar:jar"/>
<ant:property name="jardir__" value="${maven.repo.central.fileserver}/${pom.artifactDirectory}/jars"/> <ant:mkdir dir="${jardir__}"/> <ant:echo>copy ${maven.jar.to.deploy} as ${pom.artifactId}-SNAPSHOT.jar to ${jardir__}</ant:echo> <ant:copy file="${maven.build.dir}/${maven.jar.to.deploy}" tofile="${jardir__}/${pom.artifactId}-SNAPSHOT.jar" overwrite="true" /> </goal>
</project>
using (in build.properties):
maven.repo.central.fileserver = E:/
where E:/ is a local share to the webserver dir.
I know it's better to use ssh, but this works today, where setting up ssh (on Win) is a bit of a pain right now.
Hope this helps,
Eelco
-----Original Message----- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: maandag 2 juni 2003 16:16 To: Maven Users List Subject: RE: multiple sourceDirectory elements & local jar dependencies
You can override the location of dependency jars (or just the version) using properties -- see http://maven.apache.org/reference/user-guide.html#Overriding%20Sta ted%20Dependencies
A local repository which supplements iBiblio is indeed a cool idea, as it lets you solve the problem you just pointed out more easily than setting maven properties, and it gives you a place to store locally developed JARs for other projects and to store JARs that can't be on iBiblio (like everything you use from Sun). Plus you don't have to wait for iBiblio to get updated.
Joe
Another question: if you have a dependency on a jar that doesn't
have a neat
external place to get it, and you want to pick up that jar from the local file system, what do you do? I manually created the necessary directory structure under maven-1.0-beta-9\repository to make like it had been downloaded. Is there another way? I think it would be cool to just say:
<dependency> <id>myjar</id> <uri>./lib</uri> </dependency>
Where it defaults to looking in ./lib for myjar.jar (no version,
but version
could be optionally specified), or the URI could specify the
protocol like
file:./lib, or be a variable like ${maven.repo.local}. Or again, an optional attribute on the dependency, like <dependency
repository="local"/>.
Current common solution (in mail archives) is to set
maven.repo.remote to a
local repository (either local file system or an internal
server). This is
also a cool idea. A local repository (supplemental to ibiblio)
on our own
server seems like a cool idea.
-- -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "If nature worked that way, the universe would crash all the time." --Jaron Lanier
--------------------------------------------------------------------- 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]
