Am 12/05/16 um 21:51 schrieb Florian Schätz:
> shared-core pom.xml (pom)
> - shared-core module1 pom.xml (jar)
> - shared-core module2 pom.xml (jar)
> - application1 parent pom.xml (pom)
> - application 1 module 1 pom.xml (jar)
> - application 1 module 2 pom.xml (jar)
> - applicatio
Am 12/05/16 um 21:51 schrieb Florian Schätz:
> Hello,
>
> On 05/12/2016 21:37, Christian Schulte wrote:
>
>> Only way to get at that would be to declare a property in that
>> grandparent's POM. The parent/child hierarchies really are used in the
>> opposite way. You inherit versions from parents,
Hello,
On 05/12/2016 21:37, Christian Schulte wrote:
Only way to get at that would be to declare a property in that
grandparent's POM. The parent/child hierarchies really are used in the
opposite way. You inherit versions from parents, for example (top-down,
so to say). What use-case is it requ
Am 12/05/16 um 20:33 schrieb Florian Schätz:
> ${project.parent.version} directly instead? But
> unfortunately, I don't need the parent version, but the grand parent
> version and I don't see a way to get it this way...
Only way to get at that would be to declare a property in that
grandparent's
Why would there be plugin duplications? Are you thinking there would
be plugin definitions in the aggregator pom? The point of the
aggregator pom is that it defines the GAV of the artifact and has the
modules list and NOTHING else.
On Mon, Dec 5, 2016 at 11:27 AM, Mirko Friedenhagen
wrote:
> He
On 05/12/2016 15:09, Robert Patrick wrote:
> If you don’t want to compute the value dynamically, The simplest way
> to set a property is using -Dgrandparent.version=1.2.3 on the
> command-line (or in the project's .mvn/maven.config file).
Not something I want to do, since I want to have all th
Hello,
I use the combined aggregator/parent pom as well. While multiple poms may
be cleaner because of separation of concerns, you might easily end in
duplications for e.g. plugin definitions, which is a shame as well.
Regards
Mirko
--
Sent from my mobile
Am 05.12.2016 10:56 schrieb "Sander Ver
Am 05.12.2016 um 15:09 schrieb Robert Patrick:
> Right, it looks at versions to try to find the latest version number.
>
> Another way that you might solve the problem is simply by chaining
> properties. In any one of the parent hierarchy POMs, set
> ... and then in the module POM,
> just sa
Right, it looks at versions to try to find the latest version number.
If you don’t want to compute the value dynamically, The simplest way to set a
property is using -Dgrandparent.version=1.2.3 on the command-line (or in the
project's .mvn/maven.config file). Another way that you might solve
Am Sonntag, den 04.12.2016, 14:56 -0600 schrieb Robert Patrick:
> versions:update-property seems like a good choice.
Unfortunately, the important word is "seems". versions:update-property
does some complicated stuff, I have not yet found a way to simply use it
to set property X to value Y. It doe
Simple and easy may be in the eye of the beholder. I get a lot of your points
(except for the cycles breaking your build, I'm not recognizing that), but my
environment is just dramatically different, and the things that you are
describing as necessary for your environment, would be unneeded comp
Benson,
Thanks for the quick reply and the pointers. I will do the github and the
sonatype access as you stated. Perhaps even OASIS can overtake the latter-
Kind regards,
Svante
PS: Regarding the none modification problem of Apache it is both, see
https://issues.apache.org/jira/browse/ODFTOOLKIT
12 matches
Mail list logo
