On 4/16/2013 9:33 AM, Stephen Connolly wrote:
On 16 April 2013 17:25, Mark Eggers <its_toas...@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_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>
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" <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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
