You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "Brian E. Fox" <br...@reply.infinity.nu> on 2005/12/11 16:17:20 UTC
m2 - my technique for installing 3rd party jars
I meant to send this to the users list...
We have a bunch of jars we install into our repo and I see this question
a lot so I figured I'll throw my technique out there:
I create a folder (in a defined format so I can svn it) and make a quick
pom with the minimum (adding depends if I know them). Then I name the
jar the way it should be: artifactId-version. My pom calls the antrun
plugin to unzip the jar to the target/classes folder. This is so the
packaging phase can jar it up (and add a manifest), setting up the
references needed so install and or deploy will do their thing. This
works out very well for us since I now have a pom and deploy will create
all the hashes, etc. It's also very easy to type mvn deploy instead of
remembering the other parameterized method, and very reproducible. Since
the bulk of my pom (the entire build section) is identical from one jar
to the next, it is very quick to do another, maybe 60 seconds. Here is
what my pom looks like: (for this example I would put javamail-1.3.3.jar
in the root along with the pom)
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>javamail</groupId>
<artifactId>javamail</artifactId>
<name> Sun Mail API </name>
<version>1.3.3</version>
<description>Mail API for java - from Sun</description>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>generate-sources</phase>
<configuration>
<tasks>
<unzip src="${maven.build.finalName}.${maven.packaging}"
dest="target/classes"></unzip>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ftp</artifactId>
</extension>
</extensions>
</build>
<distributionManagement>
<repository>
<id>my repo</id>
<url>my repo</url>
</repository>
</distributionManagement>
</project>
Re: m2 - my technique for installing 3rd party jars
Posted by Allan Ramirez <ar...@exist.com>.
Thanks Brian! I can add this to the FAQ page. :)
Brian E. Fox wrote:
>I meant to send this to the users list...
>
>We have a bunch of jars we install into our repo and I see this question
>a lot so I figured I'll throw my technique out there:
>
>I create a folder (in a defined format so I can svn it) and make a quick
>pom with the minimum (adding depends if I know them). Then I name the
>jar the way it should be: artifactId-version. My pom calls the antrun
>plugin to unzip the jar to the target/classes folder. This is so the
>packaging phase can jar it up (and add a manifest), setting up the
>references needed so install and or deploy will do their thing. This
>works out very well for us since I now have a pom and deploy will create
>all the hashes, etc. It's also very easy to type mvn deploy instead of
>remembering the other parameterized method, and very reproducible. Since
>the bulk of my pom (the entire build section) is identical from one jar
>to the next, it is very quick to do another, maybe 60 seconds. Here is
>what my pom looks like: (for this example I would put javamail-1.3.3.jar
>in the root along with the pom)
>
><project>
> <modelVersion>4.0.0</modelVersion>
> <groupId>javamail</groupId>
> <artifactId>javamail</artifactId>
> <name> Sun Mail API </name>
> <version>1.3.3</version>
> <description>Mail API for java - from Sun</description>
>
> <build>
><plugins>
><plugin>
> <artifactId>maven-antrun-plugin</artifactId>
> <executions>
> <execution>
> <phase>generate-sources</phase>
> <configuration>
> <tasks>
> <unzip src="${maven.build.finalName}.${maven.packaging}"
>dest="target/classes"></unzip>
> </tasks>
> </configuration>
> <goals>
> <goal>run</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
> </plugins>
> <extensions>
> <extension>
> <groupId>org.apache.maven.wagon</groupId>
> <artifactId>wagon-ftp</artifactId>
> </extension>
> </extensions>
></build>
><distributionManagement>
> <repository>
> <id>my repo</id>
> <url>my repo</url>
> </repository>
></distributionManagement>
></project>
>
>
>
>
>------------------------------------------------------------------------
>
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.1.371 / Virus Database: 267.13.13/197 - Release Date: 12/9/2005
>
>
Re: m2 - my technique for installing 3rd party jars
Posted by Brill Pappin <jo...@gmail.com>.
Of course your right... but if you can't (as is often the case) or you
want to be able to reproduce your build at will, the you do need to
think about it.
In my case, I've got a bunch of people who don't give a rats ass why
it doesn't work when it doesn't... if I told them they had to install
20 jarsmanually, Maven would get replaced immediatly.
On 12/14/05, Carlos Sanchez <ca...@apache.org> wrote:
> If you create a remote repo any developer don't need to do that previous step
Re: m2 - my technique for installing 3rd party jars
Posted by Carlos Sanchez <ca...@apache.org>.
If you create a remote repo any developer don't need to do that previous step
On 12/12/05, Brill Pappin <jo...@gmail.com> wrote:
> You misunderstand... he can reproduce it at will... any developer that
> joins his company can simply check out the moduleand run the build...
>
> However I still think a better solution is to simply write a script
> that calls mvn install.
>
> - Brill Pappin
>
> On 12/12/05, Carlos Sanchez <ca...@apache.org> wrote:
> > It can't be automated becuase you still have to download by hand the
> > jars. They can't be redistributed. if they could they'd be at ibiblio.
> >
> >
> > On 12/11/05, Brill Pappin <jo...@gmail.com> wrote:
> > > But it will be automated and he can reproduce it at will...
> > > However, it might be faster to simply write a script that would call
> > > mvn install on each jar instead... you'd have to include the same
> > > information, but not write out the POM.
> > >
> > >
> > > On 12/11/05, Carlos Sanchez <ca...@apache.org> wrote:
> > > > I don't see the use of this, maybe you can explain it better.
> > > > - putting an empty pom is useless and in fact will cause trouble
> > > > because the right pom from ibiblio wont be downloaded
> > > > - now instead of passing 5 parameters you have to write this whole pom
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: m2 - my technique for installing 3rd party jars
Posted by Brill Pappin <jo...@gmail.com>.
You misunderstand... he can reproduce it at will... any developer that
joins his company can simply check out the moduleand run the build...
However I still think a better solution is to simply write a script
that calls mvn install.
- Brill Pappin
On 12/12/05, Carlos Sanchez <ca...@apache.org> wrote:
> It can't be automated becuase you still have to download by hand the
> jars. They can't be redistributed. if they could they'd be at ibiblio.
>
>
> On 12/11/05, Brill Pappin <jo...@gmail.com> wrote:
> > But it will be automated and he can reproduce it at will...
> > However, it might be faster to simply write a script that would call
> > mvn install on each jar instead... you'd have to include the same
> > information, but not write out the POM.
> >
> >
> > On 12/11/05, Carlos Sanchez <ca...@apache.org> wrote:
> > > I don't see the use of this, maybe you can explain it better.
> > > - putting an empty pom is useless and in fact will cause trouble
> > > because the right pom from ibiblio wont be downloaded
> > > - now instead of passing 5 parameters you have to write this whole pom
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: m2 - my technique for installing 3rd party jars
Posted by Carlos Sanchez <ca...@apache.org>.
It can't be automated becuase you still have to download by hand the
jars. They can't be redistributed. if they could they'd be at ibiblio.
On 12/11/05, Brill Pappin <jo...@gmail.com> wrote:
> But it will be automated and he can reproduce it at will...
> However, it might be faster to simply write a script that would call
> mvn install on each jar instead... you'd have to include the same
> information, but not write out the POM.
>
>
> On 12/11/05, Carlos Sanchez <ca...@apache.org> wrote:
> > I don't see the use of this, maybe you can explain it better.
> > - putting an empty pom is useless and in fact will cause trouble
> > because the right pom from ibiblio wont be downloaded
> > - now instead of passing 5 parameters you have to write this whole pom
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: m2 - my technique for installing 3rd party jars
Posted by Brill Pappin <jo...@gmail.com>.
But it will be automated and he can reproduce it at will...
However, it might be faster to simply write a script that would call
mvn install on each jar instead... you'd have to include the same
information, but not write out the POM.
On 12/11/05, Carlos Sanchez <ca...@apache.org> wrote:
> I don't see the use of this, maybe you can explain it better.
> - putting an empty pom is useless and in fact will cause trouble
> because the right pom from ibiblio wont be downloaded
> - now instead of passing 5 parameters you have to write this whole pom
Re: m2 - my technique for installing 3rd party jars
Posted by Carlos Sanchez <ca...@apache.org>.
I don't see the use of this, maybe you can explain it better.
- putting an empty pom is useless and in fact will cause trouble
because the right pom from ibiblio wont be downloaded
- now instead of passing 5 parameters you have to write this whole pom
On 12/11/05, Brian E. Fox <br...@reply.infinity.nu> wrote:
> I meant to send this to the users list...
>
> We have a bunch of jars we install into our repo and I see this question
> a lot so I figured I'll throw my technique out there:
>
> I create a folder (in a defined format so I can svn it) and make a quick
> pom with the minimum (adding depends if I know them). Then I name the
> jar the way it should be: artifactId-version. My pom calls the antrun
> plugin to unzip the jar to the target/classes folder. This is so the
> packaging phase can jar it up (and add a manifest), setting up the
> references needed so install and or deploy will do their thing. This
> works out very well for us since I now have a pom and deploy will create
> all the hashes, etc. It's also very easy to type mvn deploy instead of
> remembering the other parameterized method, and very reproducible. Since
> the bulk of my pom (the entire build section) is identical from one jar
> to the next, it is very quick to do another, maybe 60 seconds. Here is
> what my pom looks like: (for this example I would put javamail-1.3.3.jar
> in the root along with the pom)
>
> <project>
> <modelVersion>4.0.0</modelVersion>
> <groupId>javamail</groupId>
> <artifactId>javamail</artifactId>
> <name> Sun Mail API </name>
> <version>1.3.3</version>
> <description>Mail API for java - from Sun</description>
>
> <build>
> <plugins>
> <plugin>
> <artifactId>maven-antrun-plugin</artifactId>
> <executions>
> <execution>
> <phase>generate-sources</phase>
> <configuration>
> <tasks>
> <unzip src="${maven.build.finalName}.${maven.packaging}"
> dest="target/classes"></unzip>
> </tasks>
> </configuration>
> <goals>
> <goal>run</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
> </plugins>
> <extensions>
> <extension>
> <groupId>org.apache.maven.wagon</groupId>
> <artifactId>wagon-ftp</artifactId>
> </extension>
> </extensions>
> </build>
> <distributionManagement>
> <repository>
> <id>my repo</id>
> <url>my repo</url>
> </repository>
> </distributionManagement>
> </project>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org