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? > > > > > > > > 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 >
