Hi,
Any thoughts on my message below?
Thanks.
-
Anderson Vaz
--
View this message in context:
http://mojo.10943.n7.nabble.com/Build-Helper-Maven-Plugin-Build-MetaData-Maven-Plugin-tp39569p39768.html
Sent from the Developer mailing list archive at Nabble.com.
-
Hi all,
@Stephen C. thanks for the answer
@Karl H. after this long thread discussion became clear to me what's a best
solution for this kind of necessity in maven projects. I read your blog post
and the suggestion there is cool but it's not exactly what I was looking
for, but anyway thinks for the
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" a
écrit :
> Hello Avaz,
>
> putting configurations
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
mo
Hi,
>
http://stackoverflow.com/questions/1012402/maven2-property-ethat-indicates-the-parent-directory
This looks like the usual problem building for several environments
which is as you already mentioned not a good idea. The best having
packages which is not dependent on the environment but
On 16 April 2013 17:23, avaz 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 t
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
On 15 April 2013 20:42, Karl Heinz Marbaise wrote:
> A case in point of the improving (though not related to the idea of being
>> able to get a property exposing the root (never mind the which root:
>> reactor/inheritence/**inheritence within reactor) but more related to
>> re-engineering to make
Hi,
based on the requirement which has been made to introduce a new property
for the root of the reactor I 100% agree with Stephens argumentation.
I have taken a look into those question on SO and all of those things
can be solved in better ways than suggested on SO, cause many people
didn't
CC'ing users@maven because I think my point applies to the entire Maven
community:
Well my view is that such practice is bad practice, there are good ways to
do things and bad ways to do things. Hard-coding references between
projects using the file system is bad practice. For one thing it fails t
Hi,
As suggestion, this plugin could have a goal that set's the 'root parent
dir', I see this pretty useful for sharing plugin configuration based in
properties files located in the main parent in a multi module projets.
There is a lot of anxiety of it around web as can be seen:
http://stackoverf
11 matches
Mail list logo
