To share config files between projects, I'd advice using the maven-remote-resources-plugin.
We use it successfully to centralize versioned configuration (for pmd, etc.) between tens of project. Cheers Le 16 avr. 2013 23:37, "Mirko Friedenhagen" <[email protected]> a écrit : > 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 >> >> >>
