maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Shade plugin plus WAR overlays
Date Tue, 16 Apr 2013 19:43:44 GMT
On 16 April 2013 17:57, Mark Eggers <its_toasted@yahoo.com> wrote:

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message