Thanks for the help! >From the plugin documentation, that wasn't obvious: I thought that the >parameter only influences the final name.
Well, having three different artifacts from one Maven build isn't standard... ;-) Anyway, I'm still not 100% there, here's what Maven builds: schemas-private.war xml-schemas-1.7.0-SNAPSHOT.jar xml-schemas-1.7.0-SNAPSHOT-sources.jar xml-schemas-application-server-1.7.0-SNAPSHOT-appserver.zip xml-schemas-public-schema-server-1.7.0-SNAPSHOT-public.zip And here are the Jenkins build artifacts: xml-schemas-1.7.0-SNAPSHOT-private.war xml-schemas-1.7.0-SNAPSHOT.jar xml-schemas-1.7.0-SNAPSHOT-sources.jar xml-schemas-1.7.0-SNAPSHOT-appserver.zip xml-schemas-1.7.0-SNAPSHOT-public.zip xml-schemas-1.7.0-SNAPSHOT.pom But that's really good enough and I can work with that. Thanks again! Best regards, Eric -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Stephen Connolly Gesendet: Donnerstag, 7. Juni 2012 18:07 An: [email protected] Betreff: Re: Maven build results don't match Jenkins Build Artifacts On 7 June 2012 16:33, Lewis, Eric <[email protected]> wrote: > Well, the 'classifier' property within the Assembly plugin is deprecated. > Instead, the assembly's ID should be used, which is what I do. That's fine. I wasn't saying to use the classifier property, rather I was checking that you had different classifiers feeding into the reactor. > I have three different Assembly descriptors in that project. > > <?xml version="1.0" encoding="UTF-8"?> > <assembly > xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 > http://maven.apache.org/xsd/assembly-1.1.2.xsd";> > <id>appserver</id> > ... > > > <?xml version="1.0" encoding="UTF-8"?> > <assembly > xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 > http://maven.apache.org/xsd/assembly-1.1.2.xsd";> > <id>private</id> > ... > > <?xml version="1.0" encoding="UTF-8"?> > <assembly > xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 > http://maven.apache.org/xsd/assembly-1.1.2.xsd";> > <id>public</id> > ... > > > And here's the relevant part of the POM: > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-assembly-plugin</artifactId> > <executions> > <execution> > <id>create-private-xml-schema-war</id> > <phase>package</phase> > <goals> > <goal>single</goal> > </goals> > <configuration> > <descriptors> > > <descriptor>${assemblies.default.directory}/private-xml-schemas.xml</descriptor> > </descriptors> > <finalName>${schema.private.target.war.file}</finalName> > <appendAssemblyId>false</appendAssemblyId> ^^^ this means do not set the classifier to the assembly id, instead publish as main artifact > <outputDirectory>${project.build.directory}</outputDirectory> > <workDirectory>target/assembly/work-private</workDirectory> > </configuration> > </execution> > <execution> > <id>create-private-xml-schema-appserver-zip</id> > <phase>package</phase> > <goals> > <goal>single</goal> > </goals> > <configuration> > <descriptors> > > <descriptor>${assemblies.default.directory}/private-xml-schemas-appserver.xml</descriptor> > </descriptors> > > <finalName>${schema.private.appserver.target.zip.file}</finalName> > <appendAssemblyId>false</appendAssemblyId> ^^^ this means do not set the classifier to the assembly id, instead publish as main artifact > <outputDirectory>${project.build.directory}</outputDirectory> > > <workDirectory>target/assembly/work-private-appserver</workDirectory> > </configuration> > </execution> > <execution> > <id>create-public-xml-schema-zip</id> > <phase>package</phase> > <goals> > <goal>single</goal> > </goals> > <configuration> > <descriptors> > > <descriptor>${assemblies.default.directory}/public-xml-schemas.xml</descriptor> > </descriptors> > <finalName>${schema.public.target.zip.file}</finalName> > <appendAssemblyId>false</appendAssemblyId> ^^^ this means do not set the classifier to the assembly id, instead publish as main artifact > <outputDirectory>${project.build.directory}</outputDirectory> > <workDirectory>target/assembly/work-public</workDirectory> > </configuration> > </execution> > </executions> > </plugin> > > But I wonder whether Jenkins is confused because I define the ZIP's name > within the POM... Because you set the main artifact to three different zip files, and since there can be only one, the winner is ${assemblies.default.directory}/public-xml-schemas.xml being the last to execute in pom order. > > Best regards, > Eric > > -----Ursprüngliche Nachricht----- > Von: [email protected] > [mailto:[email protected]] Im Auftrag von Stephen Connolly > Gesendet: Donnerstag, 7. Juni 2012 17:22 > An: [email protected] > Betreff: Re: Maven build results don't match Jenkins Build Artifacts > > yes but do the assemblies produce different classifiers for the > different assemblies? > > On 7 June 2012 14:37, Lewis, Eric <[email protected]> wrote: >> Well, according to >> http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html the >> ZIP files are attached automatically ('attach' defaults to true). >> >> I'll archive the ZIP files as artifacts (thanks for the hint), but is there >> any way to check what is actually attached to the Maven build? >> >> Best regards, >> Eric >> >> -----Ursprüngliche Nachricht----- >> Von: [email protected] >> [mailto:[email protected]] Im Auftrag von Stephen Connolly >> Gesendet: Donnerstag, 7. Juni 2012 12:36 >> An: [email protected] >> Betreff: Re: Maven build results don't match Jenkins Build Artifacts >> >> I will bet you are not attaching the artifacts to the reactor >> correctly, i.e. one/both of the zip files do not have a classifier, in >> which case the last zip file will be the one bound to the reactor and >> hence picked up by the maven job type's crazy code. >> >> There is the ability to manually archive artifacts in addition to >> those auto-archived by the maven job type (I know this because when I >> was testing the cloudbees rsync-like faster archiving of artifacts >> code I spotted the option). that will give you back the permalinks and >> the file names will be those of the file system. >> >> I see this issue as a problem with your build and Jenkins is doing the >> "right thing" so I don't see the need for a JIRA >> >> On 7 June 2012 10:41, Lewis, Eric <[email protected]> wrote: >>> Well, the name is one thing, but the artifacts themselves differ (I create >>> two ZIP files, but only one (and which one?) ends up as Jenkins artifact. >>> >>> I would expect that the Maven job type asks Maven about the job artifacts - >>> but then I'm probably wrong ;-) >>> >>> For the moment I can live with the fact that I have to get artifacts from >>> the workspace instead of Jenkins (even though I'll miss the nice >>> permalinks). But should I write an issue in the Jenkins JIRA? >>> >>> Best regards, >>> Eric >>> >>> >>> >>> Von: [email protected] >>> [mailto:[email protected]] Im Auftrag von Stephen Connolly >>> Gesendet: Donnerstag, 7. Juni 2012 10:54 >>> An: [email protected] >>> Betreff: Re: Maven build results don't match Jenkins Build Artifacts >>> >>> Those are what maven considers the artifacts, ie those are the names that >>> will end up in the maven repository. >>> >>> You can manually archive the files if the name is that important to you. >>> >>> Of course I never use the maven job type as it does things (which make the >>> users life initially easier) that are not the maven way. My preference is a >>> maven build step in a freestyle project... But what would I know! >>> >>> One of these days sacha will ok me writing a correct maven job type >>> (something which I know how it should be done, but haven't had the time to >>> do yet. Btw that fork of jenkins has not done it right either ;-) ) >>> >>> On Thursday, 7 June 2012, Lewis, Eric wrote: >>> Hi >>> >>> Since changing from an old Hudson to Jenkins 1.460 I noticed that Maven's >>> build results differ from what Jenkins considers Build Artifacts. >>> Specifically it has to do with renaming and using other results of the >>> Maven assembly plugin. >>> >>> For instance, I have a build which repackages some XML schemas in various >>> forms. >>> >>> Here's what it looks like in the workspace: >>> >>> target/ >>> |-- schemas.war >>> |-- xml-schemas-1.6.0-sources.jar >>> |-- xml-schemas-1.6.0.jar >>> |-- xml-schemas-application-server-1.6.0.zip >>> `-- xml-schemas-public-schema-server-1.6.0.zip >>> >>> Here's what Jenkins considers build artifacts: >>> Build Artifacts >>> xml-schemas-1.6.0-sources.jar >>> xml-schemas-1.6.0.jar >>> xml-schemas-1.6.0.pom >>> xml-schemas-1.6.0.war >>> xml-schemas-1.6.0.zip >>> >>> Is this a known bug? >>> >>> Best regards, >>> Eric
