You've not provided, for example, a relativePath to the parent pom -
thus maven defaults to assuming that it is one level up (which it's
not; it's two levels up).
If that's the only problem, I guess we are fine with the current
structure. Installing 1 parent pom locally is a reasonable requirement
IMO.
To be clearer, a number of the sub-modules of the root parent's
modules (e.g., /framework/cayenne-client/pom.xml) have as their
parent /pom.xml rather than /framework/pom.xml... where the parent
of /framework/pom.xml would be /pom.xml.
I assume you had a reason for doing this (which I'd not seen before)
but it wasn't clear to me what that reasoning was.
The reason being hiding our internal structure from the end users who
import Cayenne in their projects. This reduces the number of
intermediate parent modules one would need to download to just 1.
Andrus
On Aug 13, 2008, at 11:16 AM, Lachlan Deck wrote:
On 10/08/2008, at 12:36 AM, Andrus Adamchik wrote:
On Aug 9, 2008, at 10:31 AM, Andrus Adamchik wrote:
group: org.apache
artifact: cayenne
This suggestion is the most damaging, as it would force us to
break out of our namespace.
Or maybe I am wrong here, as everything will still be published
under /org/apache/cayenne in the repo. So a follow up question - is
there any indication that our artifact naming (not following the
folder structure) caused your build troubles?
Some of the modules have no way of referring automatically to non-
installed builds because they can't find the parent in the usual
place (so this affects projects imported into Eclipse... i.e., it
means you must do an install from trunk of all artifacts for
anything to work).
You've not provided, for example, a relativePath to the parent pom -
thus maven defaults to assuming that it is one level up (which it's
not; it's two levels up).
To be clearer, a number of the sub-modules of the root parent's
modules (e.g., /framework/cayenne-client/pom.xml) have as their
parent /pom.xml rather than /framework/pom.xml... where the parent
of /framework/pom.xml would be /pom.xml.
I assume you had a reason for doing this (which I'd not seen before)
but it wasn't clear to me what that reasoning was.
with regards,
--
Lachlan Deck
