See my replies below. On Apr 12, 2011, at 5:00 PM, Christian Grobmeier wrote: > Hi, > >> All Eclipse files for the modules that people normally care to have in >> Eclipse are checked in to SVN, so just importing the modules should be ok. >> You prolly don't need the docs module in Eclipse. There's no code in there. > > Yes, I already saw there is no code. But mvn eclipse:eclipse should > not fail imho even when there is no code in it. Probably I simply want > to edit the html files with my favourite eclipse plugin.
If we can fix it, I won't argue against it :-) > What I just saw was there is a target folder committed to svn. This is > also very unusual. Why is it there? Guess the api is somehow generated > into the docs target folder and from there put into the doc.jar I don't see the target folder in SVN. There's only src folder here: https://svn.apache.org/repos/asf/cayenne/main/trunk/docs/doc/ > Now the unpublished thing... We are trying to hide some internal modularity > from the end users for simplicity sake. And we are going against Maven > normal practices in doing that. So when building from command line, we > aggregate a bunch of unpublished modules in cayenne-server and cayenne-client > aggregate modules (aggregating their transitive deps as well). And that's > what the end users should include in their POMs. > > > OK. I don't see the real benefit. For me its ok to split the modules. > The enduser still can include cayenne-server and cayenne-client even > when those two jars have dependencies to f. e. cayenne-di.jar. I don't > think a user really cares how many cayenne jars are on his classpath. > Nor do I think he feels its easier to have 5 jars on the classpath or > to have 50 more classes in a single jar. > > Hope I do not open a can of worms, but I would think its easy if > everything follows the standard practices. Now - as I want more of > Cayenne - I have the surprising problem to understand the speciality > of the cayenne build. That was one of mavens biggest pluses. There are reasons and I'll be happy to discuss them. But please start a separate thread on the dev list with the corresponding subject. >> All the "ext" modules are for building CayenneModeler on different platforms >> (Mac, Windows, Generic). Some of them are platform dependent (e.g. depend on >> jars that only exist in OS X; or on an OS-specific windowing system). > > Well, I am on OS X. Windows and Generic build for me, when I include > the dependencies as said. Cayenne team has already separated the > platform dependencies into different profiles - but my problem is more > with f. e. cayenne-di-unpublished. This package seems to be platform > independent. It is only on "provided" scope. I stil think this should > be at compile scope. or did i miss something? > > >> So with the above in mind, what are you planning to do with Cayenne in >> Eclipse? Very likely you just need a smaller subset of modules. > > I work on a Project A and would like to add the eclipse projects as > dependency, not only the jar files. But as I learned now, I am not > sure if this is possible. Let's put it this way - this wasn't the target use case for us. Still it is possible, but you will need only a few modules in Eclipse - cayenne-di-unpublished and cayenne-jdk1.5-unpublished. You can safely ignore the rest. The runtime component is not that big. Tests and various support tools create this whole Maven complexity. > I have succeeded with compiling and dependencies, but still get curious > errors: > > org.apache.cayenne.configuration.server.DataDomainLoadException: > [v.${project.version} ${project.build.date} ${project.build.time}] > Configuration file "CayenneFilter.xml" is not found. How do you bootstrap CayenneRuntime? This error is about a failure to locate your project XML file. Andrus
