cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Menard <>
Subject Re: Borked dependency graph?
Date Sun, 01 Oct 2006 22:25:54 GMT
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 

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


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

View raw message