Re: shade plugin usage
First, try to stay away from the überjar path. It's normally not the way to go today, but you should use the jar and it's dependencies instead. I've seen many case where people use a überjar just to try to make their life simpler but ending up with other issues instead. A proper classpath is the way to go in my opinion. I guess your approach of deploying the überjar and a dep-reduced-pom would work, but please remember to deploy it to your remote repo as well (and not just your local repo). Somewhere in the back of my head I recall a similar discussion earlier. Not sure if someone brought up any issues though. Having said that, the reason for deploying the überjar at a separate coordinate would be to have a separate pom with reduced deps. This indicates that you plan on use the pom to get the dependencies and in that case you should try to stick with the original jar instead and work with the proper set of deps. /Anders On Wed, Sep 4, 2013 at 7:42 AM, Richard Sand rs...@idfconnect.com wrote: I've a project that uses shade to create an uberjar - since I want that uberjar artifact to be available for use in other projects, does it make sense to *not* attach the artifact in shade, but rather have shade create the uberjar and dependency-reduced-pom, and then use install:install-file to grab the uberjar and drp.xml and install with a new unique artifactid (as opposed to a classifier of the original artifact)? Still feeling my way down the Maven Way... -Richard - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using a plugin twice?
And in case of the assembly-plugin you could configure multiple descriptors to generate different artifacts with one pom.xml. 2013/9/4 Richard Sand rs...@idfconnect.com Ah, too easy! I was hoping for a more difficult solution :-) -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Tuesday, September 03, 2013 6:09 PM To: Maven Users List Subject: Re: using a plugin twice? Just add the second execution with a different id On Tuesday, 3 September 2013, Richard Sand wrote: I've a feeling I know the answer at this point, but: Is it possible to use the same plugin twice in the same maven session? E.g. if I want to use maven-assembly-plugin to create two different assemblies? Or if I wanted the maven-shade-plugin to create a zip and a tarball but with slightly different contents? Or is this another case of just use two poms? Best regards, Richard - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: users-h...@maven.apache.orgjavascript:; -- Sent from my phone - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Using the invoker to test against multiple versions of a dependency
I have a maven module that builds a Lucene / Solr plugin. The POM calls for (e.g.) version 4.0.0 of Lucene. It is claimed that this plugin will work fine when integrated with, for example, version 4.4.0 of Lucene. I'd like to automatically test this without maintain multiple near-identical versions of the test rig. This strikes me as more or less an application of the invoker. Can anyone point to a model of using the invoker this way?
Re: Using the invoker to test against multiple versions of a dependency
Are you talking about maven-invoker-plugin or some other invoker? /Anders On Wed, Sep 4, 2013 at 2:17 PM, Benson Margulies bimargul...@gmail.comwrote: I have a maven module that builds a Lucene / Solr plugin. The POM calls for (e.g.) version 4.0.0 of Lucene. It is claimed that this plugin will work fine when integrated with, for example, version 4.4.0 of Lucene. I'd like to automatically test this without maintain multiple near-identical versions of the test rig. This strikes me as more or less an application of the invoker. Can anyone point to a model of using the invoker this way?
Re: How to release:perform without site publishing?
You can configure the goals to execute. Just configure that to install. /Anders (mobile) Den 4 sep 2013 16:39 skrev Paul Benedict pbened...@apache.org: I am fond of the Release plugin's ability to check out my code, tag, update the POM, and check it back in. I just don't need any site generation or publishing to a remote repository. Is it possible to skip the latter? If not, can I publish to my local repository without messing up its metadata? -- Cheers, Paul
How to release:perform without site publishing?
I am fond of the Release plugin's ability to check out my code, tag, update the POM, and check it back in. I just don't need any site generation or publishing to a remote repository. Is it possible to skip the latter? If not, can I publish to my local repository without messing up its metadata? -- Cheers, Paul
Re: [ANN] AspectJ Maven Plugin version 1.5 released
Dude. Sweet. Thanks! On Tue, Sep 3, 2013 at 3:12 PM, Lennart Jörelid lennart.jore...@gmail.comwrote: Hello all, The Mojo team is pleased to announce the release of the AspectJ Maven Plugin version 1.5. This release updates the plugin to current standards, resolving a set of outstanding bugs (c.f. release notes below). The AspectJ-Maven-Plugin weaves AspectJ aspects into your classes using the AspectJ compiler (ajc). The plugin can be included in your project by using the XML snippet below. Please refer to http://mojo.codehaus.org/aspectj-maven-plugin/index.htmlfor usage, option description and full configuration documentation. plugin groupIdorg.codehaus.mojo/groupId artifactIdaspectj-maven-plugin/artifactId version1.5/version /plugin Release Notes - Mojo's AspectJ Maven Plugin - Version 1.5 ** Bug * [MASPECTJ-4] - Corbertura Plugin fails to work when AspectJ plugin is enabled * [MASPECTJ-89] - multi-module build dependency not found - linux only * [MASPECTJ-99] - ajc error when project has no sources * [MASPECTJ-106] - Compiler warning with aspectj-maven-plugin: expected 1.6.11 found 1.6.12 * [MASPECTJ-110] - Don't add nonexistent sourceDirectory * [MASPECTJ-120] - CreateReport and CreateSite tests do not work under Java 7 ** Improvement * [MASPECTJ-11] - Make aspect:aspectj-report store working dir under target/ * [MASPECTJ-88] - Add configuration option for -xmlConfigured as well as path to aop.xml to be used for compiling * [MASPECTJ-94] - excludes could also filter aspects included in aspectLibrary * [MASPECTJ-116] - Add support for -Xset arguments * [MASPECTJ-118] - Update to handle all options available in AspectJ 1.7.2 * [MASPECTJ-121] - Update external systems referred within POM to actual values, and use parent pom's dependency versions where applicable * [MASPECTJ-122] - Include an AJC quick reference in the plugin's documentation ** New Feature * [MASPECTJ-80] - Add support for -Xajruntimelevel * [MASPECTJ-107] - Add support for ajc -xlintfile * [MASPECTJ-108] - Java 1.7 source code not supported ** Task * [MASPECTJ-117] - Update to aspectj 1.7.2 * [MASPECTJ-119] - Update to aspectj 1.7.3 Enjoy, The Mojo team. Lennart Jörelid -- +==+ | Bästa hälsningar, | [sw. Best regards] | | Lennart Jörelid | EAI Architect Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@jguru.se | URL: www.jguru.se | Phone | (skype):jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==+ -- mailto:matt...@matthewadams.me matt...@matthewadams.me skype:matthewadams12 googletalk:matt...@matthewadams.me http://matthewadams.me http://www.linkedin.com/in/matthewadams
Fail the maven build on arbitrary string output in the log
Hi all - Is there a way to fail the build if an arbitrary string shows up in the log? We have quite the cocktail of plugins and instead of editing each one to catch different problems, it'd be cooler to have an enforcer plugin run at the VERY end and fail if the build has previously logged a particular regex. Is there a way to do this? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: shade plugin usage
Hi Anders - thanks for your reply. I agree with your advice - for this particular project artifact is a case where we want to offer both options, and the uberjar is mainly an aggregation of our product apis. But I definitely understand the danger you are describing. -Richard -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Wednesday, September 04, 2013 2:08 AM To: Maven Users List Subject: Re: shade plugin usage First, try to stay away from the überjar path. It's normally not the way to go today, but you should use the jar and it's dependencies instead. I've seen many case where people use a überjar just to try to make their life simpler but ending up with other issues instead. A proper classpath is the way to go in my opinion. I guess your approach of deploying the überjar and a dep-reduced-pom would work, but please remember to deploy it to your remote repo as well (and not just your local repo). Somewhere in the back of my head I recall a similar discussion earlier. Not sure if someone brought up any issues though. Having said that, the reason for deploying the überjar at a separate coordinate would be to have a separate pom with reduced deps. This indicates that you plan on use the pom to get the dependencies and in that case you should try to stick with the original jar instead and work with the proper set of deps. /Anders On Wed, Sep 4, 2013 at 7:42 AM, Richard Sand rs...@idfconnect.com wrote: I've a project that uses shade to create an uberjar - since I want that uberjar artifact to be available for use in other projects, does it make sense to *not* attach the artifact in shade, but rather have shade create the uberjar and dependency-reduced-pom, and then use install:install-file to grab the uberjar and drp.xml and install with a new unique artifactid (as opposed to a classifier of the original artifact)? Still feeling my way down the Maven Way... -Richard - 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
