On 16 April 2013 17:23, 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?
>
Yep, that is what would be the best way. Then (once you understand how
maven works) you can completely control your build and you no longer are at
the mercy of "magic"
>
> 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'?
>
>
I will let Karl take up that... my point here is that people often fall
back to the file system as a solution to many types of problem. I don't
think there is one magic solution to many different problems... I think
each problem needs to be addressed one step at a time, hence using
${basedir}/../.. as a *temporary* work around while you try to figure out
the right way to do it is fine... after all you need to Get Things Done™
and each use case may well have a different solution (all in the same
flavour, using the reactor, but the how may well differ)
> 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
>
>
>
