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: > > > > > > 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 > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Sébastien Arbogast > > > > http://sebastien-arbogast.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Sébastien Arbogast > > http://sebastien-arbogast.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Sébastien Arbogast http://sebastien-arbogast.com
