Well, the 'classifier' property within the Assembly plugin is deprecated. Instead, the assembly's ID should be used, which is what I do. 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> <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> <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> <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... 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
