Even though we happen to all be developers, this discussion may be
more appropriate on the users list.
Sebastien, have you looked at the overlay feature of the WAR plugin? http://maven.apache.org/plugins/maven-war-plugin/examples/war-overlay.html
Are you proposing that a similar idea be generalized for other
projects? I know this still might no fit your definition of
reasonable, but it might just be what you were looking for.
Tim
On Apr 13, 2008, at 11:56 AM, Sejal Patel wrote:
Hi Sebastien, you are right that this is a common problem and has no
clean
solution. Partly because of this limitation, at my job I've
instituted some
rules as part of the project standards. Any "resources" instead of
being
placed in the src/main/resources are now placed in src/main/packages
and
I've written a custom plugin that goes through and does a few things
actually but one thing is to create the same artifact jar with a
different
classifier called "${artifactId}-${version}-external-${envName}.jar"
in our
case for externalized resources.
The custom plugin also allows you to do either a -Denv=foo to
automatically
filter the src/main/package with a filter located in the src/main/
filters.
For instance -Denv=prod would filter using src/main/filters/
prod.properties.
This would produce a classifier called
${artifactId}-${version}-external-prod.jar
It also supports doing a -Dfilter=~/myfilters/custom.properties to
allow
filtering of the src/main/package contents with individual
filterings. This
would produce a classifier called
${artifactId}-${version}-external-${user.name}.jar
In both cases filtering values default to
src/main/filters/default.properties
What this does is allow you to treat resources as external
configurations of
sorts and still allows you to filter them on an environment level
(test,
dev, qa, ref, prod, etc ....) which are stored in the repository as
well as
local developer filtering which sits only on the developers machine
and
doesn't clutter the filters with 30 different custom filters that
are only
meaningful to a single person.
And as a general rule of thumb, we mark that resource in the pom.xml
as a
scope of "provided" in order to prevent the wrong configurations
from being
pushed out to the wrong environments and such. And the pom.xml
contains the
"test" filtered in the test scope for use with unit tests.
So our "base" project will contain the shared resources and the
modules will
include the base projects external-test classified resource within
them for
use with testing and such. Modules which produce applications (stand
alone
or web) include the external-default as a provided and/or rely on
assembly
to pull in the correct one to be used.
On Sun, Apr 13, 2008 at 5:31 AM, Sebastien ARBOGAST <
[EMAIL PROTECTED]> wrote:
Hi guys,
I've had a comment exchange on my blog with Brian Fox (
http://sebastien-arbogast.com/index.php/2008/04/11/flex-spring-and-blazeds-the-full-stack-part-2/#comment-126
)
because I would like to find a natural solution to share
confirguration
files between two modules. In this case, I'm building a
Flex+BlazeDS+Spring
applications with two modules, one for the flex part, and the other
one
for
the web application. And both of those modules need the same
configuration
files.
For now, the only solution I've found is to duplicate those files in
src/main/resources for each module.
Brian suggested that I could put those files in a third module to
package
them up using assembly, and then retrieve these in both modules
that need
it. But it doesn't seem very natural to me.
As a matter of fact, I don't think that this use case is very rare. I
mean,
there are situatiosn where you want to reuse icon graphics or
configuration
files in several modules. And it would be great if we could place
those
resources in the parent module and have the submodules inherit
resources
from their parent.
What do you think? Would it be feasible? Would it be okay with best
practices promoted by Maven?
--
Sébastien Arbogast
http://sebastien-arbogast.com
--
Justice is nothing more than that which is in the greatest self-
interest of
the largest portion of the population.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
