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.
