Am Donnerstag, den 12.01.2017, 14:22 -0800 schrieb Benson Margulies:
> I agree with them that this is counter-intuitive. The whole point of
> -beta-1 is to introduce new, incompatible, stuff. The whole point of
> that range is to exclude it.
Doesn't 2.0.0-beta1 imply that it's a beta for the
On 23/12/2016 09:48, Christian Schulte wrote:
I'd move those re-useable test classes into theire own module. For the
example mentioned above, you would add commons-lang as a compile
dependency to that module and then you can depend on that module in test
scope the usual way and you'll get the
Hello,
let's assume a simple maven project consisting of two modules:
- myproject-basicstuff
- myproject-application
...in which myproject-application has the myproject-basicstuff as a
dependency.
Now let's say we have an arbitrary class in myproject-basicstuff:
public class Data {
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
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
X to value Y. It does some strange range stuff, etc.
> Sent from my iDevice
>
> > On Dec 4, 2016, at 8:22 AM, Florian Schätz <m...@florian-schaetz.de> wrote:
> >
> > Hello,
> >
> >> For now, you can make that property a constant in the grandparent li
Hello,
For now, you can make that property a constant in the grandparent like
"1.0.0-SNAPSHOT" and use that
property itself in the grandparent like
"${grandparent.version}". Should not override that
property in modules, of course.
But that would require me to always update that property
Is there any other chance to get the grandparent version - preferably
without writing another maven plugin ;-)
If you control the grandparent POM, you can put a property there and set it
to ${project.version} and then it should be inherited in the descendants.
Erm... Not really? That's why I
Hello,
Was it expected to work with Maven 2, before the whole effective pom
calculation was rewritten?
Did you try?
No, don't have Maven 2 here, it was just referenced as a workaround in
https://issues.apache.org/jira/browse/MASSEMBLY-367
and in a comment in...
Hello,
for a project I would like to resolve the "grandparent" version:
${project.parent.parent.version}
Unfortunately, with Maven 3.3.9 this simply doesn't work, the effective
pom shows it as unresolved:
${project.parent.parent.version}
I can reproduce it with any new probject a simple way
A library project to be
shared between multiple applications each having its own release-cycle
should not be part of a multi-module project used to build such an
application and should be an independent project with its own
release-cycle.
While this is of course a good idea, especially when
Hello Oliver (and everyone else),
can you tell us who do you define a "bigger project"?
Well, bigger project in this case would be starting with two web
applications, with some shared code (thus best put into separate modules
that get developed along the main applications). More
12 matches
Mail list logo
