Now I think I understand what you mean by "something similar". The main problem I see with using the assembly plugin is the amount of configuration needed for packaging and depackaging of resources to work. Indeed, if it was possible to specify an dependency as overlaid instead of included, this would simplify depackaging resources. But then you could not just package those resources in a mere JAR, otherwise how could you differentiate included JARs and overlaid JARs. The maven war plugin automatically overlays WAR dependencies and includes JAR dependencies.
So here's my proposition: - modules containing only resources have their packaging set to "resource" - such modules are automatically packaged in a zip format - when specifying a zip dependency in any module (jar or war packaging), it's overlaid instead of being included Is it already possible AND simple to configure? If not is it a better practice? Does it require new development? (in which case this discussion is good for the development list) 2008/4/13, Tim O'Brien <[EMAIL PROTECTED]>: > > 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] > > -- Sébastien Arbogast http://sebastien-arbogast.com
