I like this Idea.... Some resources packaging.
If its not possible, we can create a simple mojo on flex-mojos, only to handle configurations. What you think? VELO On Sun, Apr 13, 2008 at 3:49 PM, Sebastien ARBOGAST < [EMAIL PROTECTED]> wrote: > 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 >
