maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anthony Dahanne <anthony.daha...@gmail.com>
Subject Re: snapshot versions and classpath stored in manifest
Date Thu, 10 Jan 2013 14:58:30 GMT
Brian,
I got a tip from a colleague, to use the outputFileNameMapping :
https://github.com/anthonydahanne/maven-manifest-and-assembly-bug/commit/bd946565da54be6faa1af71e894b16e6b1b0ff48

I checked with my sample project, and it renames the snapshot to a
-SNAPSHOT , which will satisfy the manifest.

Do you think this is a hack  ?
Thanks again,
Anthony





On Thu, Jan 10, 2013 at 12:14 AM, Anthony Dahanne <anthony.dahanne@gmail.com
> wrote:

> Hello Brian,
> So I triple checked, and I specified : (2.4 is the latest version)
>
> <plugin>
>          <groupId>org.apache.maven.plugins</groupId>
>          <artifactId>maven-jar-plugin</artifactId>
>          <version>2.4</version>
> </plugin>
>
> in each of my modules, but still, if I :
> * in my cli project reactor : $ mvn clean deploy
> * clean the local repo : $ rm -rf ~/.m2/repository/com/terracotta/
> * in the assembly module : $ mvn clean install -U
>
> I get :
>
> z:target anthony$ tar xvzf assembly-1.1.0-SNAPSHOT-bundle.tar.gz
> x cli-1.1.0-20130110.023006-1.jar
> x dependencyA-1.1.0-20130110.023002-1.jar
> x slf4j-jdk14-1.6.6.jar
> x slf4j-api-1.6.6.jar
>
> with the cli manifest having :
> Class-Path: dependencyA-1.1.0-SNAPSHOT.jar slf4j-jdk14-1.6.6.jar slf4j
>  -api-1.6.6.jar
>
> I set up a very simple example and a nexus instance to reproduce this use
> case
> https://github.com/anthonydahanne/maven-manifest-and-assembly-bug
>
> Thanks for having a look,
> Anthony
>
>
>
>
>
>
>
>
> On Wed, Jan 9, 2013 at 1:40 PM, Brian Fox <brianf@infinity.nu> wrote:
>
>> Are you positive you are using jar plugin version 2.3?
>>
>>
>> On Mon, Jan 7, 2013 at 11:26 AM, Anthony Dahanne
>> <anthony.dahanne@gmail.com>wrote:
>>
>> > Hello all,
>> > I am using Maven 3 with Nexus 2.
>> > I am building a cli tool (let's call it cli) , which has dependencies on
>> > some other libraries (let's call them dependencyA and dependencyB)
>> > To make my cli tool work in every environment, I rely on the manifest
>> > classpath, generated with :
>> > <plugin>
>> >   <groupId>org.apache.maven.plugins</groupId>
>> >   <artifactId>maven-jar-plugin</artifactId>
>> >   <configuration>
>> >     <archive>
>> >       <manifest>
>> >         <addClasspath>true</addClasspath>
>> >       </manifest>
>> >     </archive>
>> >   </configuration>
>> > </plugin>
>> >
>> > and then I package everything (cli and its dependencies) using an
>> assembly
>> >
>> > my launcher script looks like :
>> > java -jar cli*.jar (the * is there so that I won't need to update the
>> > script for any versions)
>> >
>> > If I build everything locally, in version 1.1.0-SNAPSHOT, here is the
>> > manifest classpath entry :
>> > Class-Path: dependencyA-1.1.0-SNAPSHOT.jar dependencyB-1.1.0-S
>> >  NAPSHOT.jar  slf4j-jdk14-1.6.6.jar slf4j-api-1.6.6.jar
>> >
>> > locally, everything is fine
>> >
>> > Now, if I download the assembly, built by a CI tool and published to
>> Nexus,
>> > the manifest is still the same, but look at the names of the
>> dependencies :
>> > ~> ls lib/
>> > cli-1.1.0-20130105.224257-7.jar  dependencyA-1.1.0-20130105.224257-7.jar
>> > dependencyB-1.1.0-20130105.224257-7.jar
>> >
>> > As you can imagine, the cli won't find it's dependencies since their
>> > version does not match any more the manifest's (SNAPSHOT in the
>> manifest,
>> > 1.1.0-20130105.224257-7 is what we have)
>> >
>> > It seems like this issue was fixed some time ago :
>> > http://jira.codehaus.org/browse/MJAR-28
>> >
>> > Is is a regression ?
>> >
>> > Thanks a lot for your help!
>> > Anthony
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message