Hello Avaz,
putting configurations in a jar is probably the best solution. One hack I
use in multimodule projects is ${user.dir} which often is the reactor root
and works when you start your builds always from the root.
I could not figure out how to correctly have the configuration jar to be a
module easily when it is used in plugins of the aggregator pom, so I have
the configuration jar as a separate project.
Regards Mirko
--
Sent from my mobile
On Apr 16, 2013 6:23 PM, "avaz" <[email protected]> wrote:
> Hi,
>
> Ok, it's clear to me now that set this property is bad idea and it's not
> the
> Maven Way™.
> Hide a 'code smell' in a plugin or somewhere else evict that the proper
> solution for that 'code smell' to be found.
>
> And if I understood correctly by the emails sent and more research that I
> did (see links bellow) the reason why this kind of thing is a bad pratice
> is
> because the Maven Way™ expect that an artifact be self content and
> environment agnostic, so it can be built in any place where maven exist,
> right? In this way, the philosophy is any dependecy of an artifact needs,
> he
> need to know how to resolve, to proper be built.
>
> Base on this, the best solution is to not share files (or things) based on
> (relative|absolute) paths and instead put them in some place that can be
> resolved by the normal maven mechanism to resolve dependecys, and the best
> place for this is to put it in the facto some dependecy that can be found
> in
> the repository and consequently shows up in anywhere based on the maven
> functionality.
>
> So if I put my "shared" files as a resource of some other artifact and just
> declare that artifact as dependency in the project that I need everything
> will work and my configuration will be more close to the Maven Way™, it's
> correct Stephen C?
>
> And Karl H., you comment that "...and all of those things can be solved in
> better ways than suggested on SO...", can you point some insights,
> documentation, etc about these 'better ways'?
>
> To make a point clear here, I'm not looking for a big discussion of some
> kind of flame war, I just started to look for a solution for my problem
> some
> days ago and, because the way I was thinking about the solution I found
> other people thinking in the same way and suggesting some solutions,
> following this suggested solutions was the reason for propose to create
> dynamically that property (rootParentDir).
>
> More information:
>
> http://maven.40175.n5.nabble.com/Relative-path-to-parent-directory-at-multi-module-maven-project-td4611798.html
> <
> http://maven.40175.n5.nabble.com/Relative-path-to-parent-directory-at-multi-module-maven-project-td4611798.html
> >
>
>
> http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-way.html
> <
> http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-way.html
> >
>
> Thanks.
>
>
>
> -----
> Anderson Vaz
> --
> View this message in context:
> http://mojo.10943.n7.nabble.com/Build-Helper-Maven-Plugin-Build-MetaData-Maven-Plugin-tp39569p39697.html
> Sent from the Developer mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
