Re: How can maven be used in a continuous integration situation?
On Thursday 04 December 2008 Wayne Fay wrote: The problem with this method is that the maven install plugin only uses the version in the pom file, not the version passed in on the command line. This is noted in [this maven issue][1]. If you use mvn release rather than simply mvn install, this is handled for you via the release plugin. Since you are literally cutting a release, I think this is appropriate anyway. What is mvn release? According to [0] it's not a valid phase or lifecylce. And running it gives me [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Invalid task 'release': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal Do you mean mvn deploy? Or do you mean using the release plugin like mvn release:prepare release:perform? regards, - martin [0] http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference signature.asc Description: This is a digitally signed message part.
Re: How can maven be used in a continuous integration situation?
The latter, look at the link Wayne provided (maven-release-plugin). Cheers. 2008/12/4 Martin Höller [EMAIL PROTECTED] On Thursday 04 December 2008 Wayne Fay wrote: The problem with this method is that the maven install plugin only uses the version in the pom file, not the version passed in on the command line. This is noted in [this maven issue][1]. If you use mvn release rather than simply mvn install, this is handled for you via the release plugin. Since you are literally cutting a release, I think this is appropriate anyway. What is mvn release? According to [0] it's not a valid phase or lifecylce. And running it gives me [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Invalid task 'release': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal Do you mean mvn deploy? Or do you mean using the release plugin like mvn release:prepare release:perform? regards, - martin [0] http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
RE: Searching for good j2ee example
Ok, my in my project i use ejb3, jboss 4.2.*, jsf. My request is for migrate from netbeans to maven. I have a lot of difficult to do this migration and a sea of dubt. I know I need to mudularize my project but i don't know how exactly. Martin Gainty wrote: it would be helpful to know what the ear is supposed to accomplish web-service? connection-pooling? also which AppServer ar you deploying to? WebLogic? JBoss? Websphere? Resin? Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. Date: Wed, 3 Dec 2008 17:26:57 + Subject: Re: Re: Searching for good j2ee example From: [EMAIL PROTECTED] To: users@maven.apache.org Hi Mario, What specific examples are you after/what information do you need? What have you tried so far? Happy to help, but I don't see much point in just sending over a whole bunch of poms and associated configuration files. Cheers, Martijn On Dec 3, 2008 4:02pm, Mario Alsini [EMAIL PROTECTED] wrote: Is not important the domani of the j2ee project. I need a project with several module. In my project, for example, for now in netbeans form, i use ejb, jsf war, plain text client ... Thank you! karianna wrote: What sort of things are you after? We build several EARs in our project (which contain SAR, RAR, WAR, HAR, SAR etc) On Dec 3, 2008 3:21pm, Mario Alsini wrote: Hello, i need to see an example of medium j2ee project well done with maven. -- View this message in context: http://www.nabble.com/Searching-for-good-j2ee-example-tp20814960p20814960.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Searching-for-good-j2ee-example-tp20814960p20815798.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Send e-mail faster without improving your typing skills. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_speed_122008 -- View this message in context: http://n2.nabble.com/Searching-for-good-j2ee-example-tp1609248p1612769.html Sent from the maven users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
wagon-maven-plugin feedback requested
Hello Maven user The wagon-maven-plugin was first committed to MOJO's sandbox by James W. Dumay and continued with me. The main motivation is to provide capability to transfer artifacts between URLs during and after build. And since the implementation is generic enough, it is extended to provide the merging capability to merge a Maven repo to another including metadata with the merge logic taken from maven-stage-plugin. In the long term, it also can be easily extended to merge a subset of files from a maven repo based on groupId/artifactId/version to another maven repo. version 1.0-beta-1-SNAPSHOT has been deployed. The site is at (http://mojo.codehaus.org/wagon-maven-plugin/) Feedbacks are very welcomed. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Limitation of the release plugin?
On Wed, Dec 3, 2008 at 5:39 PM, Barrie Treloar [EMAIL PROTECTED] wrote: The alternative is to BRANCH first. This is very true and we ended up doing this as well. It allows you to lock down your code changes and then do any Maven fix-ups that you need to do before release, without having to do them on the trunk until you're sure they're OK. release:prepare/release:rollback to your heart's content, then once you're really ready to pull the trigger, release:perform and your branch transforms itself into a maintenance branch. Is there a wiki or something for best practices like this? I wish someone had told me about all this before we made all the mistakes that led us to rediscover this best practice on our own. The release plugin is picky enough that it's become another piece of the You Must Follow The Maven Way Or You Will Regret It dogma, but it's not nearly so well documented. - John Stoneham - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Limitation of the release plugin?
Todd Thiessen wrote: The first modification of the pom changes the version to remove the -SNAPSHOT and also changes the SCM values to point to the tag location instead of the trunk location. Once done, it then commits this change to trunk. To some extent I think there's a reason for this, which is so that the files will not appear to have been modified on the tag, and the tag is a straight copy of some actual SVN revision, rather than being created out of thin air from a working copy. (Of course, if you branch from a tag and have it increment the branch version numbers, it straight-up modifies the tag and then modifies it back, which bugs me.) Something similar is done when branching - version numbers are updated beforehand, then branched, so that the set of revisions on the branch doesn't include the version number change. I guess this is so when you merge over all changes on the branch to the turnk, you don't get a bunch of spurious version number changes that you'd have to ignore. Can anyone else confirm this? This seems pretty dangerous. Certainly confirmable. I guess the main danger is really if someone updates and does a 'mvn deploy' and it blows away your release version. Keeping your release deployment credentials close is good practice, so this would be pretty uncommon in the wild. But it's an issue that maybe bears rethinking nonetheless. - John Stoneham - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Limitation of the release plugin?
Todd Thiessen wrote: The first modification of the pom changes the version to remove the -SNAPSHOT and also changes the SCM values to point to the tag location instead of the trunk location. Once done, it then commits this change to trunk. To some extent I think there's a reason for this, which is so that the files will not appear to have been modified on the tag, and the tag is a straight copy of some actual SVN revision, rather than being created out of thin air from a working copy. (Of course, if you branch from a tag and have it increment the branch version numbers, it straight-up modifies the tag and then modifies it back, which bugs me.) Something similar is done when branching - version numbers are updated beforehand, then branched, so that the set of revisions on the branch doesn't include the version number change. I guess this is so when you merge over all changes on the branch to the turnk, you don't get a bunch of spurious version number changes that you'd have to ignore. Can anyone else confirm this? This seems pretty dangerous. Certainly confirmable. I guess the main danger is really if someone updates and does a 'mvn deploy' and it blows away your release version. Keeping your release deployment credentials close is good practice, so this would be pretty uncommon in the wild. But it's an issue that maybe bears rethinking nonetheless. Yes, unfortunaltley it interferes with any(most?) CI systems - as the CI System has the potential to see the release (on the trunk) and build it. All my snapshots are built and deployed by the CI system, the only way I have found to stop this is to disable the project in the CI server before the release happens - which is a bit labour intensive but better than changing all the versions and scm location by hand. /James * This e-mail is confidential, the property of NDS Ltd and intended for the addressee only. Any dissemination, copying or distribution of this message or any attachments by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please immediately notify the [EMAIL PROTECTED] and destroy the original message. Messages sent to and from NDS may be monitored. NDS cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of NDS. To protect the environment please do not print this e-mail unless necessary. NDS Limited Registered office: One Heathrow Boulevard, 286 Bath Road, West Drayton, Middlesex, UB7 0DQ, United Kingdom. A company registered in England and Wales Registered no. 3080780 VAT no. GB 603 8808 40-00 ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: Searching for good j2ee example
Hi Mario, We personally use Jboss 4.3.0.GA and a small amount of EJB2.1 and lots of Spring configured POJOs, we also have a servlet or two (WAR), JCA connectors (RAR) and a service archive that we're trying to phase out (SAR). The first thing you must have clear in your mind/layout is that Maven produces one artifact per POM. So we for example have a separate pom for the JAR, WAR, RAR, EAR etc. Start by building a project that builds your POJOs and their associated unit tests. Then take a look at the WAR plugin to see how you can take the JSF etc and build a WAR. Then take a look at the EAR plugin to see how you can bring it all together. Remember a separate pom for each of these. Definitely Read: http://books.sonatype.com/maven-book/ and BetterBuildsWithMaven.pdf (just search for this via Google) They're both relatively short documents that provide a massive amount of help and understanding. Then look at the appropriate plugins on the Maven site, eg ear, war, assembly. Their documentation is fairly clear. Good luck! On Dec 4, 2008 9:00am, Mario Alsini [EMAIL PROTECTED] wrote: Ok, my in my project i use ejb3, jboss 4.2.*, jsf. My request is for migrate from netbeans to maven. I have a lot of difficult to do this migration and a sea of dubt. I know I need to mudularize my project but i don't know how exactly. Martin Gainty wrote: it would be helpful to know what the ear is supposed to accomplish web-service? connection-pooling? also which AppServer ar you deploying to? WebLogic? JBoss? Websphere? Resin? Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. Date: Wed, 3 Dec 2008 17:26:57 + Subject: Re: Re: Searching for good j2ee example From: [EMAIL PROTECTED] To: users@maven.apache.org Hi Mario, What specific examples are you after/what information do you need? What have you tried so far? Happy to help, but I don't see much point in just sending over a whole bunch of poms and associated configuration files. Cheers, Martijn On Dec 3, 2008 4:02pm, Mario Alsini wrote: Is not important the domani of the j2ee project. I need a project with several module. In my project, for example, for now in netbeans form, i use ejb, jsf war, plain text client ... Thank you! karianna wrote: What sort of things are you after? We build several EARs in our project (which contain SAR, RAR, WAR, HAR, SAR etc) On Dec 3, 2008 3:21pm, Mario Alsini wrote: Hello, i need to see an example of medium j2ee project well done with maven. -- View this message in context: http://www.nabble.com/Searching-for-good-j2ee-example-tp20814960p20814960.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Searching-for-good-j2ee-example-tp20814960p20815798.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Send e-mail faster without improving your typing skills. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_speed_122008 -- View this message in context: http://n2.nabble.com/Searching-for-good-j2ee-example-tp1609248p1612769.html Sent from the maven users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: deploy archetype-catalog
Hi, Please consider raising a Jira Regards, Raphaël 2008/12/3 Jason Voegele [EMAIL PROTECTED]: On Wednesday 03 December 2008 01:57:48 pm Reto Bachmann-Gmür wrote: that's what I do (more exactly what continuum does), but while the archetype gets deployed to the snapshotRepository specified in the distributionManagement I find no archetype-catalog there. I can confirm this behavior. mvn deploy deploys the archetype to the repository, but the archetype-catalog.xml does not get created (or updated) in the deployment repository. -- Jason Voegele Q: What do you call a boomerang that doesn't come back? A: A stick. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: Searching for good j2ee example
Hi Martin, can you please give me which your project is? So I can study a real example. I already read the 2 books bat for me it isn't simple. With a real exsample it'll be better. martijnverburg wrote: Hi Mario, We personally use Jboss 4.3.0.GA and a small amount of EJB2.1 and lots of Spring configured POJOs, we also have a servlet or two (WAR), JCA connectors (RAR) and a service archive that we're trying to phase out (SAR). The first thing you must have clear in your mind/layout is that Maven produces one artifact per POM. So we for example have a separate pom for the JAR, WAR, RAR, EAR etc. Start by building a project that builds your POJOs and their associated unit tests. Then take a look at the WAR plugin to see how you can take the JSF etc and build a WAR. Then take a look at the EAR plugin to see how you can bring it all together. Remember a separate pom for each of these. Definitely Read: http://books.sonatype.com/maven-book/ and BetterBuildsWithMaven.pdf (just search for this via Google) They're both relatively short documents that provide a massive amount of help and understanding. Then look at the appropriate plugins on the Maven site, eg ear, war, assembly. Their documentation is fairly clear. Good luck! On Dec 4, 2008 9:00am, Mario Alsini [EMAIL PROTECTED] wrote: Ok, my in my project i use ejb3, jboss 4.2.*, jsf. My request is for migrate from netbeans to maven. I have a lot of difficult to do this migration and a sea of dubt. I know I need to mudularize my project but i don't know how exactly. Martin Gainty wrote: it would be helpful to know what the ear is supposed to accomplish web-service? connection-pooling? also which AppServer ar you deploying to? WebLogic? JBoss? Websphere? Resin? Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. Date: Wed, 3 Dec 2008 17:26:57 + Subject: Re: Re: Searching for good j2ee example From: [EMAIL PROTECTED] To: users@maven.apache.org Hi Mario, What specific examples are you after/what information do you need? What have you tried so far? Happy to help, but I don't see much point in just sending over a whole bunch of poms and associated configuration files. Cheers, Martijn On Dec 3, 2008 4:02pm, Mario Alsini wrote: Is not important the domani of the j2ee project. I need a project with several module. In my project, for example, for now in netbeans form, i use ejb, jsf war, plain text client ... Thank you! karianna wrote: What sort of things are you after? We build several EARs in our project (which contain SAR, RAR, WAR, HAR, SAR etc) On Dec 3, 2008 3:21pm, Mario Alsini wrote: Hello, i need to see an example of medium j2ee project well done with maven. -- View this message in context: http://www.nabble.com/Searching-for-good-j2ee-example-tp20814960p20814960.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Searching-for-good-j2ee-example-tp20814960p20815798.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Send e-mail faster without improving your typing skills. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_speed_122008 -- View this message in context: http://n2.nabble.com/Searching-for-good-j2ee-example-tp1609248p1612769.html Sent from the maven users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context:
[maven-war-plugin] maven still wants to use 2.1-alpha-1
Hello, I'd been waiting for a bug fix that has been added to 2.1-alpha-2, which is great. Although this version has been released, my maven keeps on using the 2.1-alpha-1. I tried anything I could : - delete my local repository so that anything is downloaded again - searched if I specified a plugin version in any of my pom No way. Can someone help me ? regards, domConsultez nos nouveaux sites internet : http://www.dexia-sofaxis.com http://www.dexia-sofcap-sofcah.com Tous ensemble pour l’environnement : n’imprimer ce courriel que si nécessaire. Dexia Sofaxis disclaimer : http://www.dexia-sofaxis.com/disclaimer.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Limitation of the release plugin?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Stoneham To some extent I think there's a reason for this, which is so that the files will not appear to have been modified on the tag, and the tag is a straight copy of some actual SVN revision, rather than being created out of thin air from a working copy. I believe Maven intentially does an svn working dopy, not a copy from an SVN revision. If you look closely at the output from a prepare, you will see a line something like this: [INFO] Executing: svn --non-interactive copy --file D:\yourtempdir\maven-scm-791753447.commit . https://yoursvnserver/project/tags/project-1.0.0 Notice that it copies from . (BTW. There seems to be a bug with SVN working copies. You can read about that here [1]). Doing a copy from your working directory, however, is important. If you did a copy from an SVN revision you could potentially release something you didn't intend if someone commits to that revision after the you checked out your working copy from that revion, but before you performed the release. [1] http://jira.codehaus.org/browse/SCM-406 --- Todd Thiessen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: RE: Searching for good j2ee example
I'll post this to everyone as people can search this archive and maybe get
some help from it.
Disclaimer: I am NOT a Maven expert, I'm sure there are several best
practices that I'm breaking here,
so take this with a grain of salt please.
OK, let's start with the basics, you'll need a project layout something
similar to this:
projectname
/ejb
/environment
/jar
/war
/ear
distribution.xml
pom.xml
project.properties
Each of those sub directories will be maven projects in their own right.
The pom.xml at the root of the project is a
parent pom that can wrap it all together and provide some
environmentalisation for it.
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
groupIdorg.martijnverburg/groupId
artifactIdmartijnverburg-parent/artifactId
version0.0.1/version
packagingpom/packaging
namemartijnverburg : Parent Project/name
modules
modulejar/module
moduleejb/module
modulewar/module
moduleear/module
/modules
build
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
configuration
finalNamemartijnverburg-${server}-${env}/finalName
filters
filterproject.properties/filter
filterenvironment/${server}/${env}/environment.properties/filter
/filters
descriptors
descriptordistribution.xml/descriptor
/descriptors
/configuration
/plugin
/plugins
/build
/project
A Couple of Notes:
1,) project.properties is a hint to you that you need to think about have
environmentalised builds. A file like
project.properties is a _very_ simple step towards this. Normally you would
use build profiles or (as we do)
use several environment properties files (we reference which ones we want
by passing in -D parameter on the command line,
as you can see we pass in the $server and $env variables). You may not need
this.
2,) distribution.xml is used for assembly purposes, see the maven:assembly
plugin for details. We use this as
we not only distribute an EAR but also several configuration files as part
of out project. You may not need this.
In the next post I'll go through the jar project/pom, for dealing with your
POJOs
Cheers,
Martijn
On Dec 4, 2008 1:53pm, Mario Alsini [EMAIL PROTECTED] wrote:
Hi Martin,
can you please give me which your project is?
So I can study a real example.
I already read the 2 books bat for me it isn't simple.
With a real exsample it'll be better.
Re: Limitation of the release plugin?
Doing a copy from your working directory, however, is important. If you did a copy from an SVN revision you could potentially release something you didn't intend if someone commits to that revision after the you checked out your working copy from that revion, but before you performed the release. If the release plugin did a copy of the revision there would be no problem. The problem is that you cannot make a copy of the HEAD revision. You cannot commit anymore to any revision (It would make a new revision) Hth, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Thu, Dec 4, 2008 at 3:16 PM, Todd Thiessen [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Stoneham To some extent I think there's a reason for this, which is so that the files will not appear to have been modified on the tag, and the tag is a straight copy of some actual SVN revision, rather than being created out of thin air from a working copy. I believe Maven intentially does an svn working dopy, not a copy from an SVN revision. If you look closely at the output from a prepare, you will see a line something like this: [INFO] Executing: svn --non-interactive copy --file D:\yourtempdir\maven-scm-791753447.commit . https://yoursvnserver/project/tags/project-1.0.0 Notice that it copies from . (BTW. There seems to be a bug with SVN working copies. You can read about that here [1]). Doing a copy from your working directory, however, is important. If you did a copy from an SVN revision you could potentially release something you didn't intend if someone commits to that revision after the you checked out your working copy from that revion, but before you performed the release. [1] http://jira.codehaus.org/browse/SCM-406 --- Todd Thiessen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [maven-war-plugin] maven still wants to use 2.1-alpha-1
Try, mvn help:effective-pom You will see that your war plugin is set to a fixed version. This has been a fix in 2.0.8 or 2.0.9. The default plugins have a fixed version, to make reproducible builds more likely. If you want to override the version you have to specify it in your pom, or any parent poms you may have (like a company pom or such). Hth, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl 2008/12/4 DJP JEAN-PROST Dominique [EMAIL PROTECTED]: Hello, I'd been waiting for a bug fix that has been added to 2.1-alpha-2, which is great. Although this version has been released, my maven keeps on using the 2.1-alpha-1. I tried anything I could : - delete my local repository so that anything is downloaded again - searched if I specified a plugin version in any of my pom No way. Can someone help me ? regards, dom Consultez nos nouveaux sites internet : http://www.dexia-sofaxis.com http://www.dexia-sofcap-sofcah.com Tous ensemble pour l'environnement : n'imprimer ce courriel que si nécessaire. Dexia Sofaxis disclaimer : http://www.dexia-sofaxis.com/disclaimer.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Limitation of the release plugin?
Have anyone considered changing the release plugin such that it does not commit the changes to the POM which removes SNAPSHOT from the version? The only negative I can see is that you don't see a history of this change in your trunk. But this shouldn't matter since you have a copy of this POM in your tags. In fact, this makes more sense to me anyway. I don't like seeing a released version of my POM in my trunk history. So to be clear, the steps would be changed to this (roughly): 1. Make changes to the POM in your working copy to remove SNAPSHOT from the version and make changes to your SCM entries to point to your tags instead of your trunk. (Same) 2. DO NOT commit this change back to trunk. (Different). 3. Do an svn copy of your working directory to your tags, just as it does today. (Same) 4. ... continue as normal Are there any negatives to this that I have overlooked? --- Todd Thiessen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Limitation of the release plugin?
If you did a revision copy, you would have to do commit to capture the changes to the POM. You couldn't do a straight revision copy. So the situation now become more complicated. If you checkout revision x, someone may commit before you release incrementing the revision to x+1. You then run your prepare, incrementing the revision to x+2 to change the version of your pom to a released version. So you now have to copy revision x+2 of your pom to your tags folder but use revision x for everything else. The best solution I see is to not commit the changes to the POM which changes the version to a released version and continue to do a working copy as the plugin does now. Thoughts? --- Todd Thiessen -Original Message- From: Nick Stolwijk [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 9:22 AM To: Maven Users List Subject: Re: Limitation of the release plugin? Doing a copy from your working directory, however, is important. If you did a copy from an SVN revision you could potentially release something you didn't intend if someone commits to that revision after the you checked out your working copy from that revion, but before you performed the release. If the release plugin did a copy of the revision there would be no problem. The problem is that you cannot make a copy of the HEAD revision. You cannot commit anymore to any revision (It would make a new revision) Hth, Nick Stolwijk ~Java Developer~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Nexus Publish Indexes
Hi Todd, I swear I answered this yep: http://www.nabble.com/Publish-Indexes---td20800360ef34838.html --Brian -Original Message- From: Todd Thiessen [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2008 5:53 AM To: Maven Users List Subject: Nexus Publish Indexes I asked this question on the nexus users list but didn't get a response. Since Nexus and Maven are closely related, I hope you guys don't mind if I ask it here. I was going through the definitive guide and noticed that under scheduling, there is a task called Publish Indexes. The description in the guide is somewhat limited. What does Publish Indexes mean? How is this different from simply rebuilding the index? --- Todd Thiessen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven Flex Plugin 2.0 released.
The ServeBox.org team is pleased to announce the release of the Maven Flex Plugin 2.0. http://www.servebox.org/2008/12/maven-flex-plugin-200-released/ The Flex plugin empower the developers to use Maven 2.0 for Flex development. This new version fixes some previous bugs and add new functionalities such as: * Documentation added : Flex Unit, ASDoc for aggregators, ASDoc template, Eclipse mojo. * Added documentation about ASdoc and reports * Reports for ASDoc and aggregator ASDoc * Eclipse project descriptors generation, including multi-module projects * Unit testing refactored * Adobe Flex SDK Compiler API embedded * Several bug fixes (including tests running under Linux, many thanks to Stephen More for the original patch) * Compiler options management refactored to match Maven conventions Regards, Eric Hartmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Nexus Publish Indexes
Thanks for the answer. I didn't recieve that response though. I just went through my inbox. Our corporation mailer may have blocked it. Even on the nabble site, there is a security warning on your response. WRT your resonse though, that does answer my question, thank you. I was always wondering how to create an index for a group since I didn't see that option when I right clicked on a group. This is good to know. BTW. Is it possible to do this without using the scheduler? Wouldn't it make sense to have a create index option when you right click on a group so the user can do it manually? The other thing I would like to ask about is this comment: The internal indexes are always updated in realtime... Do you mean the Nexus hosted drepository indexes? If so, I have not observed this behaviour. For instance, if I deploy an artifact to my Nexus repository, it does not automatically update the index. I have always had to re-index it manually. Thats actually why I started to look at the scheduler to see if I could at least semi-automate it. --- Todd Thiessen -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 10:17 AM To: Maven Users List Subject: RE: Nexus Publish Indexes Hi Todd, I swear I answered this yep: http://www.nabble.com/Publish-Indexes---td20800360ef34838.html --Brian -Original Message- From: Todd Thiessen [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2008 5:53 AM To: Maven Users List Subject: Nexus Publish Indexes I asked this question on the nexus users list but didn't get a response. Since Nexus and Maven are closely related, I hope you guys don't mind if I ask it here. I was going through the definitive guide and noticed that under scheduling, there is a task called Publish Indexes. The description in the guide is somewhat limited. What does Publish Indexes mean? How is this different from simply rebuilding the index? --- Todd Thiessen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: qdox-current.jar is missing from repo1.maven.org
Use your browser to check things... Wget isn't allowed on central. It's available here: http://repo1.maven.org/maven2/vdoclet/qdox/current/ and I adjusted the rewrite so your url below works correctly. -Original Message- From: Chris Helck [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2008 6:16 AM To: Maven Users List Subject: qdox-current.jar is missing from repo1.maven.org What happened to http://repo1.maven.org/maven/vdoclet/jars/qdoc-current.jar ? When I wget it I get a 403 Forbidden error. This used to work -- just a few weeks ago. I can no longer create site documentation for maven1 projects. Thanks, C. Helck ** This communication and all information (including, but not limited to, market prices/levels and data) contained therein (the Information) is for informational purposes only, is confidential, may be legally privileged and is the intellectual property of ICAP plc and its affiliates (ICAP) or third parties. No confidentiality or privilege is waived or lost by any mistransmission. The Information is not, and should not be construed as, an offer, bid or solicitation in relation to any financial instrument or as an official confirmation of any transaction. The Information is not warranted, including, but not limited, as to completeness, timeliness or accuracy and is subject to change without notice. ICAP assumes no liability for use or misuse of the Information. All representations and warranties are expressly disclaimed. The Information does not necessarily reflect the views of ICAP. Access to the Information by anyone else other than the recipient is unauthorized and any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [maven-war-plugin] maven still wants to use 2.1-alpha-1
If you're using 2.0.9, then the default versions are set to prevent accidental upgrades. See the release notes for more details. Specifying the version in your pom will work. -Original Message- From: DJP JEAN-PROST Dominique [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 5:37 AM To: users@maven.apache.org Subject: [maven-war-plugin] maven still wants to use 2.1-alpha-1 Hello, I'd been waiting for a bug fix that has been added to 2.1-alpha-2, which is great. Although this version has been released, my maven keeps on using the 2.1-alpha-1. I tried anything I could : - delete my local repository so that anything is downloaded again - searched if I specified a plugin version in any of my pom No way. Can someone help me ? regards, dom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Eclipse plugin versions wrong in mvn eclipse:make-artifacts
Hello, I'm using eclipse:make-artifacts to install some plugins in the local repository. I want the artifacts to look like this: groupIdorg.eclipse.core/groupId artifactIdorg.eclipse.core.runtime/artifactId version3.4.0-v2008051/version I want the dependencies to have the same structure (including exact versions, not ranges of versions). The command I use is this: mvn eclipse:make-artifacts -DeclipseDir=D:\eclipse -DstripQualifier=false -DresolveVersionRanges=true I use it on a Eclipse 3.4 install. The result is this: groupIdorg.eclipse.core/groupId artifactIdorg.eclipse.core.runtime/artifactId nameCore Runtime/name version3.4.0-v2008051/version dependencies dependency groupIdorg.eclipse.osgi/groupId artifactIdorg.eclipse.osgi/artifactId version[3.2.0,4.0.0)/version /dependency I don't like the dependency range. It looks like DresolveVersionRanges=true is not working. Is it a bug in maven-eclipse-plugin, or am I doing something wrong? Thank you, Costin. -- View this message in context: http://www.nabble.com/Eclipse-plugin-versions-wrong-in-mvn-eclipse%3Amake-artifacts-tp20835865p20835865.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Nexus Publish Indexes
BTW. Is it possible to do this without using the scheduler? Wouldn't it make sense to have a create index option when you right click on a group so the user can do it manually? The group index is created automatically when there's a group made and any reindex on the group will also update it, but it will also reindex all the repos in the group. This is why we separated the publish step from a full reindex. Since the index is created automatically, there's no need for a create index option. The other thing I would like to ask about is this comment: The internal indexes are always updated in realtime... Do you mean the Nexus hosted drepository indexes? If so, I have not observed this behaviour. For instance, if I deploy an artifact to my Nexus repository, it does not automatically update the index. I have always had to re-index it manually. Thats actually why I started to look at the scheduler to see if I could at least semi-automate it. I mean the indexes that Nexus uses internally. If you deploy something and then go to the Nexus UI and search for it, it should be there immediately with no further action. If you're pulling the index into m2e, then the publish needs to occur for the previously mentioned reasons. If you see that it is not indexed immediately and visible from the UI, check that the user you are logged in to the UI has permissions to the repo where it exists (the search results are filtered based on permissions). If you still have problems, then lets discuss more debugging on the Nexus User list. --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Limitation of the release plugin?
Many scm's don't let you commit changes to tags, which is why it commits to trunk first and then tags. -Original Message- From: Todd Thiessen [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 6:18 AM To: Maven Users List Subject: RE: Limitation of the release plugin? Have anyone considered changing the release plugin such that it does not commit the changes to the POM which removes SNAPSHOT from the version? The only negative I can see is that you don't see a history of this change in your trunk. But this shouldn't matter since you have a copy of this POM in your tags. In fact, this makes more sense to me anyway. I don't like seeing a released version of my POM in my trunk history. So to be clear, the steps would be changed to this (roughly): 1. Make changes to the POM in your working copy to remove SNAPSHOT from the version and make changes to your SCM entries to point to your tags instead of your trunk. (Same) 2. DO NOT commit this change back to trunk. (Different). 3. Do an svn copy of your working directory to your tags, just as it does today. (Same) 4. ... continue as normal Are there any negatives to this that I have overlooked? --- Todd Thiessen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Limitation of the release plugin?
My suggestion though is to not commit at all. Just do a working copy. So no commit to tags would be required. --- Todd Thiessen -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 10:42 AM To: Maven Users List Subject: RE: Limitation of the release plugin? Many scm's don't let you commit changes to tags, which is why it commits to trunk first and then tags. -Original Message- From: Todd Thiessen [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 6:18 AM To: Maven Users List Subject: RE: Limitation of the release plugin? Have anyone considered changing the release plugin such that it does not commit the changes to the POM which removes SNAPSHOT from the version? The only negative I can see is that you don't see a history of this change in your trunk. But this shouldn't matter since you have a copy of this POM in your tags. In fact, this makes more sense to me anyway. I don't like seeing a released version of my POM in my trunk history. So to be clear, the steps would be changed to this (roughly): 1. Make changes to the POM in your working copy to remove SNAPSHOT from the version and make changes to your SCM entries to point to your tags instead of your trunk. (Same) 2. DO NOT commit this change back to trunk. (Different). 3. Do an svn copy of your working directory to your tags, just as it does today. (Same) 4. ... continue as normal Are there any negatives to this that I have overlooked? --- Todd Thiessen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can maven be used in a continuous integration situation?
Are you suggesting that our CI server performs a 'mvn release' nightly? From the documentation that you linked to it seems like this is not intended to be an automated process, as there are several steps that prompt the user for information. I assume that you can provide this information on the command line? Regardless of this issue, what is standard practice in this situation? We want a CI server to use maven to produce regular versioned builds of a project that is a dependency of other projects. Is there something about this that doesn't fin in the maven philosophy? Thanks. Matthew Jaskula t +1 212.542.8299 From: Wayne Fay [EMAIL PROTECTED] Reply-To: Maven Users List users@maven.apache.org Date: Wed, 3 Dec 2008 16:35:01 -0800 To: Maven Users List users@maven.apache.org Subject: Re: How can maven be used in a continuous integration situation? The problem with this method is that the maven install plugin only uses the version in the pom file, not the version passed in on the command line. This is noted in [this maven issue][1]. If you use mvn release rather than simply mvn install, this is handled for you via the release plugin. Since you are literally cutting a release, I think this is appropriate anyway. mvn install only installs the artifacts in the local repo cache. mvn release does a lot more. You probably want to use the batch mode: http://maven.apache.org/plugins/maven-release-plugin/howto.html Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Visit our website at http://www.nyse.com Note: The information contained in this message and any attachment to it is privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to the message, and please delete it from your system. Thank you. NYSE Euronext, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Limitation of the release plugin?
Yeah but it sounds like you're thinking in svn terms only. This might not work for all scms. -Original Message- From: Todd Thiessen [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 7:45 AM To: Maven Users List Subject: RE: Limitation of the release plugin? My suggestion though is to not commit at all. Just do a working copy. So no commit to tags would be required. --- Todd Thiessen -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 10:42 AM To: Maven Users List Subject: RE: Limitation of the release plugin? Many scm's don't let you commit changes to tags, which is why it commits to trunk first and then tags. -Original Message- From: Todd Thiessen [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 6:18 AM To: Maven Users List Subject: RE: Limitation of the release plugin? Have anyone considered changing the release plugin such that it does not commit the changes to the POM which removes SNAPSHOT from the version? The only negative I can see is that you don't see a history of this change in your trunk. But this shouldn't matter since you have a copy of this POM in your tags. In fact, this makes more sense to me anyway. I don't like seeing a released version of my POM in my trunk history. So to be clear, the steps would be changed to this (roughly): 1. Make changes to the POM in your working copy to remove SNAPSHOT from the version and make changes to your SCM entries to point to your tags instead of your trunk. (Same) 2. DO NOT commit this change back to trunk. (Different). 3. Do an svn copy of your working directory to your tags, just as it does today. (Same) 4. ... continue as normal Are there any negatives to this that I have overlooked? --- Todd Thiessen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Limitation of the release plugin?
And it won't work on SVN 1.5.x - Original Message - From: Brian E. Fox [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Thu Dec 04 10:53:03 2008 Subject: RE: Limitation of the release plugin? Yeah but it sounds like you're thinking in svn terms only. This might not work for all scms. -Original Message- From: Todd Thiessen [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 7:45 AM To: Maven Users List Subject: RE: Limitation of the release plugin? My suggestion though is to not commit at all. Just do a working copy. So no commit to tags would be required. --- Todd Thiessen -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 10:42 AM To: Maven Users List Subject: RE: Limitation of the release plugin? Many scm's don't let you commit changes to tags, which is why it commits to trunk first and then tags. -Original Message- From: Todd Thiessen [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 6:18 AM To: Maven Users List Subject: RE: Limitation of the release plugin? Have anyone considered changing the release plugin such that it does not commit the changes to the POM which removes SNAPSHOT from the version? The only negative I can see is that you don't see a history of this change in your trunk. But this shouldn't matter since you have a copy of this POM in your tags. In fact, this makes more sense to me anyway. I don't like seeing a released version of my POM in my trunk history. So to be clear, the steps would be changed to this (roughly): 1. Make changes to the POM in your working copy to remove SNAPSHOT from the version and make changes to your SCM entries to point to your tags instead of your trunk. (Same) 2. DO NOT commit this change back to trunk. (Different). 3. Do an svn copy of your working directory to your tags, just as it does today. (Same) 4. ... continue as normal Are there any negatives to this that I have overlooked? --- Todd Thiessen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Limitation of the release plugin?
Am I? I didn't think I was. Doing a copy of the working directory though is a corner stone of how maven release plugin works. If an SCM doesn't support it, then the plugin would be flakey at best or not work outright at worst. --- Todd Thiessen -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 10:53 AM To: Maven Users List Subject: RE: Limitation of the release plugin? Yeah but it sounds like you're thinking in svn terms only. This might not work for all scms. -Original Message- From: Todd Thiessen [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 7:45 AM To: Maven Users List Subject: RE: Limitation of the release plugin? My suggestion though is to not commit at all. Just do a working copy. So no commit to tags would be required. --- Todd Thiessen -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 10:42 AM To: Maven Users List Subject: RE: Limitation of the release plugin? Many scm's don't let you commit changes to tags, which is why it commits to trunk first and then tags. -Original Message- From: Todd Thiessen [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 6:18 AM To: Maven Users List Subject: RE: Limitation of the release plugin? Have anyone considered changing the release plugin such that it does not commit the changes to the POM which removes SNAPSHOT from the version? The only negative I can see is that you don't see a history of this change in your trunk. But this shouldn't matter since you have a copy of this POM in your tags. In fact, this makes more sense to me anyway. I don't like seeing a released version of my POM in my trunk history. So to be clear, the steps would be changed to this (roughly): 1. Make changes to the POM in your working copy to remove SNAPSHOT from the version and make changes to your SCM entries to point to your tags instead of your trunk. (Same) 2. DO NOT commit this change back to trunk. (Different). 3. Do an svn copy of your working directory to your tags, just as it does today. (Same) 4. ... continue as normal Are there any negatives to this that I have overlooked? --- Todd Thiessen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Limitation of the release plugin?
What won't? --- Todd Thiessen -Original Message- From: Edelson, Justin [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 10:55 AM To: users@maven.apache.org Subject: Re: Limitation of the release plugin? And it won't work on SVN 1.5.x - Original Message - From: Brian E. Fox [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Thu Dec 04 10:53:03 2008 Subject: RE: Limitation of the release plugin? Yeah but it sounds like you're thinking in svn terms only. This might not work for all scms. -Original Message- From: Todd Thiessen [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 7:45 AM To: Maven Users List Subject: RE: Limitation of the release plugin? My suggestion though is to not commit at all. Just do a working copy. So no commit to tags would be required. --- Todd Thiessen -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 10:42 AM To: Maven Users List Subject: RE: Limitation of the release plugin? Many scm's don't let you commit changes to tags, which is why it commits to trunk first and then tags. -Original Message- From: Todd Thiessen [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 6:18 AM To: Maven Users List Subject: RE: Limitation of the release plugin? Have anyone considered changing the release plugin such that it does not commit the changes to the POM which removes SNAPSHOT from the version? The only negative I can see is that you don't see a history of this change in your trunk. But this shouldn't matter since you have a copy of this POM in your tags. In fact, this makes more sense to me anyway. I don't like seeing a released version of my POM in my trunk history. So to be clear, the steps would be changed to this (roughly): 1. Make changes to the POM in your working copy to remove SNAPSHOT from the version and make changes to your SCM entries to point to your tags instead of your trunk. (Same) 2. DO NOT commit this change back to trunk. (Different). 3. Do an svn copy of your working directory to your tags, just as it does today. (Same) 4. ... continue as normal Are there any negatives to this that I have overlooked? --- Todd Thiessen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Limitation of the release plugin?
Copying a working copy with uncommitted changes. It's part the SCM-406 issue. - Original Message - From: Todd Thiessen [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Thu Dec 04 10:57:19 2008 Subject: RE: Limitation of the release plugin? What won't? --- Todd Thiessen -Original Message- From: Edelson, Justin [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 10:55 AM To: users@maven.apache.org Subject: Re: Limitation of the release plugin? And it won't work on SVN 1.5.x - Original Message - From: Brian E. Fox [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Thu Dec 04 10:53:03 2008 Subject: RE: Limitation of the release plugin? Yeah but it sounds like you're thinking in svn terms only. This might not work for all scms. -Original Message- From: Todd Thiessen [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 7:45 AM To: Maven Users List Subject: RE: Limitation of the release plugin? My suggestion though is to not commit at all. Just do a working copy. So no commit to tags would be required. --- Todd Thiessen -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 10:42 AM To: Maven Users List Subject: RE: Limitation of the release plugin? Many scm's don't let you commit changes to tags, which is why it commits to trunk first and then tags. -Original Message- From: Todd Thiessen [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 6:18 AM To: Maven Users List Subject: RE: Limitation of the release plugin? Have anyone considered changing the release plugin such that it does not commit the changes to the POM which removes SNAPSHOT from the version? The only negative I can see is that you don't see a history of this change in your trunk. But this shouldn't matter since you have a copy of this POM in your tags. In fact, this makes more sense to me anyway. I don't like seeing a released version of my POM in my trunk history. So to be clear, the steps would be changed to this (roughly): 1. Make changes to the POM in your working copy to remove SNAPSHOT from the version and make changes to your SCM entries to point to your tags instead of your trunk. (Same) 2. DO NOT commit this change back to trunk. (Different). 3. Do an svn copy of your working directory to your tags, just as it does today. (Same) 4. ... continue as normal Are there any negatives to this that I have overlooked? --- Todd Thiessen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
POM dependency issue (Reactor)
This is my dilemna, ca anyone shed some light?
I have the following configuration of POMs
bigparentPOM --- common
parentPOM 1 (depends on common)
parentPOM 2 (depends on common)
ParentPOM 1 and 2 are dependent on common, but sometimes they also need to
be compiled separately. I I want to build only parentPOM1 and need to
recompile common, how can I do it??? For now we have to recompile
everything from bigparentPOM.
Can I configure my POM hierarchies in another way to be able to compile ONLY
parentPOM1 and common OR ONLY parentPOM2 and common
Thanks in advance for your help
--
View this message in context:
http://www.nabble.com/POM-dependency-issue-%28Reactor%29-tp20836626p20836626.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: RE: Searching for good j2ee example
OK, the directory structure of you project under the jar directory will
probably look something like this:
src/main/java
src/main/resources
src//test/java
src/test/resources
OK, the next part, a POM for your POJOs
?xml version=1.0 encoding=UTF-8?
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
groupIdmartijnverburg/groupId
artifactIdmartijnverburg-jar/artifactId
packagingjar/packaging
version0.0.1/version
namemartijnverburg : jar/name
build
!-- We want to do some filtering on our config files --
resources
resource
directorysrc/main/resources/directory
filteringtrue/filtering
/resource
/resources
filters
!-- The filters live here --
filter../../project.properties/filter
filter../module.properties/filter
/filters
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.5/source
target1.5/target
/configuration
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version2.0/version
/plugin
/plugins
/build
dependencies
!-- Logging library --
dependency
groupIdlog4j/groupId
artifactIdlog4j/artifactId
version1.2.14/version
scopeprovided/scope
/dependency
/dependency
..
..
..
Lots more dependencies
/dependencies
/project
Our real POM is actually massive with all sorts of code coverage plugins,
test plugins, reporting plugins, developer and license info etc etc. But
you can pick up most of that from the maven docs on the website.
Right, Have a go at build that first and let us know how you get on. We can
then walk through the WAR and EAR poms/projects.
Cheers,
Martijn
On Dec 4, 2008 2:17pm, [EMAIL PROTECTED] wrote:
I'll post this to everyone as people can search this archive and maybe
get some help from it.
Disclaimer: I am NOT a Maven expert, I'm sure there are several best
practices that I'm breaking here,
so take this with a grain of salt please.
OK, let's start with the basics, you'll need a project layout something
similar to this:
projectname
/ejb
/environment
/jar
/war
/ear
distribution.xml
pom.xml
project.properties
Each of those sub directories will be maven projects in their own right.
The pom.xml at the root of the project is a
parent pom that can wrap it all together and provide some
environmentalisation for it.
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;
4.0.0modelVersion
org.martijnverburggroupId
martijnverburg-parent
0.0.1
pom
martijnverburg : Parent Project
jar
ejb
war
ear
maven-assembly-plugin
martijnverburg-${server}-${env}
project.propertiesfilter
environment/${server}/${env}/environment.properties/filter
distribution.xmldescriptor
A Couple of Notes:
1,) project.properties is a hint to you that you need to think about have
environmentalised builds. A file like
project.properties is a _very_ simple step towards this. Normally you
would use build profiles or (as we do)
use several environment properties files (we reference which ones we want
by passing in -D parameter on the command line,
as you can see we pass in the $server and $env variables). You may not
need this.
2,) distribution.xml is used for assembly purposes, see the
maven:assembly plugin for details. We use this as
we not only distribute an EAR but also several configuration files as
part of out project. You may not need this.
In the next post I'll go through the jar project/pom, for dealing with
your POJOs
Cheers,
Martijn
On Dec 4, 2008 1:53pm, Mario Alsini [EMAIL PROTECTED] wrote:
Hi Martin,
can you please give me which your project is?
So I can study a real example.
I already read the 2 books bat for me it isn't simple.
With a real exsample it'll be better.
Attaching artifacts
Is there anyway to attach an artifact without writing a mojo to do it? I would like to just do it with the pom if possible. Liz Sommers [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Limitation of the release plugin?
Not so. Doing a working copy with uncommited changes actually does work with SVN 1.5.4. But it may be not supported in other SCMs. That I can understand. The term working copy does normally include uncommited files though. --- Todd Thiessen -Original Message- From: Edelson, Justin [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 11:09 AM To: users@maven.apache.org Subject: Re: Limitation of the release plugin? Copying a working copy with uncommitted changes. It's part the SCM-406 issue. - Original Message - From: Todd Thiessen [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Thu Dec 04 10:57:19 2008 Subject: RE: Limitation of the release plugin? What won't? --- Todd Thiessen -Original Message- From: Edelson, Justin [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 10:55 AM To: users@maven.apache.org Subject: Re: Limitation of the release plugin? And it won't work on SVN 1.5.x - Original Message - From: Brian E. Fox [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Thu Dec 04 10:53:03 2008 Subject: RE: Limitation of the release plugin? Yeah but it sounds like you're thinking in svn terms only. This might not work for all scms. -Original Message- From: Todd Thiessen [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 7:45 AM To: Maven Users List Subject: RE: Limitation of the release plugin? My suggestion though is to not commit at all. Just do a working copy. So no commit to tags would be required. --- Todd Thiessen -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 10:42 AM To: Maven Users List Subject: RE: Limitation of the release plugin? Many scm's don't let you commit changes to tags, which is why it commits to trunk first and then tags. -Original Message- From: Todd Thiessen [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 6:18 AM To: Maven Users List Subject: RE: Limitation of the release plugin? Have anyone considered changing the release plugin such that it does not commit the changes to the POM which removes SNAPSHOT from the version? The only negative I can see is that you don't see a history of this change in your trunk. But this shouldn't matter since you have a copy of this POM in your tags. In fact, this makes more sense to me anyway. I don't like seeing a released version of my POM in my trunk history. So to be clear, the steps would be changed to this (roughly): 1. Make changes to the POM in your working copy to remove SNAPSHOT from the version and make changes to your SCM entries to point to your tags instead of your trunk. (Same) 2. DO NOT commit this change back to trunk. (Different). 3. Do an svn copy of your working directory to your tags, just as it does today. (Same) 4. ... continue as normal Are there any negatives to this that I have overlooked? --- Todd Thiessen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can maven be used in a continuous integration situation?
On Thu, Dec 4, 2008 at 10:29 AM, Matthew Jaskula [EMAIL PROTECTED] wrote: Are you suggesting that our CI server performs a 'mvn release' nightly? From the documentation that you linked to it seems like this is not intended to be an automated process, as there are several steps that prompt the user for information. I assume that you can provide this information on the command line? There is a batch mode in the release plugin - see http://maven.apache.org/plugins/maven-release-plugin/howto.html . You could do a release:prepare/perform, or release:prepare/stage. You would probably want to use a profile that sets autoVersionSubmodules and configures the developmentVersion and releaseVersion parameters. I kind of wish there was a way to do this WITHOUT committing and doing the tag somehow. You might have to do it by hand. Maybe a new plugin? - John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Attaching artifacts
If your Maven POJO is a representation of a goal then a qualified 'yes' example located here http://maven.apache.org/maven-1.x/plugins/artifact/examples.html The bigger question is Why execute a build script with no associated goal ? Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. Subject: Attaching artifacts Date: Thu, 4 Dec 2008 11:25:31 -0500 From: [EMAIL PROTECTED] To: users@maven.apache.org Is there anyway to attach an artifact without writing a mojo to do it? I would like to just do it with the pom if possible. Liz Sommers [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Send e-mail faster without improving your typing skills. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_speed_122008
Re: Limitation of the release plugin?
Could have sworn I tested that. In any case, apologies for the bad info. I think it would be reasonably easy to create a custom release plugin that worked in the way you're describing. - Original Message - From: Todd Thiessen [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Thu Dec 04 11:18:59 2008 Subject: RE: Limitation of the release plugin? Not so. Doing a working copy with uncommited changes actually does work with SVN 1.5.4. But it may be not supported in other SCMs. That I can understand. The term working copy does normally include uncommited files though. --- Todd Thiessen -Original Message- From: Edelson, Justin [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 11:09 AM To: users@maven.apache.org Subject: Re: Limitation of the release plugin? Copying a working copy with uncommitted changes. It's part the SCM-406 issue. - Original Message - From: Todd Thiessen [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Thu Dec 04 10:57:19 2008 Subject: RE: Limitation of the release plugin? What won't? --- Todd Thiessen -Original Message- From: Edelson, Justin [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 10:55 AM To: users@maven.apache.org Subject: Re: Limitation of the release plugin? And it won't work on SVN 1.5.x - Original Message - From: Brian E. Fox [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Thu Dec 04 10:53:03 2008 Subject: RE: Limitation of the release plugin? Yeah but it sounds like you're thinking in svn terms only. This might not work for all scms. -Original Message- From: Todd Thiessen [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 7:45 AM To: Maven Users List Subject: RE: Limitation of the release plugin? My suggestion though is to not commit at all. Just do a working copy. So no commit to tags would be required. --- Todd Thiessen -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 10:42 AM To: Maven Users List Subject: RE: Limitation of the release plugin? Many scm's don't let you commit changes to tags, which is why it commits to trunk first and then tags. -Original Message- From: Todd Thiessen [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 6:18 AM To: Maven Users List Subject: RE: Limitation of the release plugin? Have anyone considered changing the release plugin such that it does not commit the changes to the POM which removes SNAPSHOT from the version? The only negative I can see is that you don't see a history of this change in your trunk. But this shouldn't matter since you have a copy of this POM in your tags. In fact, this makes more sense to me anyway. I don't like seeing a released version of my POM in my trunk history. So to be clear, the steps would be changed to this (roughly): 1. Make changes to the POM in your working copy to remove SNAPSHOT from the version and make changes to your SCM entries to point to your tags instead of your trunk. (Same) 2. DO NOT commit this change back to trunk. (Different). 3. Do an svn copy of your working directory to your tags, just as it does today. (Same) 4. ... continue as normal Are there any negatives to this that I have overlooked? --- Todd Thiessen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [SPAM] RE: Attaching artifacts
I am trying to deploy an .exe file to our repository. I am willing to build a simple jar to go with it and use jar packaging but I will still need to attach the .exe file. -Original Message- From: Martin Gainty [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 11:45 AM To: users@maven.apache.org Subject: [SPAM] RE: Attaching artifacts Importance: Low If your Maven POJO is a representation of a goal then a qualified 'yes' example located here http://maven.apache.org/maven-1.x/plugins/artifact/examples.html The bigger question is Why execute a build script with no associated goal ? Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. Subject: Attaching artifacts Date: Thu, 4 Dec 2008 11:25:31 -0500 From: [EMAIL PROTECTED] To: users@maven.apache.org Is there anyway to attach an artifact without writing a mojo to do it? I would like to just do it with the pom if possible. Liz Sommers [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Send e-mail faster without improving your typing skills. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_spe ed_122008 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: POM dependency issue (Reactor)
If you haven't looked at it yet, try this:
http://books.sonatype.com/maven-book/reference/multimodule-web-spring.html
solo1970 wrote:
This is my dilemna, ca anyone shed some light?
I have the following configuration of POMs
bigparentPOM --- common
parentPOM 1 (depends on common)
parentPOM 2 (depends on common)
ParentPOM 1 and 2 are dependent on common, but sometimes they also need to
be compiled separately. I I want to build only parentPOM1 and need to
recompile common, how can I do it??? For now we have to recompile
everything from bigparentPOM.
Can I configure my POM hierarchies in another way to be able to compile ONLY
parentPOM1 and common OR ONLY parentPOM2 and common
Thanks in advance for your help
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: POM dependency issue (Reactor)
Can I configure my POM hierarchies in another way to be able to compile ONLY parentPOM1 and common OR ONLY parentPOM2 and common Sure, with profiles. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SPAM] RE: Attaching artifacts
Use pom packaging so that you don't deploy a jar. Use the buildhelper-maven-plugin bound to the package phase to attach the exe to your build. Use the exec-maven-plugin bound to the compile phase to (I'm guessing) invoke your native code build system to generate the .exe. That's an all-in-the-pom way that is in the Maven spirit -Stephen 2008/12/4 Sommers, Elizabeth [EMAIL PROTECTED] I am trying to deploy an .exe file to our repository. I am willing to build a simple jar to go with it and use jar packaging but I will still need to attach the .exe file. -Original Message- From: Martin Gainty [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 11:45 AM To: users@maven.apache.org Subject: [SPAM] RE: Attaching artifacts Importance: Low If your Maven POJO is a representation of a goal then a qualified 'yes' example located here http://maven.apache.org/maven-1.x/plugins/artifact/examples.html The bigger question is Why execute a build script with no associated goal ? Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. Subject: Attaching artifacts Date: Thu, 4 Dec 2008 11:25:31 -0500 From: [EMAIL PROTECTED] To: users@maven.apache.org Is there anyway to attach an artifact without writing a mojo to do it? I would like to just do it with the pom if possible. Liz Sommers [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Send e-mail faster without improving your typing skills. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_spe ed_122008http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_speed_122008 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: POM dependency issue (Reactor)
Alternatively, you could do.
cd common
mvn install
cd ../parentPOM1
mvn install
2008/12/4 Rusty Wright [EMAIL PROTECTED]
If you haven't looked at it yet, try this:
http://books.sonatype.com/maven-book/reference/multimodule-web-spring.html
solo1970 wrote:
This is my dilemna, ca anyone shed some light?
I have the following configuration of POMs
bigparentPOM --- common
parentPOM 1 (depends on common)
parentPOM 2 (depends on common)
ParentPOM 1 and 2 are dependent on common, but sometimes they also need to
be compiled separately. I I want to build only parentPOM1 and need to
recompile common, how can I do it??? For now we have to recompile
everything from bigparentPOM.
Can I configure my POM hierarchies in another way to be able to compile
ONLY
parentPOM1 and common OR ONLY parentPOM2 and common
Thanks in advance for your help
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: POM dependency issue (Reactor)
Oh yeah, I forgot. Define two profiles, both active unless things say otherwise. Put parentPom1 as a module defined in profile 1 Put parentPom2 as a module defined in profile 2. If you do nothing, compiling bigParent will compile everything if you do mvn -Pprofile_1 then (as specifying an active profile deactivates all profiles that are active by default) you'd only compile common and parentPom1 2008/12/4 Wayne Fay [EMAIL PROTECTED] Can I configure my POM hierarchies in another way to be able to compile ONLY parentPOM1 and common OR ONLY parentPOM2 and common Sure, with profiles. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Plugin that bundles Jetty + Webapp for release
Hi, I'm searching for a Maven plugin that is able to package my webapp together with Jetty, for example into a Zip file. Doing it this way, I could use this Zip file and distribute it all in one. As far as I know, with the ordinary maven-jetty-plugin its only possible to run the embedded Jetty within Maven, but not to bundle Jetty with my webapp for a release. Any hints for me about such a plugin? My search was not successful so far. Thanks in advance. Regards Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Good weblogic plugin?
Hi! Have to deploy (generate stubs - deployment descriptos) for both WLS 9.2 and 10.x. Anybody know of any good plugins? The one at mojo seems a little abandoned and mainly for 8.2 usage - and barely 9.0 - and I haven't had great success with it yet? I see cargo has had some weblogic activity lately - anybody tried it? -- David J. M. Karlsen - +47 90 68 22 43 http://www.davidkarlsen.com http://mp3.davidkarlsen.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Attaching artifacts
Use the build-helper plugin --Brian (mobile) On Dec 4, 2008, at 8:25 AM, Sommers, Elizabeth [EMAIL PROTECTED] wrote: Is there anyway to attach an artifact without writing a mojo to do it? I would like to just do it with the pom if possible. Liz Sommers [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Limitation of the release plugin?
On Fri, Dec 5, 2008 at 2:15 AM, Todd Thiessen [EMAIL PROTECTED] wrote: My suggestion though is to not commit at all. Just do a working copy. So no commit to tags would be required. Err, if you dont commit, then how can you tag? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Limitation of the release plugin?
By doing an svn copy of the working copy with uncommited changes. The release plugin does not do a revision copy to the tags folder. It does a copy of your working folder. --- Todd Thiessen -Original Message- From: Barrie Treloar [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 2:56 PM To: Maven Users List Subject: Re: Limitation of the release plugin? On Fri, Dec 5, 2008 at 2:15 AM, Todd Thiessen [EMAIL PROTECTED] wrote: My suggestion though is to not commit at all. Just do a working copy. So no commit to tags would be required. Err, if you dont commit, then how can you tag? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin that bundles Jetty + Webapp for release
You might want to look at the source tree for Nexus. It does something similar to what you're describing. Justin - Original Message - From: Stephan Niedermeier [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Thu Dec 04 13:56:27 2008 Subject: Plugin that bundles Jetty + Webapp for release Hi, I'm searching for a Maven plugin that is able to package my webapp together with Jetty, for example into a Zip file. Doing it this way, I could use this Zip file and distribute it all in one. As far as I know, with the ordinary maven-jetty-plugin its only possible to run the embedded Jetty within Maven, but not to bundle Jetty with my webapp for a release. Any hints for me about such a plugin? My search was not successful so far. Thanks in advance. Regards Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Errors which was resolved in JIRA: MSITE-286
Hi, I'm using maven-2.0.8 to build up the Java code and to generate the site out of it. The site-plugin being used while building is 2.0-beta-7 and I could see an error trace as below in the build log. Even though it doesn't impact the build/site generation, I would need to fix this. Having said in MSITE-286 that 2.0-beta-6 version of maven-site-plugin fixes this, I see the same error coming in 2.0-beta-7 which I believe is an upgraded version. [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'VM_global_library.vm' Please help me in resolving this issue. Thanks Regards, Logu Rajamanickam - This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to UK legal entities.
Re: Plugin that bundles Jetty + Webapp for release
Hi Stephan, I doubt there is a plugin doing this directly since it is a rather specialized task. But you can achieve the same using an Ant script invoked by Maven (maven-antrun-plugin) and/or the maven-assembly-plugin. Furthermore it should be possible to add this distribution as attached artifact to the Maven build Having said that you can have a look at http://people.apache.org/~sgoeschl/download/wikionastick/ for some inspiration ... :-) +) it packages JSPWiki in ready-to-use distribution (Wiki On A Stick) +) it creates Windows and Mac OS X native application starter as well Hope this helps Siegfried Goeschl Stephan Niedermeier wrote: Hi, I'm searching for a Maven plugin that is able to package my webapp together with Jetty, for example into a Zip file. Doing it this way, I could use this Zip file and distribute it all in one. As far as I know, with the ordinary maven-jetty-plugin its only possible to run the embedded Jetty within Maven, but not to bundle Jetty with my webapp for a release. Any hints for me about such a plugin? My search was not successful so far. Thanks in advance. Regards Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin that bundles Jetty + Webapp for release
Hi, Have a look at the continuum-jetty pom [1]. It use appassembler-maven-plugin and assembly plugin to do this. -- Olivier [1] https://svn.apache.org/repos/asf/continuum/trunk/continuum-jetty/pom.xml 2008/12/4 Siegfried Goeschl [EMAIL PROTECTED]: Hi Stephan, I doubt there is a plugin doing this directly since it is a rather specialized task. But you can achieve the same using an Ant script invoked by Maven (maven-antrun-plugin) and/or the maven-assembly-plugin. Furthermore it should be possible to add this distribution as attached artifact to the Maven build Having said that you can have a look at http://people.apache.org/~sgoeschl/download/wikionastick/ for some inspiration ... :-) +) it packages JSPWiki in ready-to-use distribution (Wiki On A Stick) +) it creates Windows and Mac OS X native application starter as well Hope this helps Siegfried Goeschl Stephan Niedermeier wrote: Hi, I'm searching for a Maven plugin that is able to package my webapp together with Jetty, for example into a Zip file. Doing it this way, I could use this Zip file and distribute it all in one. As far as I know, with the ordinary maven-jetty-plugin its only possible to run the embedded Jetty within Maven, but not to bundle Jetty with my webapp for a release. Any hints for me about such a plugin? My search was not successful so far. Thanks in advance. Regards Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Errors which was resolved in JIRA: MSITE-286
[INFO] Velocimacro : error using VM library template VM_global_library.vm : org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'VM_global_library.vm' Read the comments in this bug: http://jira.codehaus.org/browse/MSITE-306 Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Good weblogic plugin?
We have been maintaining the weblogic plugin on codehaus and it works fine for all versions 8 -10. Are there some problems you are having? Scott Ryan President/CTO Soaring Eagle L.L.C. www.soaringeagleco.com [EMAIL PROTECTED] (303) 263-3044 On Dec 4, 2008, at 12:20 PM, [EMAIL PROTECTED] wrote: Hi! Have to deploy (generate stubs - deployment descriptos) for both WLS 9.2 and 10.x. Anybody know of any good plugins? The one at mojo seems a little abandoned and mainly for 8.2 usage - and barely 9.0 - and I haven't had great success with it yet? I see cargo has had some weblogic activity lately - anybody tried it? -- David J. M. Karlsen - +47 90 68 22 43 http://www.davidkarlsen.com http://mp3.davidkarlsen.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
deploying with maven and a production control/release management group?
I was wondering if and how people are doing war deployments in a setup where you have a production control group that deploys the war to your qa and production servers (tomcat, for example). It seems to me that you could have them use maven with the cargo plugin. But how do they get the pom.xml; check it out of scm and then run maven with it? And do you have a separate project that's just for doing the deployment? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JavaFX compiler?
Hey all, Now that JavaFX is out there in the wild wild world, has anyone looked at a maven javafx compiler/pakaging type? Theres http://m2-javafxc.sourceforge.net/ but I suspect it hasn't been updated or anything... mark -- It is easier to optimize correct code than to correct optimized code. -- Bill Harlan
release plugin and plugin-level dependencies
So, the release plugin checks for SNAPSHOT dependencies in plugins, parent POM, and dependencies. It doesn't notice SNAPSHOT plugin-level dependencies (i.e. dependencies elements within plugin or execution elements). This is http://jira.codehaus.org/browse/MRELEASE-378. Anyone know a workaround? A brief look at maven-enforcer-plugin's source code did not seem to indicate it knew how to check for this either. (Maybe I'll just submit a patch for MRELEASE-378...) - John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
scm:update
Hello! I haven't much experience with Maven yet... In our Project we use the SCM- plugin. We use scm:update instead of svn up (cause: to long directory names in Windows) Is it possible to run scm:update with an option to print out the updated files in command line as svn up does? Thank you very much! Danny
maven2 : how to call a .sh file or a .bat from pom ?
Hi, i want to call a .sh file from a pom. .sh file . (actually .sh doing some server environment configuration and then deploy the application in weblogic actual path) If i am able to call the .sh file then it will be ok. Is their any tag or plugin which will be used to call the .sh file? if yes could you pls mention the tag ? Regards, partha -- View this message in context: http://www.nabble.com/maven2-%3A-how-to-call-a-.sh-file-or-a-.bat-from-pom---tp20848353p20848353.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven2 : how to call a .sh file or a .bat from pom ?
maven-antrun-plugin On Thu, Dec 4, 2008 at 10:15 PM, partha_ctc [EMAIL PROTECTED] wrote: Hi, i want to call a .sh file from a pom. .sh file . (actually .sh doing some server environment configuration and then deploy the application in weblogic actual path) If i am able to call the .sh file then it will be ok. Is their any tag or plugin which will be used to call the .sh file? if yes could you pls mention the tag ? Regards, partha -- View this message in context: http://www.nabble.com/maven2-%3A-how-to-call-a-.sh-file-or-a-.bat-from-pom---tp20848353p20848353.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven2 : how to call a .sh file or a .bat from pom ?
exec-maven-plugin On Thu, Dec 4, 2008 at 10:20 PM, Dan Tran [EMAIL PROTECTED] wrote: maven-antrun-plugin On Thu, Dec 4, 2008 at 10:15 PM, partha_ctc [EMAIL PROTECTED] wrote: Hi, i want to call a .sh file from a pom. .sh file . (actually .sh doing some server environment configuration and then deploy the application in weblogic actual path) If i am able to call the .sh file then it will be ok. Is their any tag or plugin which will be used to call the .sh file? if yes could you pls mention the tag ? Regards, partha -- View this message in context: http://www.nabble.com/maven2-%3A-how-to-call-a-.sh-file-or-a-.bat-from-pom---tp20848353p20848353.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Nexus Publish Indexes
Hi, An issue has been opened concerning the update of the index on the fly: https://issues.sonatype.org/browse/NEXUS-997 Best Regards Jean-Claude -Ursprüngliche Nachricht- Von: Brian E. Fox [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 4. Dezember 2008 16:41 An: Maven Users List Betreff: RE: Nexus Publish Indexes BTW. Is it possible to do this without using the scheduler? Wouldn't it make sense to have a create index option when you right click on a group so the user can do it manually? The group index is created automatically when there's a group made and any reindex on the group will also update it, but it will also reindex all the repos in the group. This is why we separated the publish step from a full reindex. Since the index is created automatically, there's no need for a create index option. The other thing I would like to ask about is this comment: The internal indexes are always updated in realtime... Do you mean the Nexus hosted drepository indexes? If so, I have not observed this behaviour. For instance, if I deploy an artifact to my Nexus repository, it does not automatically update the index. I have always had to re-index it manually. Thats actually why I started to look at the scheduler to see if I could at least semi-automate it. I mean the indexes that Nexus uses internally. If you deploy something and then go to the Nexus UI and search for it, it should be there immediately with no further action. If you're pulling the index into m2e, then the publish needs to occur for the previously mentioned reasons. If you see that it is not indexed immediately and visible from the UI, check that the user you are logged in to the UI has permissions to the repo where it exists (the search results are filtered based on permissions). If you still have problems, then lets discuss more debugging on the Nexus User list. --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
