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.
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" <[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: [email protected]
For additional commands, e-mail: [email protected]
