Re: Inheriting resources
On Thu, 17 Apr 2008, Sebastien ARBOGAST wrote: I've been trying to make it work with assembly plugin but configuration is quite heavy. I manage to archive my configuration files in a zip file, but then how do I configure the other modules to unpack the archive (just this one) to the right directory? Far too much hassle. I had the same usecase - and ended up using the dependency plugin to unpack the archived config - maybe that could work for you too? -- David J. M. Karlsen - +47 90 68 22 43 http://www.davidkarlsen.com http://mp3.davidkarlsen.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inheriting resources
Thanks a lot Brian. I just updated my article series to avoid configuration file duplication based on your tutorial. But to all Maven developers, I really think that it should be simpler to do that out of the box. 2008/4/18, Brian E. Fox <[EMAIL PROTECTED]>: > > I made this into a tutorial: > > > http://www.dzone.com/links/how_to_share_resources_across_projects_in_maven.html > > > -Original Message- > From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED] > > Sent: Thursday, April 17, 2008 4:27 PM > To: Maven Developers List > Subject: Re: Inheriting resources > > Sorry to ask but could you provide me with an example please? Because I > just > don't see those options in the documentation and I don't know where to put > them. > > 2008/4/17, Brian E. Fox <[EMAIL PROTECTED]>: > > > > You can specify includeArtifactId=xxx and includeGroupId=xxx and this > > essentially narrows down to the one you want. (you could also do > type=zip > > etc and they can be combined) > > > > > > > > -Original Message- > > From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED] > > > > Sent: Thursday, April 17, 2008 3:51 PM > > To: Maven Developers List > > > > Subject: Re: Inheriting resources > > > > But how can I choose specifically this one and not unpack all the other > > dependencies in the same place. I didn't find any configuration showing > > that > > level of granularity. > > > > 2008/4/17, Brian E. Fox <[EMAIL PROTECTED]>: > > > > > > You can use dependency:unpack/unpack-dependencies to retrieve them and > > put > > > 'em were you need 'em > > > > > > > > > -Original Message- > > > From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, April 17, 2008 3:40 PM > > > To: Maven Developers List; [EMAIL PROTECTED] > > > Subject: Re: Inheriting resources > > > > > > I've been trying to make it work with assembly plugin but > configuration > > is > > > quite heavy. I manage to archive my configuration files in a zip file, > > but > > > then how do I configure the other modules to unpack the archive (just > > this > > > one) to the right directory? Far too much hassle. > > > > > > I'm starting to think that duplicating those configuration files is > like > > > the > > > "least bad" solution. > > > > > > 2008/4/14, VELO <[EMAIL PROTECTED]>: > > > > > > > > At current stage flex-compiler-plugin look at all resources folder > > > > (project.getBuild().getResources()) for configuration files. > > > > > > > > Is possible too specify some relative path, such as > > > > .../.../anotherProject/src/main/resources/config.xml > > > > But this has a lot of problems,.. > > > > > > > > > > > > VELO > > > > > > > > On Mon, Apr 14, 2008 at 12:09 PM, Brian E. Fox < > > [EMAIL PROTECTED] > > > > > > > > wrote: > > > > > > > > > > > > > I think there could be some value to making resource sharing a > > little > > > > > easier out of the box. Naturally it won't fit all instances but > > those > > > > > other instances can already be solved with assembly and or > > > > > remote-resources > > > > > > > > > > We currently package up the site descriptor for a parent and that > > gets > > > > > inherited by the children. I think we could leverage the > > > > > remote-resources and do something similar. If you put files in the > > > > > src/main/resources of a pom, we could automatically pick those up > > and > > > > > deploy them as a resource bundle. Then in the children we could > > > augment > > > > > the resources model to specify to inherit the resources from the > > > parents > > > > > and the plugin could be smart enough to find them on the disk or > > from > > > > > the repo. > > > > > > > > > > -Original Message- > > > > > From: Benjamin Bentmann [mailto:[EMAIL PROTECTED] > > > > > Sent: Sunday, April 13, 2008 6:06 AM > > > > > To: Maven Developers List > > > > > Subject: Re: Inheriting resources > > > > > > > > > > Sebastien ARBOGAST wrote: > > > > >
RE: Inheriting resources
I made this into a tutorial: http://www.dzone.com/links/how_to_share_resources_across_projects_in_maven.html -Original Message- From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED] Sent: Thursday, April 17, 2008 4:27 PM To: Maven Developers List Subject: Re: Inheriting resources Sorry to ask but could you provide me with an example please? Because I just don't see those options in the documentation and I don't know where to put them. 2008/4/17, Brian E. Fox <[EMAIL PROTECTED]>: > > You can specify includeArtifactId=xxx and includeGroupId=xxx and this > essentially narrows down to the one you want. (you could also do type=zip > etc and they can be combined) > > > > -Original Message- > From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED] > > Sent: Thursday, April 17, 2008 3:51 PM > To: Maven Developers List > > Subject: Re: Inheriting resources > > But how can I choose specifically this one and not unpack all the other > dependencies in the same place. I didn't find any configuration showing > that > level of granularity. > > 2008/4/17, Brian E. Fox <[EMAIL PROTECTED]>: > > > > You can use dependency:unpack/unpack-dependencies to retrieve them and > put > > 'em were you need 'em > > > > > > -Original Message- > > From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED] > > Sent: Thursday, April 17, 2008 3:40 PM > > To: Maven Developers List; [EMAIL PROTECTED] > > Subject: Re: Inheriting resources > > > > I've been trying to make it work with assembly plugin but configuration > is > > quite heavy. I manage to archive my configuration files in a zip file, > but > > then how do I configure the other modules to unpack the archive (just > this > > one) to the right directory? Far too much hassle. > > > > I'm starting to think that duplicating those configuration files is like > > the > > "least bad" solution. > > > > 2008/4/14, VELO <[EMAIL PROTECTED]>: > > > > > > At current stage flex-compiler-plugin look at all resources folder > > > (project.getBuild().getResources()) for configuration files. > > > > > > Is possible too specify some relative path, such as > > > .../.../anotherProject/src/main/resources/config.xml > > > But this has a lot of problems,.. > > > > > > > > > VELO > > > > > > On Mon, Apr 14, 2008 at 12:09 PM, Brian E. Fox < > [EMAIL PROTECTED] > > > > > > wrote: > > > > > > > > > > I think there could be some value to making resource sharing a > little > > > > easier out of the box. Naturally it won't fit all instances but > those > > > > other instances can already be solved with assembly and or > > > > remote-resources > > > > > > > > We currently package up the site descriptor for a parent and that > gets > > > > inherited by the children. I think we could leverage the > > > > remote-resources and do something similar. If you put files in the > > > > src/main/resources of a pom, we could automatically pick those up > and > > > > deploy them as a resource bundle. Then in the children we could > > augment > > > > the resources model to specify to inherit the resources from the > > parents > > > > and the plugin could be smart enough to find them on the disk or > from > > > > the repo. > > > > > > > > -Original Message- > > > > From: Benjamin Bentmann [mailto:[EMAIL PROTECTED] > > > > Sent: Sunday, April 13, 2008 6:06 AM > > > > To: Maven Developers List > > > > Subject: Re: Inheriting resources > > > > > > > > Sebastien ARBOGAST wrote: > > > > > I would like to find a natural solution to share confirguration > > > > > files between two modules. [...] > > > > > 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 wa
RE: Inheriting resources
Sure, I will send one tonight. -Original Message- From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED] Sent: Thursday, April 17, 2008 4:27 PM To: Maven Developers List Subject: Re: Inheriting resources Sorry to ask but could you provide me with an example please? Because I just don't see those options in the documentation and I don't know where to put them. 2008/4/17, Brian E. Fox <[EMAIL PROTECTED]>: > > You can specify includeArtifactId=xxx and includeGroupId=xxx and this > essentially narrows down to the one you want. (you could also do type=zip > etc and they can be combined) > > > > -Original Message- > From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED] > > Sent: Thursday, April 17, 2008 3:51 PM > To: Maven Developers List > > Subject: Re: Inheriting resources > > But how can I choose specifically this one and not unpack all the other > dependencies in the same place. I didn't find any configuration showing > that > level of granularity. > > 2008/4/17, Brian E. Fox <[EMAIL PROTECTED]>: > > > > You can use dependency:unpack/unpack-dependencies to retrieve them and > put > > 'em were you need 'em > > > > > > -Original Message- > > From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED] > > Sent: Thursday, April 17, 2008 3:40 PM > > To: Maven Developers List; [EMAIL PROTECTED] > > Subject: Re: Inheriting resources > > > > I've been trying to make it work with assembly plugin but configuration > is > > quite heavy. I manage to archive my configuration files in a zip file, > but > > then how do I configure the other modules to unpack the archive (just > this > > one) to the right directory? Far too much hassle. > > > > I'm starting to think that duplicating those configuration files is like > > the > > "least bad" solution. > > > > 2008/4/14, VELO <[EMAIL PROTECTED]>: > > > > > > At current stage flex-compiler-plugin look at all resources folder > > > (project.getBuild().getResources()) for configuration files. > > > > > > Is possible too specify some relative path, such as > > > .../.../anotherProject/src/main/resources/config.xml > > > But this has a lot of problems,.. > > > > > > > > > VELO > > > > > > On Mon, Apr 14, 2008 at 12:09 PM, Brian E. Fox < > [EMAIL PROTECTED] > > > > > > wrote: > > > > > > > > > > I think there could be some value to making resource sharing a > little > > > > easier out of the box. Naturally it won't fit all instances but > those > > > > other instances can already be solved with assembly and or > > > > remote-resources > > > > > > > > We currently package up the site descriptor for a parent and that > gets > > > > inherited by the children. I think we could leverage the > > > > remote-resources and do something similar. If you put files in the > > > > src/main/resources of a pom, we could automatically pick those up > and > > > > deploy them as a resource bundle. Then in the children we could > > augment > > > > the resources model to specify to inherit the resources from the > > parents > > > > and the plugin could be smart enough to find them on the disk or > from > > > > the repo. > > > > > > > > -Original Message- > > > > From: Benjamin Bentmann [mailto:[EMAIL PROTECTED] > > > > Sent: Sunday, April 13, 2008 6:06 AM > > > > To: Maven Developers List > > > > Subject: Re: Inheriting resources > > > > > > > > Sebastien ARBOGAST wrote: > > > > > I would like to find a natural solution to share confirguration > > > > > files between two modules. [...] > > > > > 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 > >
Re: Inheriting resources
Sorry to ask but could you provide me with an example please? Because I just don't see those options in the documentation and I don't know where to put them. 2008/4/17, Brian E. Fox <[EMAIL PROTECTED]>: > > You can specify includeArtifactId=xxx and includeGroupId=xxx and this > essentially narrows down to the one you want. (you could also do type=zip > etc and they can be combined) > > > > -Original Message- > From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED] > > Sent: Thursday, April 17, 2008 3:51 PM > To: Maven Developers List > > Subject: Re: Inheriting resources > > But how can I choose specifically this one and not unpack all the other > dependencies in the same place. I didn't find any configuration showing > that > level of granularity. > > 2008/4/17, Brian E. Fox <[EMAIL PROTECTED]>: > > > > You can use dependency:unpack/unpack-dependencies to retrieve them and > put > > 'em were you need 'em > > > > > > -Original Message- > > From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED] > > Sent: Thursday, April 17, 2008 3:40 PM > > To: Maven Developers List; [EMAIL PROTECTED] > > Subject: Re: Inheriting resources > > > > I've been trying to make it work with assembly plugin but configuration > is > > quite heavy. I manage to archive my configuration files in a zip file, > but > > then how do I configure the other modules to unpack the archive (just > this > > one) to the right directory? Far too much hassle. > > > > I'm starting to think that duplicating those configuration files is like > > the > > "least bad" solution. > > > > 2008/4/14, VELO <[EMAIL PROTECTED]>: > > > > > > At current stage flex-compiler-plugin look at all resources folder > > > (project.getBuild().getResources()) for configuration files. > > > > > > Is possible too specify some relative path, such as > > > .../.../anotherProject/src/main/resources/config.xml > > > But this has a lot of problems,.. > > > > > > > > > VELO > > > > > > On Mon, Apr 14, 2008 at 12:09 PM, Brian E. Fox < > [EMAIL PROTECTED] > > > > > > wrote: > > > > > > > > > > I think there could be some value to making resource sharing a > little > > > > easier out of the box. Naturally it won't fit all instances but > those > > > > other instances can already be solved with assembly and or > > > > remote-resources > > > > > > > > We currently package up the site descriptor for a parent and that > gets > > > > inherited by the children. I think we could leverage the > > > > remote-resources and do something similar. If you put files in the > > > > src/main/resources of a pom, we could automatically pick those up > and > > > > deploy them as a resource bundle. Then in the children we could > > augment > > > > the resources model to specify to inherit the resources from the > > parents > > > > and the plugin could be smart enough to find them on the disk or > from > > > > the repo. > > > > > > > > -Original Message- > > > > From: Benjamin Bentmann [mailto:[EMAIL PROTECTED] > > > > Sent: Sunday, April 13, 2008 6:06 AM > > > > To: Maven Developers List > > > > Subject: Re: Inheriting resources > > > > > > > > Sebastien ARBOGAST wrote: > > > > > I would like to find a natural solution to share confirguration > > > > > files between two modules. [...] > > > > > 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 > > > >
RE: Inheriting resources
You can specify includeArtifactId=xxx and includeGroupId=xxx and this essentially narrows down to the one you want. (you could also do type=zip etc and they can be combined) -Original Message- From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED] Sent: Thursday, April 17, 2008 3:51 PM To: Maven Developers List Subject: Re: Inheriting resources But how can I choose specifically this one and not unpack all the other dependencies in the same place. I didn't find any configuration showing that level of granularity. 2008/4/17, Brian E. Fox <[EMAIL PROTECTED]>: > > You can use dependency:unpack/unpack-dependencies to retrieve them and put > 'em were you need 'em > > > -Original Message- > From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 17, 2008 3:40 PM > To: Maven Developers List; [EMAIL PROTECTED] > Subject: Re: Inheriting resources > > I've been trying to make it work with assembly plugin but configuration is > quite heavy. I manage to archive my configuration files in a zip file, but > then how do I configure the other modules to unpack the archive (just this > one) to the right directory? Far too much hassle. > > I'm starting to think that duplicating those configuration files is like > the > "least bad" solution. > > 2008/4/14, VELO <[EMAIL PROTECTED]>: > > > > At current stage flex-compiler-plugin look at all resources folder > > (project.getBuild().getResources()) for configuration files. > > > > Is possible too specify some relative path, such as > > .../.../anotherProject/src/main/resources/config.xml > > But this has a lot of problems,.. > > > > > > VELO > > > > On Mon, Apr 14, 2008 at 12:09 PM, Brian E. Fox <[EMAIL PROTECTED] > > > > wrote: > > > > > > > I think there could be some value to making resource sharing a little > > > easier out of the box. Naturally it won't fit all instances but those > > > other instances can already be solved with assembly and or > > > remote-resources > > > > > > We currently package up the site descriptor for a parent and that gets > > > inherited by the children. I think we could leverage the > > > remote-resources and do something similar. If you put files in the > > > src/main/resources of a pom, we could automatically pick those up and > > > deploy them as a resource bundle. Then in the children we could > augment > > > the resources model to specify to inherit the resources from the > parents > > > and the plugin could be smart enough to find them on the disk or from > > > the repo. > > > > > > -Original Message- > > > From: Benjamin Bentmann [mailto:[EMAIL PROTECTED] > > > Sent: Sunday, April 13, 2008 6:06 AM > > > To: Maven Developers List > > > Subject: Re: Inheriting resources > > > > > > Sebastien ARBOGAST wrote: > > > > I would like to find a natural solution to share confirguration > > > > files between two modules. [...] > > > > 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? > > > > > > I'm used to think of projects as independent build units. More > > > precisely, I > > > expect the following to work: > > > - checkout an arbitrary project/module, i.e. not necessarily a whole > > > trunk > > > - run any build command on this checkout, it should succeed > > > > > > Now, if I checked out one of your sub-modules how should it inherit > its > > > resources from the parent which is not on my local disk? Maven can > > > retrieve > >
Re: Inheriting resources
Thinking MavenProject has the list of resources, right? http://maven.apache.org/ref/2.0.4/maven-project/apidocs/org/apache/maven/project/MavenProject.html#getResources() So, exists any kind of dependency/plugin/whatever who allow me to define the dependency A must be maped into resources list? VELO On Thu, Apr 17, 2008 at 4:51 PM, Sebastien ARBOGAST < [EMAIL PROTECTED]> wrote: > But how can I choose specifically this one and not unpack all the other > dependencies in the same place. I didn't find any configuration showing > that > level of granularity. > > 2008/4/17, Brian E. Fox <[EMAIL PROTECTED]>: > > > > You can use dependency:unpack/unpack-dependencies to retrieve them and > put > > 'em were you need 'em > > > > > > -Original Message- > > From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED] > > Sent: Thursday, April 17, 2008 3:40 PM > > To: Maven Developers List; [EMAIL PROTECTED] > > Subject: Re: Inheriting resources > > > > I've been trying to make it work with assembly plugin but configuration > is > > quite heavy. I manage to archive my configuration files in a zip file, > but > > then how do I configure the other modules to unpack the archive (just > this > > one) to the right directory? Far too much hassle. > > > > I'm starting to think that duplicating those configuration files is like > > the > > "least bad" solution. > > > > 2008/4/14, VELO <[EMAIL PROTECTED]>: > > > > > > At current stage flex-compiler-plugin look at all resources folder > > > (project.getBuild().getResources()) for configuration files. > > > > > > Is possible too specify some relative path, such as > > > .../.../anotherProject/src/main/resources/config.xml > > > But this has a lot of problems,.. > > > > > > > > > VELO > > > > > > On Mon, Apr 14, 2008 at 12:09 PM, Brian E. Fox < > [EMAIL PROTECTED] > > > > > > wrote: > > > > > > > > > > I think there could be some value to making resource sharing a > little > > > > easier out of the box. Naturally it won't fit all instances but > those > > > > other instances can already be solved with assembly and or > > > > remote-resources > > > > > > > > We currently package up the site descriptor for a parent and that > gets > > > > inherited by the children. I think we could leverage the > > > > remote-resources and do something similar. If you put files in the > > > > src/main/resources of a pom, we could automatically pick those up > and > > > > deploy them as a resource bundle. Then in the children we could > > augment > > > > the resources model to specify to inherit the resources from the > > parents > > > > and the plugin could be smart enough to find them on the disk or > from > > > > the repo. > > > > > > > > -Original Message- > > > > From: Benjamin Bentmann [mailto:[EMAIL PROTECTED] > > > > Sent: Sunday, April 13, 2008 6:06 AM > > > > To: Maven Developers List > > > > Subject: Re: Inheriting resources > > > > > > > > Sebastien ARBOGAST wrote: > > > > > I would like to find a natural solution to share confirguration > > > > > files between two modules. [...] > > > > > 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? > &g
Re: Inheriting resources
But how can I choose specifically this one and not unpack all the other dependencies in the same place. I didn't find any configuration showing that level of granularity. 2008/4/17, Brian E. Fox <[EMAIL PROTECTED]>: > > You can use dependency:unpack/unpack-dependencies to retrieve them and put > 'em were you need 'em > > > -Original Message- > From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 17, 2008 3:40 PM > To: Maven Developers List; [EMAIL PROTECTED] > Subject: Re: Inheriting resources > > I've been trying to make it work with assembly plugin but configuration is > quite heavy. I manage to archive my configuration files in a zip file, but > then how do I configure the other modules to unpack the archive (just this > one) to the right directory? Far too much hassle. > > I'm starting to think that duplicating those configuration files is like > the > "least bad" solution. > > 2008/4/14, VELO <[EMAIL PROTECTED]>: > > > > At current stage flex-compiler-plugin look at all resources folder > > (project.getBuild().getResources()) for configuration files. > > > > Is possible too specify some relative path, such as > > .../.../anotherProject/src/main/resources/config.xml > > But this has a lot of problems,.. > > > > > > VELO > > > > On Mon, Apr 14, 2008 at 12:09 PM, Brian E. Fox <[EMAIL PROTECTED] > > > > wrote: > > > > > > > I think there could be some value to making resource sharing a little > > > easier out of the box. Naturally it won't fit all instances but those > > > other instances can already be solved with assembly and or > > > remote-resources > > > > > > We currently package up the site descriptor for a parent and that gets > > > inherited by the children. I think we could leverage the > > > remote-resources and do something similar. If you put files in the > > > src/main/resources of a pom, we could automatically pick those up and > > > deploy them as a resource bundle. Then in the children we could > augment > > > the resources model to specify to inherit the resources from the > parents > > > and the plugin could be smart enough to find them on the disk or from > > > the repo. > > > > > > -Original Message- > > > From: Benjamin Bentmann [mailto:[EMAIL PROTECTED] > > > Sent: Sunday, April 13, 2008 6:06 AM > > > To: Maven Developers List > > > Subject: Re: Inheriting resources > > > > > > Sebastien ARBOGAST wrote: > > > > I would like to find a natural solution to share confirguration > > > > files between two modules. [...] > > > > 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? > > > > > > I'm used to think of projects as independent build units. More > > > precisely, I > > > expect the following to work: > > > - checkout an arbitrary project/module, i.e. not necessarily a whole > > > trunk > > > - run any build command on this checkout, it should succeed > > > > > > Now, if I checked out one of your sub-modules how should it inherit > its > > > resources from the parent which is not on my local disk? Maven can > > > retrieve > > > the POM and the site descriptor from the remote repo but anything else > > > (like > > > resources) from the parent project is not shared via the repo. > > > > > > For the above reason, you would need to package the resources up into > a > > > JAR > > > that can be deployed to the repos. May
RE: Inheriting resources
You can use dependency:unpack/unpack-dependencies to retrieve them and put 'em were you need 'em -Original Message- From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED] Sent: Thursday, April 17, 2008 3:40 PM To: Maven Developers List; [EMAIL PROTECTED] Subject: Re: Inheriting resources I've been trying to make it work with assembly plugin but configuration is quite heavy. I manage to archive my configuration files in a zip file, but then how do I configure the other modules to unpack the archive (just this one) to the right directory? Far too much hassle. I'm starting to think that duplicating those configuration files is like the "least bad" solution. 2008/4/14, VELO <[EMAIL PROTECTED]>: > > At current stage flex-compiler-plugin look at all resources folder > (project.getBuild().getResources()) for configuration files. > > Is possible too specify some relative path, such as > .../.../anotherProject/src/main/resources/config.xml > But this has a lot of problems,.. > > > VELO > > On Mon, Apr 14, 2008 at 12:09 PM, Brian E. Fox <[EMAIL PROTECTED]> > wrote: > > > > I think there could be some value to making resource sharing a little > > easier out of the box. Naturally it won't fit all instances but those > > other instances can already be solved with assembly and or > > remote-resources > > > > We currently package up the site descriptor for a parent and that gets > > inherited by the children. I think we could leverage the > > remote-resources and do something similar. If you put files in the > > src/main/resources of a pom, we could automatically pick those up and > > deploy them as a resource bundle. Then in the children we could augment > > the resources model to specify to inherit the resources from the parents > > and the plugin could be smart enough to find them on the disk or from > > the repo. > > > > -Original Message- > > From: Benjamin Bentmann [mailto:[EMAIL PROTECTED] > > Sent: Sunday, April 13, 2008 6:06 AM > > To: Maven Developers List > > Subject: Re: Inheriting resources > > > > Sebastien ARBOGAST wrote: > > > I would like to find a natural solution to share confirguration > > > files between two modules. [...] > > > 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? > > > > I'm used to think of projects as independent build units. More > > precisely, I > > expect the following to work: > > - checkout an arbitrary project/module, i.e. not necessarily a whole > > trunk > > - run any build command on this checkout, it should succeed > > > > Now, if I checked out one of your sub-modules how should it inherit its > > resources from the parent which is not on my local disk? Maven can > > retrieve > > the POM and the site descriptor from the remote repo but anything else > > (like > > resources) from the parent project is not shared via the repo. > > > > For the above reason, you would need to package the resources up into a > > JAR > > that can be deployed to the repos. Maybe your resources need filtering > > before their packaging and now you're quite there what is known as a > > "jar" > > packaging. That is just as Brian suggested, a separate module. And I > > believe > > this is right because sharing POM configuration and sharing resources > > seem > > two different aspects, hence separation of concerns. > > > > Finally note that project inheritance suffers from the same drawback as > > class inheritance in ordinary programming: What if you ever needed your > > resources in projects that do not inherit from a common parent? Shift it > > up > > the parent chain until you reach a common ancestor and po
Re: Inheriting resources
I've been trying to make it work with assembly plugin but configuration is quite heavy. I manage to archive my configuration files in a zip file, but then how do I configure the other modules to unpack the archive (just this one) to the right directory? Far too much hassle. I'm starting to think that duplicating those configuration files is like the "least bad" solution. 2008/4/14, VELO <[EMAIL PROTECTED]>: > > At current stage flex-compiler-plugin look at all resources folder > (project.getBuild().getResources()) for configuration files. > > Is possible too specify some relative path, such as > .../.../anotherProject/src/main/resources/config.xml > But this has a lot of problems,.. > > > VELO > > On Mon, Apr 14, 2008 at 12:09 PM, Brian E. Fox <[EMAIL PROTECTED]> > wrote: > > > > I think there could be some value to making resource sharing a little > > easier out of the box. Naturally it won't fit all instances but those > > other instances can already be solved with assembly and or > > remote-resources > > > > We currently package up the site descriptor for a parent and that gets > > inherited by the children. I think we could leverage the > > remote-resources and do something similar. If you put files in the > > src/main/resources of a pom, we could automatically pick those up and > > deploy them as a resource bundle. Then in the children we could augment > > the resources model to specify to inherit the resources from the parents > > and the plugin could be smart enough to find them on the disk or from > > the repo. > > > > -Original Message- > > From: Benjamin Bentmann [mailto:[EMAIL PROTECTED] > > Sent: Sunday, April 13, 2008 6:06 AM > > To: Maven Developers List > > Subject: Re: Inheriting resources > > > > Sebastien ARBOGAST wrote: > > > I would like to find a natural solution to share confirguration > > > files between two modules. [...] > > > 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? > > > > I'm used to think of projects as independent build units. More > > precisely, I > > expect the following to work: > > - checkout an arbitrary project/module, i.e. not necessarily a whole > > trunk > > - run any build command on this checkout, it should succeed > > > > Now, if I checked out one of your sub-modules how should it inherit its > > resources from the parent which is not on my local disk? Maven can > > retrieve > > the POM and the site descriptor from the remote repo but anything else > > (like > > resources) from the parent project is not shared via the repo. > > > > For the above reason, you would need to package the resources up into a > > JAR > > that can be deployed to the repos. Maybe your resources need filtering > > before their packaging and now you're quite there what is known as a > > "jar" > > packaging. That is just as Brian suggested, a separate module. And I > > believe > > this is right because sharing POM configuration and sharing resources > > seem > > two different aspects, hence separation of concerns. > > > > Finally note that project inheritance suffers from the same drawback as > > class inheritance in ordinary programming: What if you ever needed your > > resources in projects that do not inherit from a common parent? Shift it > > up > > the parent chain until you reach a common ancestor and pollute the > > resources > > for all children below? I would rather take the composition approach and > > > > package your resources into an independent project/JAR that other > > projects > > can put on their class path if needed. > > > > Just my two cents, > > > > > > Benjamin > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > -- Sébastien Arbogast http://sebastien-arbogast.com
Re: Inheriting resources
At current stage flex-compiler-plugin look at all resources folder (project.getBuild().getResources()) for configuration files. Is possible too specify some relative path, such as .../.../anotherProject/src/main/resources/config.xml But this has a lot of problems,.. VELO On Mon, Apr 14, 2008 at 12:09 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote: > I think there could be some value to making resource sharing a little > easier out of the box. Naturally it won't fit all instances but those > other instances can already be solved with assembly and or > remote-resources > > We currently package up the site descriptor for a parent and that gets > inherited by the children. I think we could leverage the > remote-resources and do something similar. If you put files in the > src/main/resources of a pom, we could automatically pick those up and > deploy them as a resource bundle. Then in the children we could augment > the resources model to specify to inherit the resources from the parents > and the plugin could be smart enough to find them on the disk or from > the repo. > > -Original Message- > From: Benjamin Bentmann [mailto:[EMAIL PROTECTED] > Sent: Sunday, April 13, 2008 6:06 AM > To: Maven Developers List > Subject: Re: Inheriting resources > > Sebastien ARBOGAST wrote: > > I would like to find a natural solution to share confirguration > > files between two modules. [...] > > 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? > > I'm used to think of projects as independent build units. More > precisely, I > expect the following to work: > - checkout an arbitrary project/module, i.e. not necessarily a whole > trunk > - run any build command on this checkout, it should succeed > > Now, if I checked out one of your sub-modules how should it inherit its > resources from the parent which is not on my local disk? Maven can > retrieve > the POM and the site descriptor from the remote repo but anything else > (like > resources) from the parent project is not shared via the repo. > > For the above reason, you would need to package the resources up into a > JAR > that can be deployed to the repos. Maybe your resources need filtering > before their packaging and now you're quite there what is known as a > "jar" > packaging. That is just as Brian suggested, a separate module. And I > believe > this is right because sharing POM configuration and sharing resources > seem > two different aspects, hence separation of concerns. > > Finally note that project inheritance suffers from the same drawback as > class inheritance in ordinary programming: What if you ever needed your > resources in projects that do not inherit from a common parent? Shift it > up > the parent chain until you reach a common ancestor and pollute the > resources > for all children below? I would rather take the composition approach and > > package your resources into an independent project/JAR that other > projects > can put on their class path if needed. > > Just my two cents, > > > Benjamin > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
RE: Inheriting resources
I think there could be some value to making resource sharing a little easier out of the box. Naturally it won't fit all instances but those other instances can already be solved with assembly and or remote-resources We currently package up the site descriptor for a parent and that gets inherited by the children. I think we could leverage the remote-resources and do something similar. If you put files in the src/main/resources of a pom, we could automatically pick those up and deploy them as a resource bundle. Then in the children we could augment the resources model to specify to inherit the resources from the parents and the plugin could be smart enough to find them on the disk or from the repo. -Original Message- From: Benjamin Bentmann [mailto:[EMAIL PROTECTED] Sent: Sunday, April 13, 2008 6:06 AM To: Maven Developers List Subject: Re: Inheriting resources Sebastien ARBOGAST wrote: > I would like to find a natural solution to share confirguration > files between two modules. [...] > 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? I'm used to think of projects as independent build units. More precisely, I expect the following to work: - checkout an arbitrary project/module, i.e. not necessarily a whole trunk - run any build command on this checkout, it should succeed Now, if I checked out one of your sub-modules how should it inherit its resources from the parent which is not on my local disk? Maven can retrieve the POM and the site descriptor from the remote repo but anything else (like resources) from the parent project is not shared via the repo. For the above reason, you would need to package the resources up into a JAR that can be deployed to the repos. Maybe your resources need filtering before their packaging and now you're quite there what is known as a "jar" packaging. That is just as Brian suggested, a separate module. And I believe this is right because sharing POM configuration and sharing resources seem two different aspects, hence separation of concerns. Finally note that project inheritance suffers from the same drawback as class inheritance in ordinary programming: What if you ever needed your resources in projects that do not inherit from a common parent? Shift it up the parent chain until you reach a common ancestor and pollute the resources for all children below? I would rather take the composition approach and package your resources into an independent project/JAR that other projects can put on their class path if needed. Just my two cents, Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inheriting resources
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+Blaze
Re: Inheriting resources
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. B
Re: Inheriting resources
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]
Re: Inheriting resources
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.
Re: Inheriting resources
Sebastien ARBOGAST wrote: I would like to find a natural solution to share confirguration files between two modules. [...] 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? I'm used to think of projects as independent build units. More precisely, I expect the following to work: - checkout an arbitrary project/module, i.e. not necessarily a whole trunk - run any build command on this checkout, it should succeed Now, if I checked out one of your sub-modules how should it inherit its resources from the parent which is not on my local disk? Maven can retrieve the POM and the site descriptor from the remote repo but anything else (like resources) from the parent project is not shared via the repo. For the above reason, you would need to package the resources up into a JAR that can be deployed to the repos. Maybe your resources need filtering before their packaging and now you're quite there what is known as a "jar" packaging. That is just as Brian suggested, a separate module. And I believe this is right because sharing POM configuration and sharing resources seem two different aspects, hence separation of concerns. Finally note that project inheritance suffers from the same drawback as class inheritance in ordinary programming: What if you ever needed your resources in projects that do not inherit from a common parent? Shift it up the parent chain until you reach a common ancestor and pollute the resources for all children below? I would rather take the composition approach and package your resources into an independent project/JAR that other projects can put on their class path if needed. Just my two cents, Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Inheriting resources
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