Thanks for your input!
Baptiste MATHUS wrote:
> Didn't dig on that very subject, but IIRC, kind of. Parent
> pom could sometime be downloaded although it *was* part of
> the reactor.
> Being more explicit and less permissive is one of the
> features of m3 (as is the build reproducibility for ma
On 28 May 2013 20:22, Baptiste MATHUS wrote:
> 2013/5/28 Mike Wilson
>
> > > Is this what you are seeing?
> >
> > Sort of. But it seems you have assigned relativePath to a non-
> > empty value, something I think is incorrect in this kind of
> > setup.
> > I believe my setup was described in enou
2013/5/28 Mike Wilson
> > Is this what you are seeing?
>
> Sort of. But it seems you have assigned relativePath to a non-
> empty value, something I think is incorrect in this kind of
> setup.
> I believe my setup was described in enough detail in my
> previous post. I used no relativePath elemen
> Is this what you are seeing?
Sort of. But it seems you have assigned relativePath to a non-
empty value, something I think is incorrect in this kind of
setup.
I believe my setup was described in enough detail in my
previous post. I used no relativePath elements.
> The non-resolvable parent POM
OK, I think I have managed to duplicate the behavior. Is this what you are
seeing?
> [ERROR]
> [ERROR] The project com.packtpub.maven:obfuscate:1.0
> (/Users/russgold/projects/maven-course/sample4/obfuscator/pom.xml) has 1 error
> [ERROR] Non-resolvable parent POM: Could not find artifa
I'm having trouble understanding your use case still, I think - and you are
disregarding the general pattern that child poms are found nested under their
parent; however, from your description, I don't see why this wouldn't work. Can
you make a small sample project that displays the problematic
There are many variations, but here is a simplification of our
own scenario:
1) Consider a number of standalone modules with their own
release cycles in their own VCS repos:
parent/ [vcs0]
pom.xml (1.0.0)
module1/ [vcs1]
pom.xml (1.1.0, parent=parent-1.0.0)
module2/ [vcs2]
...
2)
Only the developers could say for sure, but I would guess that it was done as
part of code cleanup - that it's not so much that they wanted to remove the
feature as it was that cleaning up the code might have made it hard to support
the feature - and there was no particular reason to keep it. Bu
I'm trying to make the point that Maven 2 had the expected
behaviour, and Maven 3 changed that into something less
good. As far as I can read the motivation, it seems to have
been done for the wrong reason.
But it's quite likely I'm missing something, and that a
better motivation may be found o
I'd think this would be better suited for the maven developers list…
But it seems to me that in the case where modules are not supposed to know
where their parents are located, the working assumption is that the parent is
already in the repo and built separately.
That is, there are two cases:
[Note: this entire post deals with project layouts where it is
undesired for modules to know in what filesystem directory their
parent module resides. This rules out relying on Maven parent
found in parent directory or through the relativePath element.]
Maven 3 will throw a "Non-resolvable paren
11 matches
Mail list logo
