maven signjar plugin
The maven site to the maven signjar plugin does not seem to be completely up to date. [MJARSIGNER-6] Allow batch signing of multiple JARs This has not been covered by the documentation, and according to JIRA this was included in the 1.1 release, the current release is 1.2. What should be trusted here? JIRA or the documentation? Best regards -- Erlend
Re: maven signjar plugin
I am apparantly unable to read documentation. Sorry guys, ignore this. On Mon, Jun 28, 2010 at 9:02 AM, Erlend Hamnaberg ngar...@gmail.com wrote: The maven site to the maven signjar plugin does not seem to be completely up to date. [MJARSIGNER-6] Allow batch signing of multiple JARs This has not been covered by the documentation, and according to JIRA this was included in the 1.1 release, the current release is 1.2. What should be trusted here? JIRA or the documentation? Best regards -- Erlend
RE: webResources not copied during build on UNIX.
Is there any possibility that on Windows you are relying on the fact that there
is no case distinction in the names and using different capitalization?
Stan
-Original Message-
From: Michael Delaney [mailto:mdela...@upromise.com]
Sent: Friday, June 25, 2010 1:40 PM
To: users@maven.apache.org
Subject: webResources not copied during build on UNIX.
All,
I have a war project (by this I mean packaging type is 'war') that, in
the maven-war-plugin, I'm defining some web resources (see snipped
below). During a build on Windows the resources specified in the
'webResources' tag are copied over but during a build on UNIX (most
explicitly Solaris) the resources are not copied over. The paths do not
contain any Windows specific slashes and the case of the files is also
correct.
Anyone know what could be causing this?
We're using maven-war-plugin version 2.1-alpha-1 and
maven-resources-plugin 2.3.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
configuration
webResources
resource
filteringfalse/filtering
directory${basedir}/src/main/resources/templates/directory
!-- the list has a default value of ** --
includes
includeweb.xml/include
/includes
targetPathWEB-INF/templates/targetPath
/resource
/webResources
/configuration
/plugin
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Shade plugin on Multimodule projects
Hi, I have a multimodule project for which I want to use the shade plugin. All is configured in the parent pom. Running on the parent with mvn clean package fails with Replacing null with d:\workspace-maven\assemblies\parent\target\parent-0.0.1-SNAPSHOT-shaded.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error creating shaded jar: null so how do I need to configure the plugin to not shade the parent as its not a jar but a pom ? Thanks Marty -- View this message in context: http://maven.40175.n5.nabble.com/Shade-plugin-on-Multimodule-projects-tp511665p511665.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Shade plugin on Multimodule projects
put the configuration for the shade plugin in pluginManagement and then just reference the sade plugin in the modules you want to use shade in On 28 June 2010 13:51, MartyMcFly martymc...@smart-mail.de wrote: Hi, I have a multimodule project for which I want to use the shade plugin. All is configured in the parent pom. Running on the parent with mvn clean package fails with Replacing null with d:\workspace-maven\assemblies\parent\target\parent-0.0.1-SNAPSHOT-shaded.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error creating shaded jar: null so how do I need to configure the plugin to not shade the parent as its not a jar but a pom ? Thanks Marty -- View this message in context: http://maven.40175.n5.nabble.com/Shade-plugin-on-Multimodule-projects-tp511665p511665.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to take archetypeVersion in archetype-resources ?
Hi Thiago,
I'm sorry. Until now I don't solve it.
Kinh
Quoting Thiago Moreira (timba) tmoreira2...@gmail.com:
Hi Khin,
How did you manage this problem? I'm trying to do the same thing.
Thanks
Thiago Moreira
On Fri, Jun 11, 2010 at 11:29 AM, NGUYEN Cong Kinh
cong_kinh.ngu...@it-sudparis.eu wrote:
Hi everybody,
I create a maven-archetype as the following:
- myArchetype
+ pom.xml (1)
+ src/main/resources
+ META-INF...
+ archetype-resources
- pom.xml (2)
- src/...
In the second POM (pom.xml - 2) which module will be generated by my
maven-archetype, I want to set the version of one dependency to the same
version with my maven - archetype. Could you any ideas for that? (I tried to
use ${archetypeVersion}, but it seems to me that this isn't correct).
For example, I define the second POM as following:
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupId${groupId}/groupId
artifactId${artifactId}/artifactId
packagingjar/packaging
version${version}/version
nameYour custom project/name
dependencies
dependency
groupIdmy groupID/groupId
artifactIdmy artifactID/artifactId
versionwhat will be placed here ?/version
/dependency
/dependencies
...
/project
Thanks in advance,
Kinh
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Shade plugin on Multimodule projects
thanks its working now :) one question to add. Is there a simple configuration to exclude transitive dependencies ? for now I only found to explicitly define the direct dependencies in the include section of artifactSet, but with that you have to maintain the dependencies twice. Thanks -- View this message in context: http://maven.40175.n5.nabble.com/Shade-plugin-on-Multimodule-projects-tp511665p511671.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
building source-release.zip artifacts for Apache multi-module aggregator projects
The Apache common top-level pom ( http://repo1.maven.org/maven2/org/apache/apache/7/apache-7.pom ) has a profile activated when doing releases, which invokes the maven-assembly-plugin to build the source-release.zip artifact. For single module (non-aggregate projects) this seems fine. For multi-module (aggregator-pom) projects, I think this only builds the source-release for the aggregator project by itself, unless the maven convention of having the directory layout have the aggregator pom in a directory which contains all the sub-projects. In our case, we have a flat hierarchy (actually, not exactly - we collect various parent-poms into one directory). My first attempt to alter our release -build process was to include in the maven-assembly-plugin descriptor a moduleSets section, to use the information in the aggregator modules element to locate and include all the subprojects. This kind of worked, but not quite, because it imposed a particular directory layout on the result, which didn't exactly match the SVN and working copy directory layout. (This was because I had put all of our parent-poms under one additional directory, just to keep things nicely organized ... ) After thinking more about this, it seems that the source-release.zip package should include just exactly what is in the SVN, starting with a directory there which is common among all the parts (the aggregating pom, and all of the projects being aggregated), but filtered to exclude all those things not in the set of artifacts being released. For example, in this layout (SVN and working copy): some-top-lvl-common-dir | +- aggregate-project | | | +- aggregate-pom.xml +- parent-poms | | | +- parent1-project | | | | | +- parent1.xml | +- parent2-project | | | | | +- parent2.xml +- some-non-released-thing the some-non-released-thing would be filtered, since it wasn't a module or the aggregate project. Does this sound like the right way to package source-releases for arbitrary layout SVN multi-module Apache projects? If so, is there a plugin which does this? -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: building source-release.zip artifacts for Apache multi-module aggregator projects
On 6/28/2010 9:52 AM, Marshall Schor wrote: The Apache common top-level pom ( http://repo1.maven.org/maven2/org/apache/apache/7/apache-7.pom ) has a profile activated when doing releases, which invokes the maven-assembly-plugin to build the source-release.zip artifact. I meant to include that Apache source releases are supposed to have what is needed to build the artifact from sources. For single module (non-aggregate projects) this seems fine. For multi-module (aggregator-pom) projects, I think this only builds the source-release for the aggregator project by itself, unless the maven Sorry for the bad English caused by cut/paste - should say unless the maven convention of ... is followed convention of having the directory layout have the aggregator pom in a directory which contains all the sub-projects. In our case, we have a flat hierarchy (actually, not exactly - we collect various parent-poms into one directory). My first attempt to alter our release -build process was to include in the maven-assembly-plugin descriptor a moduleSets section, to use the information in the aggregator modules element to locate and include all the subprojects. This kind of worked, but not quite, because it imposed a particular directory layout on the result, which didn't exactly match the SVN and working copy directory layout. (This was because I had put all of our parent-poms under one additional directory, just to keep things nicely organized ... ) After thinking more about this, it seems that the source-release.zip package should include just exactly what is in the SVN, starting with a directory there which is common among all the parts (the aggregating pom, and all of the projects being aggregated), but filtered to exclude all those things not in the set of artifacts being released. For example, in this layout (SVN and working copy): some-top-lvl-common-dir | +- aggregate-project | | | +- aggregate-pom.xml +- parent-poms | | | +- parent1-project | | | | | +- parent1.xml | +- parent2-project | | | | | +- parent2.xml +- some-non-released-thing the some-non-released-thing would be filtered, since it wasn't a module or the aggregate project. Does this sound like the right way to package source-releases for arbitrary layout SVN multi-module Apache projects? If so, is there a plugin which does this? (In this note, filtering just means including or excluding subtrees of files, not running the maven filtering software). I think the release plugin put in already the code to discover a common parent directory, as described above. (I don't think it has filtering code though). And the release process is already checking out into the target/checkout directory the SVN directory - so before it does any changes beyond the fresh checkout, could it build the source-release.zip from the (filtered) version of what's there? -Marshall -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Sanity Check
On Mon, Jun 28, 2010 at 3:53 PM, Greg Akins angryg...@gmail.com wrote: On Sat, Jun 26, 2010 at 11:20 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: [Returning reply to the list so that others may benefit] http://wiki.hudson-ci.org/display/HUDSON/File+System+SCM That's cool. Thanks for the suggestion. Still it seems that this will be pretty slow compared to a maven plugin that can run and just execute test when ever the files change. Autotest reminds me of using editors that give real-time compile information.. it's that quick (obviously assuming your tests are quick to begin with) Even if I could execute 'mvn test' every time a file changed, just the startup of mvn is enough to slow that feedback look considerably. -- Greg Akins http://insomnia-consulting.org http://www.pghcodingdojo.org http://pittjug.dev.java.net http://twitter.com/akinsgre http://www.linkedin.com/in/akinsgre - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Sanity Check
On Mon, Jun 28, 2010 at 3:53 PM, Greg Akins angryg...@gmail.com wrote: On Sat, Jun 26, 2010 at 11:20 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: [Returning reply to the list so that others may benefit] http://wiki.hudson-ci.org/display/HUDSON/File+System+SCM That's cool. Thanks for the suggestion. Still it seems that this will be pretty slow compared to a maven plugin that can run and just execute test when ever the files change. Autotest reminds me of using editors that give real-time compile information.. it's that quick (obviously assuming your tests are quick to begin with) Even if I could execute 'mvn test' every time a file changed, just the startup of mvn is enough to slow that feedback look considerably. You could use maven shell for faster feedback. manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Sanity Check
On Mon, Jun 28, 2010 at 3:57 PM, Manfred Moser manf...@mosabuam.com wrote: You could use maven shell for faster feedback. yeah.. that actually works well.. I'd like it to happen automatically, though. -- Greg Akins http://insomnia-consulting.org http://www.pghcodingdojo.org http://pittjug.dev.java.net http://twitter.com/akinsgre http://www.linkedin.com/in/akinsgre - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Building a tar and zip of jars from other projects
I am trying to build a pom in its own project that will assemble a tar
file and a zip file that will contain all of the jar files that we build
that need to go into the tomcat/lib directory.
I am missing 2 things.
1) What do I say to tell the maven-assembly-plugin that I want a tar and
a zip built?
2) How to I tell the maven-assembly-plugin that I want the jar files
zipped up without the contents being extracted and zipped as individual
classes?
I have built a test pom shown below.
Since it has
descriptorRef
jar-with-dependencies
/descriptorRef
it restructures the internal jar contents rather than creating a tar of
jar files.
I did find a nice article from Sonatype but these questions remain.
Ron
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
parent
groupIdcom.artifact_software.lms/groupId
artifactIdlms-pom-master/artifactId
version1.8.3-SNAPSHOT/version
/parent
groupIdcom.artifact_software.lms/groupId
artifactIdlms-deployment-jars/artifactId
version1.8.3-SNAPSHOT/version
packagingpom/packaging
descriptionArtifact LMS Portal Shared Library Archive
builder./description
namelms-deploymentjars/name
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
/properties
dependencies
dependency
groupIdcom.artifact_software.lms/groupId
artifactIdlms-pom-spring-hibernate-mysql-tomcat/artifactId
version${lms-project.version}/version
typepom/type
/dependency
dependency
groupIdcom.artifact_software.lms/groupId
artifactIdlms-pom-jsf/artifactId
version${lms-project.version}/version
typepom/type
/dependency
/dependencies
build
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
version2.2-beta-2/version
executions
execution
idcreate-jar-deployment-archive/id
phasepackage/phase
goals
goalsingle/goal
/goals
configuration
descriptorRefs
descriptorRef
jar-with-dependencies
/descriptorRef
/descriptorRefs
/configuration
/execution
/executions
/plugin
/plugins
/build
/project
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Building a tar and zip of jars from other projects
On 6/28/2010 4:12 PM, Ron Wheeler wrote:
I am trying to build a pom in its own project that will assemble a tar
file and a zip file that will contain all of the jar files that we
build that need to go into the tomcat/lib directory.
I am missing 2 things.
1) What do I say to tell the maven-assembly-plugin that I want a tar
and a zip built?
There are two ways to configure the assembly plugin - one uses
predefined descriptors, the other lets you specify specific
instructions in a descriptor of your own that you point to - use the
parameter descriptors instead of descriptorRefs.
Then write your own assembly descriptor. See
http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html for
instructions on how to do this. You'll see an element formats where
you can specify the tar and zip formats.
2) How to I tell the maven-assembly-plugin that I want the jar files
zipped up without the contents being extracted and zipped as
individual classes?
In the custom assembly descriptor you make, you can control this using
the unpack option, see the details in the above documentation.
For a book chapter on how to do all kinds of things with assemblies, see:
http://www.sonatype.com/books/mvnref-book/reference/assemblies.html
-Marshall Schor
I have built a test pom shown below.
Since it has
descriptorRef
jar-with-dependencies
/descriptorRef
it restructures the internal jar contents rather than creating a tar
of jar files.
I did find a nice article from Sonatype but these questions remain.
Ron
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
parent
groupIdcom.artifact_software.lms/groupId
artifactIdlms-pom-master/artifactId
version1.8.3-SNAPSHOT/version
/parent
groupIdcom.artifact_software.lms/groupId
artifactIdlms-deployment-jars/artifactId
version1.8.3-SNAPSHOT/version
packagingpom/packaging
descriptionArtifact LMS Portal Shared Library Archive
builder./description
namelms-deploymentjars/name
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
/properties
dependencies
dependency
groupIdcom.artifact_software.lms/groupId
artifactIdlms-pom-spring-hibernate-mysql-tomcat/artifactId
version${lms-project.version}/version
typepom/type
/dependency
dependency
groupIdcom.artifact_software.lms/groupId
artifactIdlms-pom-jsf/artifactId
version${lms-project.version}/version
typepom/type
/dependency
/dependencies
build
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
version2.2-beta-2/version
executions
execution
idcreate-jar-deployment-archive/id
phasepackage/phase
goals
goalsingle/goal
/goals
configuration
descriptorRefs
descriptorRef
jar-with-dependencies
/descriptorRef
/descriptorRefs
/configuration
/execution
/executions
/plugin
/plugins
/build
/project
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
[ANN] RMIC Maven Plugin 1.1 Released
The Mojo team is pleased to announce the release of the RMI Compiler Maven Plugin version 1.1. http://mojo.codehaus.org/rmic-maven-plugin/ This release includes minors updates to the site and the project configuration. To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdrmic-maven-plugin/artifactId version1.1/version /plugin A comprehensive list of changes is attached at the end of this mail. Regards, The Mojo team. Release Notes - Maven 2.x RMIC Plugin - Version 1.1 ** Improvement * [MRMIC-27] - The example for the package goal is broken - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: saxon and maven
nothing happend so far On 23.03.2009 06:54, Wayne Fay wrote: would be best if the Saxon developers deploy the latest version. I looked in the Saxon bug list and only found 1 issue that mentioned Maven (from 2006) and the developer said that deploying new versions to the Maven repo just wasn't something he cared to deal with. He might have changed his mind a bit in the last 2-3yrs, but you'd have to ask him (nicely) to find out one way or the other... Or perhaps volunteer to help him with this? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Building a tar and zip of jars from other projects
Thanks for the quick reply. See below.
On 28/06/2010 4:37 PM, Marshall Schor wrote:
On 6/28/2010 4:12 PM, Ron Wheeler wrote:
I am trying to build a pom in its own project that will assemble a tar
file and a zip file that will contain all of the jar files that we
build that need to go into the tomcat/lib directory.
I am missing 2 things.
1) What do I say to tell the maven-assembly-plugin that I want a tar
and a zip built?
There are two ways to configure the assembly plugin - one uses
predefined descriptors, the other lets you specify specific
instructions in a descriptor of your own that you point to - use the
parameterdescriptors instead ofdescriptorRefs.
Where are the predefined descriptors documented?
Then write your own assembly descriptor.
Do I need to write my own?
See
http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html for
instructions on how to do this. You'll see an elementformats where
you can specify the tar and zip formats.
2) How to I tell the maven-assembly-plugin that I want the jar files
zipped up without the contents being extracted and zipped as
individual classes?
In the custom assembly descriptor you make, you can control this using
theunpack option, see the details in the above documentation.
For a book chapter on how to do all kinds of things with assemblies, see:
http://www.sonatype.com/books/mvnref-book/reference/assemblies.html
Unpack seems to be too late. Once you merge the jars, I don't see how
you can reconstruct the jars during the unpack.
Ron
-Marshall Schor
I have built a test pom shown below.
Since it has
descriptorRef
jar-with-dependencies
/descriptorRef
it restructures the internal jar contents rather than creating a tar
of jar files.
I did find a nice article from Sonatype but these questions remain.
Ron
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
parent
groupIdcom.artifact_software.lms/groupId
artifactIdlms-pom-master/artifactId
version1.8.3-SNAPSHOT/version
/parent
groupIdcom.artifact_software.lms/groupId
artifactIdlms-deployment-jars/artifactId
version1.8.3-SNAPSHOT/version
packagingpom/packaging
descriptionArtifact LMS Portal Shared Library Archive
builder./description
namelms-deploymentjars/name
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
/properties
dependencies
dependency
groupIdcom.artifact_software.lms/groupId
artifactIdlms-pom-spring-hibernate-mysql-tomcat/artifactId
version${lms-project.version}/version
typepom/type
/dependency
dependency
groupIdcom.artifact_software.lms/groupId
artifactIdlms-pom-jsf/artifactId
version${lms-project.version}/version
typepom/type
/dependency
/dependencies
build
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
version2.2-beta-2/version
executions
execution
idcreate-jar-deployment-archive/id
phasepackage/phase
goals
goalsingle/goal
/goals
configuration
descriptorRefs
descriptorRef
jar-with-dependencies
/descriptorRef
/descriptorRefs
/configuration
/execution
/executions
/plugin
/plugins
/build
/project
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: saxon and maven
http://repo2.maven.org/maven2/net/sourceforge/saxon/saxon/9.1.0.8/ On Mon, Jun 28, 2010 at 3:32 PM, Rolf Schumacher mailingl...@august.de wrote: nothing happend so far On 23.03.2009 06:54, Wayne Fay wrote: would be best if the Saxon developers deploy the latest version. I looked in the Saxon bug list and only found 1 issue that mentioned Maven (from 2006) and the developer said that deploying new versions to the Maven repo just wasn't something he cared to deal with. He might have changed his mind a bit in the last 2-3yrs, but you'd have to ask him (nicely) to find out one way or the other... Or perhaps volunteer to help him with this? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Building a tar and zip of jars from other projects
On 6/28/2010 6:39 PM, Ron Wheeler wrote:
Thanks for the quick reply. See below.
On 28/06/2010 4:37 PM, Marshall Schor wrote:
On 6/28/2010 4:12 PM, Ron Wheeler wrote:
I am trying to build a pom in its own project that will assemble a tar
file and a zip file that will contain all of the jar files that we
build that need to go into the tomcat/lib directory.
I am missing 2 things.
1) What do I say to tell the maven-assembly-plugin that I want a tar
and a zip built?
There are two ways to configure the assembly plugin - one uses
predefined descriptors, the other lets you specify specific
instructions in a descriptor of your own that you point to - use the
parameterdescriptors instead ofdescriptorRefs.
Where are the predefined descriptors documented?
See
http://www.sonatype.com/books/mvnref-book/reference/assemblies-sect-basics.html#assemblies-sect-predefined
Also see
http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html
Then write your own assembly descriptor.
Do I need to write my own?
Yes, I think so.
See
http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html for
instructions on how to do this. You'll see an elementformats where
you can specify the tar and zip formats.
2) How to I tell the maven-assembly-plugin that I want the jar files
zipped up without the contents being extracted and zipped as
individual classes?
In the custom assembly descriptor you make, you can control this using
theunpack option, see the details in the above documentation.
For a book chapter on how to do all kinds of things with assemblies,
see:
http://www.sonatype.com/books/mvnref-book/reference/assemblies.html
Unpack seems to be too late. Once you merge the jars, I don't see how
you can reconstruct the jars during the unpack.
Sorry, I meant to suggest you use the unpackfalse/unpack setting, to
prevent the Jars from being unpacked. According to the documentation,
this is the default - so maybe it will do just what you want by default :-)
-Marshall Schor
Ron
-Marshall Schor
I have built a test pom shown below.
Since it has
descriptorRef
jar-with-dependencies
/descriptorRef
it restructures the internal jar contents rather than creating a tar
of jar files.
I did find a nice article from Sonatype but these questions remain.
Ron
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
parent
groupIdcom.artifact_software.lms/groupId
artifactIdlms-pom-master/artifactId
version1.8.3-SNAPSHOT/version
/parent
groupIdcom.artifact_software.lms/groupId
artifactIdlms-deployment-jars/artifactId
version1.8.3-SNAPSHOT/version
packagingpom/packaging
descriptionArtifact LMS Portal Shared Library Archive
builder./description
namelms-deploymentjars/name
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
/properties
dependencies
dependency
groupIdcom.artifact_software.lms/groupId
artifactIdlms-pom-spring-hibernate-mysql-tomcat/artifactId
version${lms-project.version}/version
typepom/type
/dependency
dependency
groupIdcom.artifact_software.lms/groupId
artifactIdlms-pom-jsf/artifactId
version${lms-project.version}/version
typepom/type
/dependency
/dependencies
build
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
version2.2-beta-2/version
executions
execution
idcreate-jar-deployment-archive/id
phasepackage/phase
goals
goalsingle/goal
/goals
configuration
descriptorRefs
descriptorRef
jar-with-dependencies
/descriptorRef
/descriptorRefs
/configuration
/execution
/executions
/plugin
/plugins
/build
/project
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: standardized Maven GAV URN?
Group:artifact:version:classifier:extension is pretty common On Jun 26, 2010, at 1:39 PM, lukewpatterson lukewpatter...@gmail.com wrote: It would be nice to be able to represent any Maven GAV in a string. Does such a standard exist? A good use case is for plugins that allow input configuration file paths. If there was a reusable component that took an ArtifactResolver and a String, then any plugins that currently accept file locations as Strings could passively add GAV capability. e.g. with Clover plugin, I can give the path for the license file, but if I want to store the license in the company's internal Maven repo (and thus get the advantage of Maven versioning), I have to jump through some dependency plugin hoops to get it in the right place at the right time. I'd like to be able to just give the Clover plugin a GAV URN and have it download what it needs -- View this message in context: http://maven.40175.n5.nabble.com/standardized-Maven-GAV-URN-tp511480p511480.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
