Re: Shade plugin plus WAR overlays
On Wed, Apr 17, 2013 at 7:43 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > > >> > > Hmm. I understand what ClassLoader.getResources(path) returns (just read > > the javadoc). However, if I have a bunch of independently developed > > components that are assembled as WAR overlays, then the first file in > with > > a particular name wins. > > > > You are reading the javadoc of getResource(path) not getResources(path) > note the "s" at the end. > > Stephen, I don't think you read what Mark wrote, and he is correct. The Maven WAR plugin, when it overlays, *overwrites* competing filenames with the same name. Your solution will work if they are the same name and in embedded jar files, but will not work for a war overlay. We have exactly this situation for jawr configuration files - each war overlay needs to specify jawr-artifactid.properties - then we classpath scan for /WEB-INF/jawr-*.properties and assemble them using JAWR's muultiple source capability. Mark - we use war overlays, but we have built the necessary stuff to make us productive in and outside of the IDE. We use Jetty 9 and a runnable war, not sure if that matches at all, but we have code we can give you if it helps. We will be open sourcing once we move to git but our artifacts will never be in central as we are open sourcing them to allow for students to enhance and hack on our projects. Contact me off list if you are interested and I'll send you everything. Richard -- --- Richard Vowles, Grails, Groovy, Java, Javascript, AngularJS Consistency is the last refuge of the unimaginative - Oscar Wilde ph: +64275467747, google+:http://rvowl.es/UX8Bmq podcast: http://www.illegalargument.com
Re: Shade plugin plus WAR overlays
On 16 April 2013 17:57, Mark Eggers wrote: > On 4/16/2013 9:33 AM, Stephen Connolly wrote: > >> On 16 April 2013 17:25, Mark Eggers wrote: >> >> Comments in-line, and some of the original trimmed . . . >>> >>> >>> On 4/16/2013 8:54 AM, Stephen Connolly wrote: >>> >>> On 16 April 2013 16:19, Mark Eggers wrote: On 4/16/2013 2:31 AM, Richard Vowles wrote: > > what needs concatenating? there isnt much designed to be anti-modular > >> these >> days. >> >> >> Some properties files. I could possibly remove the properties files > issue > by either having the developers hand craft them for each project, or > design > a new modular configuration system. The first is error-prone, and the > second will take a bit of time. > > I suppose an ant task would work as well, but since I'm trying to > replace > ant I would like to avoid falling back on it. > > > I would not decry using antrun to work around a (hopefully) temporary issue. If it proves too difficult to move to a new modular configuration system, then I would look to replace that antrun with a plugin that does the merging for me, perhaps even defining a new packaging type so that I can just go eggers-war I'll have to investigate a new packaging type. I'm more or less a Maven >>> newcomer, so that will take a little bit of effort. I am in huge favor of >>> keeping the pom.xml file as simple and easily understood as possible. >>> >>> >>> If I do come up with a new modular configuration system, e.g. using >>> ClassLoader.getResources(path) rather that ClassLoader.getResource(path) and then just effectively concatenating all the .properties files within the app, then the antrun will just go away. >>> I'll definitely try that. I'm mostly a systems architect, but I seem to >>> be >>> getting pulled into build and development issues these days. The change >>> should be minor, and will definitely result in a more clearly decoupled >>> modular system. >>> >>> Then the only issue becomes naming conventions so that there are no file >>> name collisions. >>> >> >> >> Ahh no... ClassLoader.getResources(path) returns an enumeration of all the >> resources with that path... you actually want the collisions and then your >> just load each in app and merge using logic defined in app... i.e. the >> best >> of all, you change no code and the app just works ;-) >> >> > Hmm. I understand what ClassLoader.getResources(path) returns (just read > the javadoc). However, if I have a bunch of independently developed > components that are assembled as WAR overlays, then the first file in with > a particular name wins. > You are reading the javadoc of getResource(path) not getResources(path) note the "s" at the end. ;-) > > If all the components name the configuration file the same name, then only > the first component's configuration gets placed in the final WAR file. > > I think the first incarnation will either be what I have now (doesn't look > too difficult to unwind) or a new package type. Then I can look changing or > getting the code changed (convince, cajole) to be more loosely coupled. > > . . . . thanks > /mde/ > > On Apr 16, 2013 6:56 PM, "Mark Eggers" wrote: >>> > >>Hi, >> >> >>> I'm fairly new to Maven, and I'm trying to meet the following >>> requirements. >>> >>> 1. A web site consisting of multiple components, some optional >>> 2. Optional components each have some configuration files >>> 3. If multiple optional components are present, the configuration >>> files >>> should be concatenated >>> >>> My first pass using WAR overlays and the shade plugin worked, in that >>> the >>> resulting site.war had all the right components. However, target/site >>> did >>> not contain the concatenated files created by the shade plugin. This >>> prevented target/site being run from within an IDE. >>> >>> If I thought about it for a minute, that's pretty obvious since the >>> shade >>> plugin is executed during the package part of the lifecycle. >>> >>> What I came up with is the following: >>> >>> 1. Create a multi-module project >>> 2. One module collects all of the components that require use of the >>> shade plugin >>> 3. The second module is the actual site, and depends on the >>> "collections" module >>> 4. Use the WAR plugin overlay, plus exclusions, plus the shade plugin >>> to create an intermediate WAR in the collections module >>> 5. Overlay that intermediate WAR on the final site >>> >>> This works except that I now have an extra artifact that is only used >>> during the build. I can run target/site from the IDE (great for >>> debugging) >>> and site.war looks as it should. >>> >>> Other than th
Re: Shade plugin plus WAR overlays
On 4/16/2013 9:33 AM, Stephen Connolly wrote: On 16 April 2013 17:25, Mark Eggers wrote: Comments in-line, and some of the original trimmed . . . On 4/16/2013 8:54 AM, Stephen Connolly wrote: On 16 April 2013 16:19, Mark Eggers wrote: On 4/16/2013 2:31 AM, Richard Vowles wrote: what needs concatenating? there isnt much designed to be anti-modular these days. Some properties files. I could possibly remove the properties files issue by either having the developers hand craft them for each project, or design a new modular configuration system. The first is error-prone, and the second will take a bit of time. I suppose an ant task would work as well, but since I'm trying to replace ant I would like to avoid falling back on it. I would not decry using antrun to work around a (hopefully) temporary issue. If it proves too difficult to move to a new modular configuration system, then I would look to replace that antrun with a plugin that does the merging for me, perhaps even defining a new packaging type so that I can just go eggers-war I'll have to investigate a new packaging type. I'm more or less a Maven newcomer, so that will take a little bit of effort. I am in huge favor of keeping the pom.xml file as simple and easily understood as possible. If I do come up with a new modular configuration system, e.g. using ClassLoader.getResources(path) rather that ClassLoader.getResource(path) and then just effectively concatenating all the .properties files within the app, then the antrun will just go away. I'll definitely try that. I'm mostly a systems architect, but I seem to be getting pulled into build and development issues these days. The change should be minor, and will definitely result in a more clearly decoupled modular system. Then the only issue becomes naming conventions so that there are no file name collisions. Ahh no... ClassLoader.getResources(path) returns an enumeration of all the resources with that path... you actually want the collisions and then your just load each in app and merge using logic defined in app... i.e. the best of all, you change no code and the app just works ;-) Hmm. I understand what ClassLoader.getResources(path) returns (just read the javadoc). However, if I have a bunch of independently developed components that are assembled as WAR overlays, then the first file in with a particular name wins. If all the components name the configuration file the same name, then only the first component's configuration gets placed in the final WAR file. I think the first incarnation will either be what I have now (doesn't look too difficult to unwind) or a new package type. Then I can look changing or getting the code changed (convince, cajole) to be more loosely coupled. . . . . thanks /mde/ On Apr 16, 2013 6:56 PM, "Mark Eggers" wrote: Hi, I'm fairly new to Maven, and I'm trying to meet the following requirements. 1. A web site consisting of multiple components, some optional 2. Optional components each have some configuration files 3. If multiple optional components are present, the configuration files should be concatenated My first pass using WAR overlays and the shade plugin worked, in that the resulting site.war had all the right components. However, target/site did not contain the concatenated files created by the shade plugin. This prevented target/site being run from within an IDE. If I thought about it for a minute, that's pretty obvious since the shade plugin is executed during the package part of the lifecycle. What I came up with is the following: 1. Create a multi-module project 2. One module collects all of the components that require use of the shade plugin 3. The second module is the actual site, and depends on the "collections" module 4. Use the WAR plugin overlay, plus exclusions, plus the shade plugin to create an intermediate WAR in the collections module 5. Overlay that intermediate WAR on the final site This works except that I now have an extra artifact that is only used during the build. I can run target/site from the IDE (great for debugging) and site.war looks as it should. Other than the fact that this works, is this the proper "Maven way"? The extra artifact (an artifact of the build process as it were) feels a little odd. . . . . just my two cents /mde/ --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Shade plugin plus WAR overlays
It can be as simple as a jar artifact that has one file: META-INF/plexus/components.xml For an example of the content of such a components.xml https://github.com/jszip/jszip-maven-plugin/blob/master/src/main/resources/META-INF/plexus/components.xml (yes that is in a plugin, but the packaging could just have easily been in a jar) when packaging is in a jar, you do ... ... to let Maven know... ideally you do that in the root parent pom, but you can save it for the pom that needs the packaging. when the packaging is in a plugin, you just add true to the ... On 16 April 2013 17:39, Laird Nelson wrote: > On Tue, Apr 16, 2013 at 8:54 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > perhaps even defining a new packaging type so that I can > > just go eggers-war > > > > I have a similar requirement and never thought about the packaging type; > what a great idea! Where is the documentation that describes how to define > a new packaging type? > > Best, > Laird >
Re: Shade plugin plus WAR overlays
On Tue, Apr 16, 2013 at 8:54 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > perhaps even defining a new packaging type so that I can > just go eggers-war > I have a similar requirement and never thought about the packaging type; what a great idea! Where is the documentation that describes how to define a new packaging type? Best, Laird
Re: Shade plugin plus WAR overlays
On 16 April 2013 17:25, Mark Eggers wrote: > Comments in-line, and some of the original trimmed . . . > > > On 4/16/2013 8:54 AM, Stephen Connolly wrote: > >> On 16 April 2013 16:19, Mark Eggers wrote: >> >> On 4/16/2013 2:31 AM, Richard Vowles wrote: >>> >>> what needs concatenating? there isnt much designed to be anti-modular these days. >>> Some properties files. I could possibly remove the properties files issue >>> by either having the developers hand craft them for each project, or >>> design >>> a new modular configuration system. The first is error-prone, and the >>> second will take a bit of time. >>> >>> I suppose an ant task would work as well, but since I'm trying to replace >>> ant I would like to avoid falling back on it. >>> >>> >> I would not decry using antrun to work around a (hopefully) temporary >> issue. >> >> If it proves too difficult to move to a new modular configuration system, >> then I would look to replace that antrun with a plugin that does the >> merging for me, perhaps even defining a new packaging type so that I can >> just go eggers-war >> >> > I'll have to investigate a new packaging type. I'm more or less a Maven > newcomer, so that will take a little bit of effort. I am in huge favor of > keeping the pom.xml file as simple and easily understood as possible. > > > If I do come up with a new modular configuration system, e.g. using >> ClassLoader.getResources(path) rather that ClassLoader.getResource(path) >> and then just effectively concatenating all the .properties files within >> the app, then the antrun will just go away. >> > > I'll definitely try that. I'm mostly a systems architect, but I seem to be > getting pulled into build and development issues these days. The change > should be minor, and will definitely result in a more clearly decoupled > modular system. > > Then the only issue becomes naming conventions so that there are no file > name collisions. Ahh no... ClassLoader.getResources(path) returns an enumeration of all the resources with that path... you actually want the collisions and then your just load each in app and merge using logic defined in app... i.e. the best of all, you change no code and the app just works ;-) > > > >> Having antrun there is a good tool to mark the fact that you have >> technical >> debt that will need to be repaid. When you are leaving technical debt the >> keys thing to remember are that: >> >> 1. it should be clear and obvious that it is technical debt >> 2. it should be as small as possible >> >> A *simple* antrun execution that removes the need for a complex workaround >> that might need to be unwound anyway is much better technical debt to >> leave >> for later... OTOH if it is a complex antrun execution then that would not >> be good technical debt to leave for later >> >> >> > This may be simple. I'll need to gather all of the files of a certain > name, concatenate them, and place them in build/site (ie., before the > packaging takes place). This way both the IDE and the resulting WAR file > will have access to the result. > > I like the idea of a simple marker that indicates a technical debt. It > looks like a good way to identify 'code smell' which needs to be addressed. > > Thanks again . . . > > > /mde/ > >On Apr 16, 2013 6:56 PM, "Mark Eggers" wrote: >>> Hi, > > I'm fairly new to Maven, and I'm trying to meet the following > requirements. > > 1. A web site consisting of multiple components, some optional > 2. Optional components each have some configuration files > 3. If multiple optional components are present, the configuration files > should be concatenated > > My first pass using WAR overlays and the shade plugin worked, in that > the > resulting site.war had all the right components. However, target/site > did > not contain the concatenated files created by the shade plugin. This > prevented target/site being run from within an IDE. > > If I thought about it for a minute, that's pretty obvious since the > shade > plugin is executed during the package part of the lifecycle. > > What I came up with is the following: > > 1. Create a multi-module project > 2. One module collects all of the components that require use of the > shade plugin > 3. The second module is the actual site, and depends on the > "collections" module > 4. Use the WAR plugin overlay, plus exclusions, plus the shade plugin > to create an intermediate WAR in the collections module > 5. Overlay that intermediate WAR on the final site > > This works except that I now have an extra artifact that is only used > during the build. I can run target/site from the IDE (great for > debugging) > and site.war looks as it should. > > Other than the fact that this works, is this the proper "Maven way"? > The > extra artifact (an artif
Re: Shade plugin plus WAR overlays
Comments in-line, and some of the original trimmed . . . On 4/16/2013 8:54 AM, Stephen Connolly wrote: On 16 April 2013 16:19, Mark Eggers wrote: On 4/16/2013 2:31 AM, Richard Vowles wrote: what needs concatenating? there isnt much designed to be anti-modular these days. Some properties files. I could possibly remove the properties files issue by either having the developers hand craft them for each project, or design a new modular configuration system. The first is error-prone, and the second will take a bit of time. I suppose an ant task would work as well, but since I'm trying to replace ant I would like to avoid falling back on it. I would not decry using antrun to work around a (hopefully) temporary issue. If it proves too difficult to move to a new modular configuration system, then I would look to replace that antrun with a plugin that does the merging for me, perhaps even defining a new packaging type so that I can just go eggers-war I'll have to investigate a new packaging type. I'm more or less a Maven newcomer, so that will take a little bit of effort. I am in huge favor of keeping the pom.xml file as simple and easily understood as possible. If I do come up with a new modular configuration system, e.g. using ClassLoader.getResources(path) rather that ClassLoader.getResource(path) and then just effectively concatenating all the .properties files within the app, then the antrun will just go away. I'll definitely try that. I'm mostly a systems architect, but I seem to be getting pulled into build and development issues these days. The change should be minor, and will definitely result in a more clearly decoupled modular system. Then the only issue becomes naming conventions so that there are no file name collisions. Having antrun there is a good tool to mark the fact that you have technical debt that will need to be repaid. When you are leaving technical debt the keys thing to remember are that: 1. it should be clear and obvious that it is technical debt 2. it should be as small as possible A *simple* antrun execution that removes the need for a complex workaround that might need to be unwound anyway is much better technical debt to leave for later... OTOH if it is a complex antrun execution then that would not be good technical debt to leave for later This may be simple. I'll need to gather all of the files of a certain name, concatenate them, and place them in build/site (ie., before the packaging takes place). This way both the IDE and the resulting WAR file will have access to the result. I like the idea of a simple marker that indicates a technical debt. It looks like a good way to identify 'code smell' which needs to be addressed. Thanks again . . . /mde/ On Apr 16, 2013 6:56 PM, "Mark Eggers" wrote: Hi, I'm fairly new to Maven, and I'm trying to meet the following requirements. 1. A web site consisting of multiple components, some optional 2. Optional components each have some configuration files 3. If multiple optional components are present, the configuration files should be concatenated My first pass using WAR overlays and the shade plugin worked, in that the resulting site.war had all the right components. However, target/site did not contain the concatenated files created by the shade plugin. This prevented target/site being run from within an IDE. If I thought about it for a minute, that's pretty obvious since the shade plugin is executed during the package part of the lifecycle. What I came up with is the following: 1. Create a multi-module project 2. One module collects all of the components that require use of the shade plugin 3. The second module is the actual site, and depends on the "collections" module 4. Use the WAR plugin overlay, plus exclusions, plus the shade plugin to create an intermediate WAR in the collections module 5. Overlay that intermediate WAR on the final site This works except that I now have an extra artifact that is only used during the build. I can run target/site from the IDE (great for debugging) and site.war looks as it should. Other than the fact that this works, is this the proper "Maven way"? The extra artifact (an artifact of the build process as it were) feels a little odd. . . . . just my two cents /mde/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Shade plugin plus WAR overlays
+1 Very well put! On 16/04/2013 11:54 AM, Stephen Connolly wrote: On 16 April 2013 16:19, Mark Eggers wrote: On 4/16/2013 2:31 AM, Richard Vowles wrote: what needs concatenating? there isnt much designed to be anti-modular these days. Some properties files. I could possibly remove the properties files issue by either having the developers hand craft them for each project, or design a new modular configuration system. The first is error-prone, and the second will take a bit of time. I suppose an ant task would work as well, but since I'm trying to replace ant I would like to avoid falling back on it. I would not decry using antrun to work around a (hopefully) temporary issue. If it proves too difficult to move to a new modular configuration system, then I would look to replace that antrun with a plugin that does the merging for me, perhaps even defining a new packaging type so that I can just go eggers-war If I do come up with a new modular configuration system, e.g. using ClassLoader.getResources(path) rather that ClassLoader.getResource(path) and then just effectively concatenating all the .properties files within the app, then the antrun will just go away. Having antrun there is a good tool to mark the fact that you have technical debt that will need to be repaid. When you are leaving technical debt the keys thing to remember are that: 1. it should be clear and obvious that it is technical debt 2. it should be as small as possible A *simple* antrun execution that removes the need for a complex workaround that might need to be unwound anyway is much better technical debt to leave for later... OTOH if it is a complex antrun execution then that would not be good technical debt to leave for later The current ant build is a rather fragile set of scripts that is very environment-dependent. The current pom.xml (actually three right now) is environment and IDE agnostic - which is the way I think things should be. Thanks for the feedback, folks. . . . . just my two cents. /mde/ On Apr 16, 2013 6:56 PM, "Mark Eggers" wrote: Hi, I'm fairly new to Maven, and I'm trying to meet the following requirements. 1. A web site consisting of multiple components, some optional 2. Optional components each have some configuration files 3. If multiple optional components are present, the configuration files should be concatenated My first pass using WAR overlays and the shade plugin worked, in that the resulting site.war had all the right components. However, target/site did not contain the concatenated files created by the shade plugin. This prevented target/site being run from within an IDE. If I thought about it for a minute, that's pretty obvious since the shade plugin is executed during the package part of the lifecycle. What I came up with is the following: 1. Create a multi-module project 2. One module collects all of the components that require use of the shade plugin 3. The second module is the actual site, and depends on the "collections" module 4. Use the WAR plugin overlay, plus exclusions, plus the shade plugin to create an intermediate WAR in the collections module 5. Overlay that intermediate WAR on the final site This works except that I now have an extra artifact that is only used during the build. I can run target/site from the IDE (great for debugging) and site.war looks as it should. Other than the fact that this works, is this the proper "Maven way"? The extra artifact (an artifact of the build process as it were) feels a little odd. . . . . just my two cents /mde/ --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Shade plugin plus WAR overlays
On 16 April 2013 16:19, Mark Eggers wrote: > On 4/16/2013 2:31 AM, Richard Vowles wrote: > >> what needs concatenating? there isnt much designed to be anti-modular >> these >> days. >> > > Some properties files. I could possibly remove the properties files issue > by either having the developers hand craft them for each project, or design > a new modular configuration system. The first is error-prone, and the > second will take a bit of time. > > I suppose an ant task would work as well, but since I'm trying to replace > ant I would like to avoid falling back on it. > I would not decry using antrun to work around a (hopefully) temporary issue. If it proves too difficult to move to a new modular configuration system, then I would look to replace that antrun with a plugin that does the merging for me, perhaps even defining a new packaging type so that I can just go eggers-war If I do come up with a new modular configuration system, e.g. using ClassLoader.getResources(path) rather that ClassLoader.getResource(path) and then just effectively concatenating all the .properties files within the app, then the antrun will just go away. Having antrun there is a good tool to mark the fact that you have technical debt that will need to be repaid. When you are leaving technical debt the keys thing to remember are that: 1. it should be clear and obvious that it is technical debt 2. it should be as small as possible A *simple* antrun execution that removes the need for a complex workaround that might need to be unwound anyway is much better technical debt to leave for later... OTOH if it is a complex antrun execution then that would not be good technical debt to leave for later > > The current ant build is a rather fragile set of scripts that is very > environment-dependent. The current pom.xml (actually three right now) is > environment and IDE agnostic - which is the way I think things should be. > > Thanks for the feedback, folks. > > . . . . just my two cents. > /mde/ > > > On Apr 16, 2013 6:56 PM, "Mark Eggers" wrote: >> >> Hi, >>> >>> I'm fairly new to Maven, and I'm trying to meet the following >>> requirements. >>> >>> 1. A web site consisting of multiple components, some optional >>> 2. Optional components each have some configuration files >>> 3. If multiple optional components are present, the configuration files >>> should be concatenated >>> >>> My first pass using WAR overlays and the shade plugin worked, in that the >>> resulting site.war had all the right components. However, target/site did >>> not contain the concatenated files created by the shade plugin. This >>> prevented target/site being run from within an IDE. >>> >>> If I thought about it for a minute, that's pretty obvious since the shade >>> plugin is executed during the package part of the lifecycle. >>> >>> What I came up with is the following: >>> >>> 1. Create a multi-module project >>> 2. One module collects all of the components that require use of the >>> shade plugin >>> 3. The second module is the actual site, and depends on the >>> "collections" module >>> 4. Use the WAR plugin overlay, plus exclusions, plus the shade plugin >>> to create an intermediate WAR in the collections module >>> 5. Overlay that intermediate WAR on the final site >>> >>> This works except that I now have an extra artifact that is only used >>> during the build. I can run target/site from the IDE (great for >>> debugging) >>> and site.war looks as it should. >>> >>> Other than the fact that this works, is this the proper "Maven way"? The >>> extra artifact (an artifact of the build process as it were) feels a >>> little >>> odd. >>> >>> . . . . just my two cents >>> /mde/ >>> >> > > --**--**- > To unsubscribe, e-mail: > users-unsubscribe@maven.**apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: [mojo-dev] Re: Build-Helper-Maven-Plugin / Build-MetaData-Maven-Plugin
http://developer-blog.cloudbees.com/2013/04/the-maven-way.html On 16 April 2013 16:16, Stephen Connolly wrote: > > > > On 16 April 2013 16:11, Mark H. Wood wrote: > >> On Mon, Apr 15, 2013 at 09:48:35PM +0100, Stephen Connolly wrote: >> [snip] >> > The reality is that the true goal of the Maven Way™ is that your pom >> should >> > be as close as possible to the following >> > >> > >> > ... >> > ... >> > ... >> > ... >> > >> > ... >> > >> > >> > >> > Every line you add to the above is moving further from the Maven Way™ >> >> Brilliant. The above describes what the project *is*. The more you >> have to tinker with plugins and the like, the more likely you are >> describing *how the project should be built*. But if I have >> understood the situation, Maven exists to figure out *how* after you >> have told it *what*. >> > > Yep, exactly! > > >> >> -- >> Mark H. Wood, Lead System Programmer mw...@iupui.edu >> Machines should not be friendly. Machines should be obedient. >> > >
Re: Shade plugin plus WAR overlays
On 4/16/2013 2:31 AM, Richard Vowles wrote: what needs concatenating? there isnt much designed to be anti-modular these days. Some properties files. I could possibly remove the properties files issue by either having the developers hand craft them for each project, or design a new modular configuration system. The first is error-prone, and the second will take a bit of time. I suppose an ant task would work as well, but since I'm trying to replace ant I would like to avoid falling back on it. The current ant build is a rather fragile set of scripts that is very environment-dependent. The current pom.xml (actually three right now) is environment and IDE agnostic - which is the way I think things should be. Thanks for the feedback, folks. . . . . just my two cents. /mde/ On Apr 16, 2013 6:56 PM, "Mark Eggers" wrote: Hi, I'm fairly new to Maven, and I'm trying to meet the following requirements. 1. A web site consisting of multiple components, some optional 2. Optional components each have some configuration files 3. If multiple optional components are present, the configuration files should be concatenated My first pass using WAR overlays and the shade plugin worked, in that the resulting site.war had all the right components. However, target/site did not contain the concatenated files created by the shade plugin. This prevented target/site being run from within an IDE. If I thought about it for a minute, that's pretty obvious since the shade plugin is executed during the package part of the lifecycle. What I came up with is the following: 1. Create a multi-module project 2. One module collects all of the components that require use of the shade plugin 3. The second module is the actual site, and depends on the "collections" module 4. Use the WAR plugin overlay, plus exclusions, plus the shade plugin to create an intermediate WAR in the collections module 5. Overlay that intermediate WAR on the final site This works except that I now have an extra artifact that is only used during the build. I can run target/site from the IDE (great for debugging) and site.war looks as it should. Other than the fact that this works, is this the proper "Maven way"? The extra artifact (an artifact of the build process as it were) feels a little odd. . . . . just my two cents /mde/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [mojo-dev] Re: Build-Helper-Maven-Plugin / Build-MetaData-Maven-Plugin
On 16 April 2013 16:11, Mark H. Wood wrote: > On Mon, Apr 15, 2013 at 09:48:35PM +0100, Stephen Connolly wrote: > [snip] > > The reality is that the true goal of the Maven Way™ is that your pom > should > > be as close as possible to the following > > > > > > ... > > ... > > ... > > ... > > > > ... > > > > > > > > Every line you add to the above is moving further from the Maven Way™ > > Brilliant. The above describes what the project *is*. The more you > have to tinker with plugins and the like, the more likely you are > describing *how the project should be built*. But if I have > understood the situation, Maven exists to figure out *how* after you > have told it *what*. > Yep, exactly! > > -- > Mark H. Wood, Lead System Programmer mw...@iupui.edu > Machines should not be friendly. Machines should be obedient. >
Re: [mojo-dev] Re: Build-Helper-Maven-Plugin / Build-MetaData-Maven-Plugin
On Mon, Apr 15, 2013 at 09:48:35PM +0100, Stephen Connolly wrote: [snip] > The reality is that the true goal of the Maven Way™ is that your pom should > be as close as possible to the following > > > ... > ... > ... > ... > > ... > > > > Every line you add to the above is moving further from the Maven Way™ Brilliant. The above describes what the project *is*. The more you have to tinker with plugins and the like, the more likely you are describing *how the project should be built*. But if I have understood the situation, Maven exists to figure out *how* after you have told it *what*. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature
RE: Maven-release-plugin error
Hi Mirko, Thank you for your answers. What do you mean by check out to: c:/tmp/myprj ?? Do I use below switch for that? mvn -B -Dresume=false -DworkingDirectory=/tmp/myprj release:prepare release:perform BTW: regarding naming the workspace We have build workspace specific to a stream so for my development stream I have a build workspace (RTC notation) named as: 'srvrtcbuild-EI AS-ITAM uCMDB 9.02 EI Stream Workspace' So we don't rename workspace with each build... Is there a way to make release plug-in use the same workspace name I provided? Looks like it wants to use tag it created based on build numbers. Is there a way to override that? I want release-plugin to snapshot (aka label) source code in the build workspace with the build version (or tag) but NOT use tag as the name of the workspace. Thanks, Robert -Original Message- From: Mirko Friedenhagen [mailto:mfriedenha...@gmail.com] Sent: Saturday, April 13, 2013 1:44 AM To: Maven Users List Subject: Re: Maven-release-plugin error Third guess, on Windows upper and lower case are ignored, so C:/tm/ucmdb and naming the tag ucmdb-patterndev-0.6.6 could help. Regards Mirko -- Sent from my mobile On Apr 12, 2013 8:59 PM, "Zanzerkia, Robert" wrote: > > Hi, > I am getting below error (SCM is Jazz RTC). > Is there some convention about workspace name and snapshot name has to > match? > Is there a switch to override it? > I also noticed that the original workspace I had specified get's changed > as follows... > RTCURL:PORT are replaced with real ones in my POM. > > > scm:jazz:https://RTCURL:PROT > /jazz:uCMDB-PatternDev-0.0.6 > > scm:jazz:https://RTCURL:PROT:uCMDB-PatternDev-0.0.6 > > https://RTCURL:PROT/jazz:uCMDB-PatternDev-0.0.6 > > > > > > Thanks, > Robert > > [INFO] Tagging release with the label uCMDB-PatternDev-0.0.6... > [INFO] Executing: cmd.exe /X /C "scm status --username a408072 --password > * > --wide" > [INFO] Working directory: C:\Documents and > Settings\a408072.DMN1\workspace301\EI > AS-ITAM uCMDB Pattern DEV > [INFO] Executing: cmd.exe /X /C "scm create snapshot --repository-uri > https://RTCURLHERE/jazz --username x --password * --name > uCMDB-PatternDev-0 > .0.6 --description "[maven-release-plugin] copy for tag > uCMDB-PatternDev-0.0.6" > uCMDB-PatternDev-0.0.6" > [INFO] Working directory: C:\Documents and > Settings\a408072.DMN1\workspace301\EI > AS-ITAM uCMDB Pattern DEV > [ERROR] Error: Selector "uCMDB-PatternDev-0.0.6" did not match any > workspaces > Problem running 'create snapshot': > Could not find workspace or stream specified by selector > "uCMDB-PatternDev-0.0.6 > " > > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 2:09.255s > [INFO] Finished at: Fri Apr 12 11:33:22 EDT 2013 > [INFO] Final Memory: 9M/247M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-release-plugin:2.4 > .1:prepare (default-cli) on project uCMDB-PatternDev: Unable to tag SCM > [ERROR] Provider message: > [ERROR] Error code for Jazz SCM tag (SNAPSHOT) command - 9 > [ERROR] Command output: > [ERROR] Selector "uCMDB-PatternDev-0.0.6" did not match any workspaces > [ERROR] Problem running 'create snapshot': > [ERROR] Could not find workspace or stream specified by selector > "uCMDB-PatternD > ev-0.0.6" > [ERROR] -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the > -e swit > ch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, > please rea > d the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureExc > eption > > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Shade plugin plus WAR overlays
what needs concatenating? there isnt much designed to be anti-modular these days. On Apr 16, 2013 6:56 PM, "Mark Eggers" wrote: > Hi, > > I'm fairly new to Maven, and I'm trying to meet the following requirements. > > 1. A web site consisting of multiple components, some optional > 2. Optional components each have some configuration files > 3. If multiple optional components are present, the configuration files >should be concatenated > > My first pass using WAR overlays and the shade plugin worked, in that the > resulting site.war had all the right components. However, target/site did > not contain the concatenated files created by the shade plugin. This > prevented target/site being run from within an IDE. > > If I thought about it for a minute, that's pretty obvious since the shade > plugin is executed during the package part of the lifecycle. > > What I came up with is the following: > > 1. Create a multi-module project > 2. One module collects all of the components that require use of the >shade plugin > 3. The second module is the actual site, and depends on the >"collections" module > 4. Use the WAR plugin overlay, plus exclusions, plus the shade plugin >to create an intermediate WAR in the collections module > 5. Overlay that intermediate WAR on the final site > > This works except that I now have an extra artifact that is only used > during the build. I can run target/site from the IDE (great for debugging) > and site.war looks as it should. > > Other than the fact that this works, is this the proper "Maven way"? The > extra artifact (an artifact of the build process as it were) feels a little > odd. > > . . . . just my two cents > /mde/ > > --**--**- > To unsubscribe, e-mail: > users-unsubscribe@maven.**apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Shade plugin plus WAR overlays
On Tuesday, 16 April 2013, Mark Eggers wrote: > Hi, > > I'm fairly new to Maven, and I'm trying to meet the following requirements. > > 1. A web site consisting of multiple components, some optional > 2. Optional components each have some configuration files > 3. If multiple optional components are present, the configuration files >should be concatenated > > My first pass using WAR overlays and the shade plugin worked, in that the > resulting site.war had all the right components. However, target/site did > not contain the concatenated files created by the shade plugin. This > prevented target/site being run from within an IDE. > > If I thought about it for a minute, that's pretty obvious since the shade > plugin is executed during the package part of the lifecycle. > > What I came up with is the following: > > 1. Create a multi-module project > 2. One module collects all of the components that require use of the >shade plugin > 3. The second module is the actual site, and depends on the >"collections" module > 4. Use the WAR plugin overlay, plus exclusions, plus the shade plugin >to create an intermediate WAR in the collections module > 5. Overlay that intermediate WAR on the final site > > This works except that I now have an extra artifact that is only used > during the build. I can run target/site from the IDE (great for debugging) > and site.war looks as it should. > > Other than the fact that this works, is this the proper "Maven way"? The > extra artifact (an artifact of the build process as it were) feels a little > odd. Well it sounds like you are removing complexity in 1 pom by creating a few (individually) less complex poms and using the reactor to reference modules... As a principle that is more the Maven Way than a 1000 line pom that does it all "by magic" I've not seen people using shade with a war module, that's a use case that perhaps needs exploring > . . . . just my two cents > /mde/ > > --**--**- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Sent from my phone
