You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Sebastien ARBOGAST <se...@gmail.com> on 2008/04/13 11:31:00 UTC
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
Re: Inheriting resources
Posted by da...@davidkarlsen.com.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Inheriting resources
Posted by VELO <ve...@gmail.com>.
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 <
sebastien.arbogast@gmail.com> 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 <br...@reply.infinity.nu>:
> >
> > You can use dependency:unpack/unpack-dependencies to retrieve them and
> put
> > 'em were you need 'em
> >
> >
> > -----Original Message-----
> > From: Sebastien ARBOGAST [mailto:sebastien.arbogast@gmail.com]
> > Sent: Thursday, April 17, 2008 3:40 PM
> > To: Maven Developers List; velo.br@gmail.com
> > 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 <ve...@gmail.com>:
> > >
> > > 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 <
> brianf@reply.infinity.nu
> > >
> > > 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:benjamin.bentmann@udo.edu]
> > > > 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: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Sébastien Arbogast
> >
> > http://sebastien-arbogast.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> Sébastien Arbogast
>
> http://sebastien-arbogast.com
>
RE: Inheriting resources
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Sure, I will send one tonight.
-----Original Message-----
From: Sebastien ARBOGAST [mailto:sebastien.arbogast@gmail.com]
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 <br...@reply.infinity.nu>:
>
> 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:sebastien.arbogast@gmail.com]
>
> 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 <br...@reply.infinity.nu>:
> >
> > You can use dependency:unpack/unpack-dependencies to retrieve them and
> put
> > 'em were you need 'em
> >
> >
> > -----Original Message-----
> > From: Sebastien ARBOGAST [mailto:sebastien.arbogast@gmail.com]
> > Sent: Thursday, April 17, 2008 3:40 PM
> > To: Maven Developers List; velo.br@gmail.com
> > 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 <ve...@gmail.com>:
> > >
> > > 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 <
> brianf@reply.infinity.nu
> > >
> > > 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:benjamin.bentmann@udo.edu]
> > > > 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: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Sébastien Arbogast
> >
> > http://sebastien-arbogast.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> Sébastien Arbogast
>
> http://sebastien-arbogast.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sébastien Arbogast
http://sebastien-arbogast.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Inheriting resources
Posted by Sebastien ARBOGAST <se...@gmail.com>.
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 <br...@reply.infinity.nu>:
>
> 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:sebastien.arbogast@gmail.com]
>
> 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 <br...@reply.infinity.nu>:
> >
> > 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:sebastien.arbogast@gmail.com]
> >
> > 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 <br...@reply.infinity.nu>:
> > >
> > > You can use dependency:unpack/unpack-dependencies to retrieve them and
> > put
> > > 'em were you need 'em
> > >
> > >
> > > -----Original Message-----
> > > From: Sebastien ARBOGAST [mailto:sebastien.arbogast@gmail.com]
> > > Sent: Thursday, April 17, 2008 3:40 PM
> > > To: Maven Developers List; velo.br@gmail.com
> > > 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 <ve...@gmail.com>:
> > > >
> > > > 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 <
> > brianf@reply.infinity.nu
> > > >
> > > > 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:benjamin.bentmann@udo.edu]
> > > > > 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: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Sébastien Arbogast
> > >
> > > http://sebastien-arbogast.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> >
> > --
> > Sébastien Arbogast
> >
> > http://sebastien-arbogast.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> Sébastien Arbogast
>
> http://sebastien-arbogast.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sébastien Arbogast
http://sebastien-arbogast.com
RE: Inheriting resources
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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:sebastien.arbogast@gmail.com]
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 <br...@reply.infinity.nu>:
>
> 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:sebastien.arbogast@gmail.com]
>
> 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 <br...@reply.infinity.nu>:
> >
> > You can use dependency:unpack/unpack-dependencies to retrieve them and
> put
> > 'em were you need 'em
> >
> >
> > -----Original Message-----
> > From: Sebastien ARBOGAST [mailto:sebastien.arbogast@gmail.com]
> > Sent: Thursday, April 17, 2008 3:40 PM
> > To: Maven Developers List; velo.br@gmail.com
> > 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 <ve...@gmail.com>:
> > >
> > > 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 <
> brianf@reply.infinity.nu
> > >
> > > 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:benjamin.bentmann@udo.edu]
> > > > 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: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Sébastien Arbogast
> >
> > http://sebastien-arbogast.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> Sébastien Arbogast
>
> http://sebastien-arbogast.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sébastien Arbogast
http://sebastien-arbogast.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Inheriting resources
Posted by Sebastien ARBOGAST <se...@gmail.com>.
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 <br...@reply.infinity.nu>:
>
> 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:sebastien.arbogast@gmail.com]
>
> 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 <br...@reply.infinity.nu>:
> >
> > You can use dependency:unpack/unpack-dependencies to retrieve them and
> put
> > 'em were you need 'em
> >
> >
> > -----Original Message-----
> > From: Sebastien ARBOGAST [mailto:sebastien.arbogast@gmail.com]
> > Sent: Thursday, April 17, 2008 3:40 PM
> > To: Maven Developers List; velo.br@gmail.com
> > 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 <ve...@gmail.com>:
> > >
> > > 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 <
> brianf@reply.infinity.nu
> > >
> > > 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:benjamin.bentmann@udo.edu]
> > > > 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: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Sébastien Arbogast
> >
> > http://sebastien-arbogast.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> Sébastien Arbogast
>
> http://sebastien-arbogast.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sébastien Arbogast
http://sebastien-arbogast.com
RE: Inheriting resources
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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:sebastien.arbogast@gmail.com]
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 <br...@reply.infinity.nu>:
>
> You can use dependency:unpack/unpack-dependencies to retrieve them and put
> 'em were you need 'em
>
>
> -----Original Message-----
> From: Sebastien ARBOGAST [mailto:sebastien.arbogast@gmail.com]
> Sent: Thursday, April 17, 2008 3:40 PM
> To: Maven Developers List; velo.br@gmail.com
> 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 <ve...@gmail.com>:
> >
> > 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 <brianf@reply.infinity.nu
> >
> > 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:benjamin.bentmann@udo.edu]
> > > 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: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
>
>
> --
> Sébastien Arbogast
>
> http://sebastien-arbogast.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sébastien Arbogast
http://sebastien-arbogast.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Inheriting resources
Posted by Sebastien ARBOGAST <se...@gmail.com>.
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 <br...@reply.infinity.nu>:
>
> You can use dependency:unpack/unpack-dependencies to retrieve them and put
> 'em were you need 'em
>
>
> -----Original Message-----
> From: Sebastien ARBOGAST [mailto:sebastien.arbogast@gmail.com]
> Sent: Thursday, April 17, 2008 3:40 PM
> To: Maven Developers List; velo.br@gmail.com
> 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 <ve...@gmail.com>:
> >
> > 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 <brianf@reply.infinity.nu
> >
> > 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:benjamin.bentmann@udo.edu]
> > > 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: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
>
>
> --
> Sébastien Arbogast
>
> http://sebastien-arbogast.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sébastien Arbogast
http://sebastien-arbogast.com
RE: Inheriting resources
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
You can use dependency:unpack/unpack-dependencies to retrieve them and put 'em were you need 'em
-----Original Message-----
From: Sebastien ARBOGAST [mailto:sebastien.arbogast@gmail.com]
Sent: Thursday, April 17, 2008 3:40 PM
To: Maven Developers List; velo.br@gmail.com
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 <ve...@gmail.com>:
>
> 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 <br...@reply.infinity.nu>
> 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:benjamin.bentmann@udo.edu]
> > 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
--
Sébastien Arbogast
http://sebastien-arbogast.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Inheriting resources
Posted by Sebastien ARBOGAST <se...@gmail.com>.
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 <ve...@gmail.com>:
>
> 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 <br...@reply.infinity.nu>
> 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:benjamin.bentmann@udo.edu]
> > 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
--
Sébastien Arbogast
http://sebastien-arbogast.com
Re: Inheriting resources
Posted by VELO <ve...@gmail.com>.
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 <br...@reply.infinity.nu>
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:benjamin.bentmann@udo.edu]
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
RE: Inheriting resources
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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:benjamin.bentmann@udo.edu]
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Inheriting resources
Posted by Benjamin Bentmann <be...@udo.edu>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Inheriting resources
Posted by VELO <ve...@gmail.com>.
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 <
sebastien.arbogast@gmail.com> 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 <to...@discursive.com>:
> >
> > 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 <
> > > sebastien.arbogast@gmail.com> 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> Sébastien Arbogast
>
> http://sebastien-arbogast.com
>
Re: Inheriting resources
Posted by Sebastien ARBOGAST <se...@gmail.com>.
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 <to...@discursive.com>:
>
> 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 <
> > sebastien.arbogast@gmail.com> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sébastien Arbogast
http://sebastien-arbogast.com
Re: Inheriting resources
Posted by Tim O'Brien <to...@discursive.com>.
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 <
> sebastien.arbogast@gmail.com> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Inheriting resources
Posted by Sejal Patel <se...@gmail.com>.
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 <
sebastien.arbogast@gmail.com> 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.