Eddie: Yeah, I figured it was something like that based on inspection of the repo structure, but what confused me was how parenting relationships fit into this (it's also probably time for me to blow away big chunks of my local repo as it's accumulated a lot of stale cruft due to changes in the build :).
So if you're parented to something with a groupId, it looks like you inherit that groupId but show up as a peer of your parent in the repo.. presumably defining your own groupId means you override what you get from your parent? Jeremy: Makes sense re: disconnecting the parent.. have we got the spec jars published in a repo somewhere so folks can actually build only in java/sca? Or at minimum do they still need to do a build in specs or at the root once anyway? On 7/21/06, Eddie O'Neil <[EMAIL PROTECTED]> wrote:
Ken-- Maven basically uses the groupId as a way to hierarchically name artifacts in a Maven repository. So, if something has a groupId of "tuscany", it would show up in a Maven2 repository as: /tuscany/<artifactId> If the groupId is "org.apache.tuscany", it shows up as: /org/apache/tuscany/<artifactId> Personally, I'm a fan of containing artifacts from a project under nested directories like this as it makes the grouping of related artifacts more obvious. Eddie On 7/21/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > On Jul 21, 2006, at 2:06 PM, Ken Tam wrote: > > > So right now sca doesn't define a groupId and is parented to > > tuscany-project w/ groupId o.a.t.. > > That is so last night ... ;-) > > In r424080 I disinherited the project from its parent (like the other > sdo and das poms) so that people could build sca without needed to > build from the root first (or doing mvn -N at the root anyway) > > > would this mean sca would continue > > to be parented to tuscany-project, but define a new groupId? What > > difference would this make? (I don't really get how maven treats this > > hierarchy to understand what the pros/cons are here) > > There is no significance to the heirarchy, it is just way of > partitioning it up. This would mean that sdo, das and sca would all > be peers under o.a.t rather than giving sca some perceived precedence > in the root. > > We already have sub-hierarchies for containers, databinding, > samples, ... > > -- > Jeremy > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
