Borked dependency graph?

[Kevin Menard <km...@servprise.com>]

I'm working on some Cayenne plugins for maven that should hopefully make 
working with the two much nicer.  I'm been having a hell of a time with 
classpath-related issues.  I just cracked open the parent POM and see 
some dependencies are listed as being provided that we directly rely 
on.  Could someone please cast some light on this issue?  My guess is 
that they're listed as provided because some other dependency has a 
transitive dependency on the same libs.  If this is the case, I propose 
we change this so that the dependency graph reflects what Cayenne 
actually depends on.  The maven book describes ways for handling this.  
Incidentally, changing those libs from "provided" to "compile" (default) 
fixes my classpath woes.  So, there may be a maven-related bug here, 
too, since transitive dependencies are supposed to be followed.

Any insight would be appreciated, since I missed most of the maven 
migration.

Thanks,
Kevin

Re: Borked dependency graph?

[Kevin Menard <km...@servprise.com>]

Incidentally, the modeler is what I'm having difficulties with.  I was 
starting with what I believed would be something simple, and perhaps a 
bit useful.  Basically you'd run "mvn cayenne:modeler" and it would open 
up the modeler.  But, like I said, I'm having some classpath issues, 
particularly with commons-pool and commons-dbcp.  It sounds like what 
you're suggesting -- changing the scope at the assembly level -- would 
work.  Now, my maven naivity is showing, but don't the assemblies 
declare their dependencies anyway?  The dependencies in question are 
declared in a <dependencyManagement> section in the parent POM, which is 
more of an organizational thing rather than specifying that all of those 
dependencies should be packaged into the final assembly, unless I'm 
mistaken.

Well, for now I'll just move to the cgen and cdbgen equivalents.  
Hopefully I don't run into the same issues.

-- 
Kevin

Andrus Adamchik wrote:
> All of those artifacts are our "optional dependencies", i.e. they are 
> required on compilation, but not required in runtime for 99% of users. 
> IIRC they were marked as "provided" to prevent Cayenne users to suck 
> up the entire ibiblio repo on their local drive :-)
>
> But this is not ideal of course. I guess we should remove "provided" 
> from the top level and add them at the assembly level. In other words 
> we need new assembly artifacts that build "cayenne-nodeps.jar" and 
> "cayenne-client-nodeps.jar" with POMs that exclude optional 
> dependencies. Also we will need to ensure that they are excluded from 
> current modeler assemblies (or the Modeler jar size will jump to 20 MB 
> :-)).
>
> Andrus

Re: Borked dependency graph?

[Andrus Adamchik <an...@objectstyle.org>]

All of those artifacts are our "optional dependencies", i.e. they are  
required on compilation, but not required in runtime for 99% of  
users. IIRC they were marked as "provided" to prevent Cayenne users  
to suck up the entire ibiblio repo on their local drive :-)

But this is not ideal of course. I guess we should remove "provided"  
from the top level and add them at the assembly level. In other words  
we need new assembly artifacts that build "cayenne-nodeps.jar" and  
"cayenne-client-nodeps.jar" with POMs that exclude optional  
dependencies. Also we will need to ensure that they are excluded from  
current modeler assemblies (or the Modeler jar size will jump to 20  
MB :-)).

Andrus


On Oct 1, 2006, at 9:50 AM, Kevin Menard wrote:
> I'm working on some Cayenne plugins for maven that should hopefully  
> make working with the two much nicer.  I'm been having a hell of a  
> time with classpath-related issues.  I just cracked open the parent  
> POM and see some dependencies are listed as being provided that we  
> directly rely on.  Could someone please cast some light on this  
> issue?  My guess is that they're listed as provided because some  
> other dependency has a transitive dependency on the same libs.  If  
> this is the case, I propose we change this so that the dependency  
> graph reflects what Cayenne actually depends on.  The maven book  
> describes ways for handling this.  Incidentally, changing those  
> libs from "provided" to "compile" (default) fixes my classpath  
> woes.  So, there may be a maven-related bug here, too, since  
> transitive dependencies are supposed to be followed.
>
> Any insight would be appreciated, since I missed most of the maven  
> migration.
>
> Thanks,
> Kevin
>