On 16 April 2013 16:19, Mark Eggers <its_toas...@yahoo.com> 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 <packaging>eggers-war</packaging> 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" <its_toas...@yahoo.com> 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<users-unsubscr...@maven.apache.org> > > For additional commands, e-mail: users-h...@maven.apache.org > >
