maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian E. Fox" <bri...@reply.infinity.nu>
Subject RE: m2 - my technique for installing 3rd party jars
Date Tue, 13 Dec 2005 01:50:15 GMT
I'm doing this because the jars don't exist and won't exist on ibiblio.
(some are non-free). Also, this deploys to my remote repo, not just to
my local one. I don't have to then turn around and go find it in my
local and move it to the remote. And since I'm keeping these jars and
poms in my source control, it's simple to redploy everything to my repo
if I need to. Otherwise I gotta start all over and do the commands one
at a time. It also works with the currently released version of maven
and has for a long time now. (creates the hashes)

-----Original Message-----
From: carlossg@gmail.com [mailto:carlossg@gmail.com] On Behalf Of Carlos
Sanchez
Sent: Sunday, December 11, 2005 8:35 PM
To: Maven Users List
Subject: Re: m2 - my technique for installing 3rd party jars

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 <brianf@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



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message