Maven 2.0.9 to 2.2.1 and war plugin 2.1-alpha-1
Hi, we just recently switch from maven 2.0.9 to 2.2.1 and I noticed that the war plugin seems to be ignoring the excludes directive. We did not change the plugin, just the maven core. Any ideas? Patrick - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2.0.9 to 2.2.1 and war plugin 2.1-alpha-1
No, but after checking I think it could be alpha-2. Is beta-1 a fix? Patrick -Original Message- From: Jason van Zyl ja...@sonatype.com Sent: Wednesday, May 26, 2010 6:58pm To: Maven Users List users@maven.apache.org Subject: Re: Maven 2.0.9 to 2.2.1 and war plugin 2.1-alpha-1 You have the plugin version locked down in your POM? On May 27, 2010, at 12:49 AM, Patrick Shea wrote: Hi, we just recently switch from maven 2.0.9 to 2.2.1 and I noticed that the war plugin seems to be ignoring the excludes directive. We did not change the plugin, just the maven core. Any ideas? Patrick - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: artifacts build fine on their own but fail in multi-module build
Hi Stuart, Thanks for your reply - I think this explains the problem. If I understand correctly, the workaround you are proposing is that I unpack the contents of the a jar into a/target/classes during the package phase (using antrun or dependency-plugin unless there is another approach)? Alternatively, I suppose I could use antrun to copy the classes for a into a/target/classes before packaging and thereby use the default classesDirectory for the jar plugin...same difference I think. thanks, Shea. Stuart McCulloch-3 wrote: On 06/03/2008, shea [EMAIL PROTECTED] wrote: Hello, I have a multi-module build that is essentially: jars---a b c Where jars is a directory that contains a parent/multimodule pom.xml that builds a pom-type artifact called jars-parent. a, b, and c are each sub-directories within the jars directory with their own poms. a, b, and c, all have jars-parent as their parent. They are referenced as modules in jars-parent's pom.xml in the same order. The problem arises in a situation when c depends on a for example. If I build each of the submodules independently in the the order a, b, c, everything is fine. however, when I do a mvn install from the jars directory, a and b build fine, but compilation of c fails - not an artifact resolution problem, but a compilation problem. This is in spite of the fact that a was built and installed to my local repo just fine. The only unusual thing I am doing is that a doesn't actually compile anything - it just packages some existing class files using the jar plugin. (this is part of an ant conversion - don't get me started :,( ) I have had other multi-module build work just fine, but I am hoping somebody can point out some potential gotchas that I am overlooking. This is due to a feature in the MavenProject class when running a reactor (ie. multi-module) compilation. Normally when it builds the compilation classpath, it will use the location of the artifact in the local maven repository - and your setup will work fine. However, with a reactor build you may be running mvn compile and not installing artifacts, so there's code inside MavenProject (addArtifactPath) that changes the compilation classpath to use: artifact-module/build.outputDirectory instead of the location of the local repository - I think the reason for this is because you want to compile against the latest code and the jar in the repository may be stale if you're not doing an install at the same time as compile unfortunately this doesn't work so well with projects that create artifacts without populating target/classes because then the compilation classpath will contain the empty directory, not the actual artifact with the classes :( the safest workaround I've found is to unpack the contents of the jar to the build.outputDirectory during the packaging phase so the classes are found where MavenProject expects them a potential fix for the MavenProject class might be to add the outputDirectory before the artifact's location in the local repo, rather than replacing it in the compilation classpath - however this is a rather central part of Maven so modifying its behavior should be done very carefully... HTH Thanks, Shea. -- View this message in context: http://www.nabble.com/artifacts-build-fine-on-their-own-but-fail-in-multi-module-build-tp15863045s177p15863045.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] -- Cheers, Stuart -- View this message in context: http://www.nabble.com/artifacts-build-fine-on-their-own-but-fail-in-multi-module-build-tp15863045s177p15901229.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]
artifacts build fine on their own but fail in multi-module build
Hello, I have a multi-module build that is essentially: jars---a b c Where jars is a directory that contains a parent/multimodule pom.xml that builds a pom-type artifact called jars-parent. a, b, and c are each sub-directories within the jars directory with their own poms. a, b, and c, all have jars-parent as their parent. They are referenced as modules in jars-parent's pom.xml in the same order. The problem arises in a situation when c depends on a for example. If I build each of the submodules independently in the the order a, b, c, everything is fine. however, when I do a mvn install from the jars directory, a and b build fine, but compilation of c fails - not an artifact resolution problem, but a compilation problem. This is in spite of the fact that a was built and installed to my local repo just fine. The only unusual thing I am doing is that a doesn't actually compile anything - it just packages some existing class files using the jar plugin. (this is part of an ant conversion - don't get me started :,( ) I have had other multi-module build work just fine, but I am hoping somebody can point out some potential gotchas that I am overlooking. Thanks, Shea. -- View this message in context: http://www.nabble.com/artifacts-build-fine-on-their-own-but-fail-in-multi-module-build-tp15863045s177p15863045.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]
mapping jar plugin include pattern to specific output location in jar...
Hello, I am creating 3 classifier-differentiated jars from a single pom - each on contains the same classes, but different resources. The resources end up in the equivalent of classes/mystuff/a, classes/mystuff/b, and classes//mystuff/c where a, b, and c are the respective resources I want for each of my jars. I have three jar plugins configured as below, each in its own execution: ... configuration classifiera/classifier includes include**/model/**/*.class/include includemystuff/a/**/include /includes /configuration ... This mostly works (I get three jars), except that the jars retain the mystuff/a structure when what I want is to have it in the root of the jar (i.e. suppress the mystuff/a structure and write contents into the root of the jar). Is there a way to do this, maybe with a slightly different include pattern? The other alternative I am considering are to have 3 separate artifacts that get their classes from a common parent or dependency via the dependency plugin, but this seems pretty inconvenient. Any other ideas appreciated. Thanks, Shea. -- View this message in context: http://www.nabble.com/mapping-jar-plugin-%3Cinclude%3E-pattern-to-specific-output-location-in-jar...-tp15835651s177p15835651.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]
Circular project reference
I just came across an interesting issue. I have a master pom with 40 or so sub projects depending on it, the pom itself was using a plugin which in turn depended on it. So these two were constantly rebuilding them self because of a dependency change detection. Since this was the master pom the entire project groups (40+ projects) were building all the time. Is there a way for continuum to detect circular references? Patrick
Re: Recursive maven projects
Yes that would be good. In a sense what we what is a way to control the scm command string per project or add a checkbox on the build definition for non recursive. Patrick -Original Message- From: Christian Edward Gruber [EMAIL PROTECTED] Sent: Wednesday, January 23, 2008 9:19am To: continuum-users@maven.apache.org Subject: Re: Recursive maven projects Actually, you don't want this, because a parent project may have /src/ site/*, so you actually want slightly more granularity on this than just recursive pull or not Christian. On 23-Jan-08, at 12:05 , Patrick Shea wrote: Ok I will. This may not be an issue on small projects but it becomes one when you have a large code base. Patrick -Original Message- From: Wendy Smoak [EMAIL PROTECTED] Sent: Wednesday, January 23, 2008 8:54am To: continuum-users@maven.apache.org Subject: Re: Recursive maven projects On Jan 23, 2008 9:39 AM, Patrick Shea [EMAIL PROTECTED] wrote: Yes that's for maven, but continuum will still call svn up on the entire branch. What I'm trying to avoid is to have multiple checked out projects with the same code. I need to pass -N to subversion on projects of type pom. As Emmanuel mentioned there's no way to do this currently. Can you open a JIRA for this enhancement if it's not already there? -- Wendy
Re: Recursive maven projects
I'm not sure I follow you, In my case I don't use the maven scm plugin to synchronize the source code, continuum dos this for me (which is the default behavior). The maven build is fine, the non-recursive parameter is used by default, it's just that the scm command is not doing the same. So just adding an option (checkbox) on the build definition to prevent recursive checkout would be nice. A good bet would be that maven projects of type pom should be non recursive in regards to source code. You could override this later with the above option. The other way around (sync all then restrict) would leave your build workspace polluted with unnecessary files. Patrick -Original Message- From: Christian Edward Gruber [EMAIL PROTECTED] Sent: Wednesday, January 23, 2008 9:37am To: continuum-users@maven.apache.org Subject: Re: Recursive maven projects Part of the problem, of course, is that this is delegated to the maven SCM stuff, so this may force a lot of feature-requests back into that project. Not a bad thing, but it's very very easy to over-specify if this isn't thought through carefully. christian On 23-Jan-08, at 12:34 , Patrick Shea wrote: Yes that would be good. In a sense what we what is a way to control the scm command string per project or add a checkbox on the build definition for non recursive. Patrick -Original Message- From: Christian Edward Gruber [EMAIL PROTECTED] Sent: Wednesday, January 23, 2008 9:19am To: continuum-users@maven.apache.org Subject: Re: Recursive maven projects Actually, you don't want this, because a parent project may have /src/ site/*, so you actually want slightly more granularity on this than just recursive pull or not Christian. On 23-Jan-08, at 12:05 , Patrick Shea wrote: Ok I will. This may not be an issue on small projects but it becomes one when you have a large code base. Patrick -Original Message- From: Wendy Smoak [EMAIL PROTECTED] Sent: Wednesday, January 23, 2008 8:54am To: continuum-users@maven.apache.org Subject: Re: Recursive maven projects On Jan 23, 2008 9:39 AM, Patrick Shea [EMAIL PROTECTED] wrote: Yes that's for maven, but continuum will still call svn up on the entire branch. What I'm trying to avoid is to have multiple checked out projects with the same code. I need to pass -N to subversion on projects of type pom. As Emmanuel mentioned there's no way to do this currently. Can you open a JIRA for this enhancement if it's not already there? -- Wendy
Re: Recursive maven projects
You're right, subversion only works on folder paths. The only way would be to use -N. So the trick would be to detect if the current pom is an enclosing project (ie: contains a modules section) and make it non recursive by default (can be overridden later) Patrick -Original Message- From: Wendy Smoak [EMAIL PROTECTED] Sent: Wednesday, January 23, 2008 10:42am To: continuum-users@maven.apache.org, [EMAIL PROTECTED] Subject: Re: Recursive maven projects On Jan 23, 2008 11:37 AM, Patrick Shea [EMAIL PROTECTED] wrote: Well, it's pretty similar, it means don't run the command (maven: compile,deploy, etc and subversion: co,up etc) recursively. If there was a way to exclude from the scm command all sub projects declared in the modules section that would do the trick. anything else left would be considered legitimate. How do you propose to tell Subversion to check out the contents of this directory and the 'src' subdirectory, but none of the other subdirectories ? -- Wendy
Re: Recursive maven projects
Well, it's pretty similar, it means don't run the command (maven: compile,deploy, etc and subversion: co,up etc) recursively. If there was a way to exclude from the scm command all sub projects declared in the modules section that would do the trick. anything else left would be considered legitimate. Patrick -Original Message- From: Wendy Smoak [EMAIL PROTECTED] Sent: Wednesday, January 23, 2008 10:27am To: continuum-users@maven.apache.org, [EMAIL PROTECTED] Subject: Re: Recursive maven projects On Jan 23, 2008 10:51 AM, Patrick Shea [EMAIL PROTECTED] wrote: I'm not sure I follow you, In my case I don't use the maven scm plugin to synchronize the source code, continuum dos this for me (which is the default behavior). The maven build is fine, the non-recursive parameter is used by default, it's just that the scm command is not doing the same. Non-recursive means something different to Maven and Subversion. If you check out with -N, you only get the directory not the project (which as Christian already mentioned may include src/site.) Still, I'm not opposed to adding a way to supply parameters for the scm command, to give people the option. -- Wendy
Re: Recursive maven projects
Ok I will. This may not be an issue on small projects but it becomes one when you have a large code base. Patrick -Original Message- From: Wendy Smoak [EMAIL PROTECTED] Sent: Wednesday, January 23, 2008 8:54am To: [EMAIL PROTECTED] Subject: Re: Recursive maven projects On Jan 23, 2008 9:39 AM, Patrick Shea [EMAIL PROTECTED] wrote: Yes that's for maven, but continuum will still call svn up on the entire branch. What I'm trying to avoid is to have multiple checked out projects with the same code. I need to pass -N to subversion on projects of type pom. As Emmanuel mentioned there's no way to do this currently. Can you open a JIRA for this enhancement if it's not already there? -- Wendy
optionaltrue/optional ignored with build from parent
I'm hoping someone has seen this before. My war has a dependency on an ejb-client jar, and I want the ejb-client placed inside the ear not the war. I am using the optionaltrue/optional tag on the dependency in the war so that the manifest gets updated to have the reference to the ejb-client jar, but that the ejb-client is not placed in the web-inf\lib of the war. When I do a Maven install from my war project and then the ear project all is fine. When I build from the parent it is placing the ejb-client jar inside the web-inf\lib of my war. Subsequently at execution time, the code breaks because the war classpath does not have visibility into the ear classpath to find the ejb jar. Has anyone seen this difference ehen building from the parent and know how to get around it? We are using a product called TPM to kick off the Maven builds and it always does so from the parent. Thanks for your help! Amy - This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. -
creating a branch from a tag with release:branch
Hello, I am trying to create a branch based on a release tag. The branch would be used for maintenance purposes. (I am using an svn scm provider with the standard layout) The release plugin doco doesn't indicate where I should be running the release:branch goal from... If I run it from the trunk, it creates a branch from the current development version, regardless of whether I give it -Dtag=myrelease_version. If I run it from a tag folder, it complains that I don't have a SNAPSHOT project in the reactor projects list. It makes sense to me that I should be able to do a release from a release tag folder, or from the trunk, (by providing a value for -Dtag=...). I ahve experiemented with -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false, but the situation is no better. Does anyone have any thoughts on what I am doing wrong? This is actually just a simplistic test project with one artifact at this point before I try to apply this to my multi-module, JEE project. Thanks, Shea. -- View this message in context: http://www.nabble.com/creating-a-branch-from-a-tag-with-release%3Abranch-tf4197145s177.html#a11937078 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
m2 ear plugin and streamlining config of application.xml generation
I've searched on this and from what I can tell, this question has not been directly asked before... I have an EAR artifact that declares dependencies on several of my own jars, a war, and some 3rd party jars. This is sufficient to get the artifacts included in my EAR, however, if I actually want an artifact to be included in application.xml (so it is actually accessible at runtime), I need to pretty much duplicate the dependency list in the modules section of the ear-plugin config. I am wondering if I am doing something incorrectly, as this duplication seems somewhat contrary to maven's principle of 'useful defaults' (which IMO would include declared dependencies in the application.xml unless you explicitly exclude them). Or am I misunderstanding the relationship between application.xml and the runtime classpath. (i.e. should I be instead using a generated ear manifest for the classpath). Thanks, Shea. -- View this message in context: http://www.nabble.com/m2-ear-plugin-and-streamlining-config-of-application.xml-generation-tf3176492s177.html#a8813645 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Visual Source Safe integration
Hi, can anyone point me towards any documentation, or an example, to show me how to integrate VSS with maven? Cheers _ Get Extra Storage in 10MB, 25MB, 50MB and 100MB options now! Go to http://join.msn.com/?pgmarket=en-aupage=hotmail/es2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
