On 16 April 2013 17:57, Mark Eggers <[email protected]> wrote: > On 4/16/2013 9:33 AM, Stephen Connolly wrote: > >> On 16 April 2013 17:25, Mark Eggers <[email protected]> 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 <[email protected]> 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> >>>> >>>> >>>> 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" <[email protected]> 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.**apac**he.org<http://apache.org> >>> <users-unsubscribe@**maven.apache.org<[email protected]> >>> > >>> >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@maven.**apache.org<[email protected]> > For additional commands, e-mail: [email protected] > >
