You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Christian Grobmeier <gr...@gmail.com> on 2011/04/12 15:12:42 UTC
Build from trunk
Hello guys,
I am back :-) and would like to include the trunk version of Cayenne
in my project. No worries, I will use a stable version when it goes to
production. But I hope to learn more about Cayenne itself when I use
the direct source. Probably I can do a few patches.
However, i have checked out the source and tried "mvn
eclipse:eclipse". It failed at the project:
"Cayenne License and Notice Bundle ."
The i runned mvn install and redid mvn eclipse:eclipse
This time it worked well, except this:
"[INFO] Cayenne Tutorials ................................. SUCCESS [0.005s]
[INFO] Cayenne Documentation ............................. FAILURE [12.603s]
[INFO] Cayenne Documenation Parent ....................... SKIPPED"
The errormessage is:
"[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-eclipse-plugin:2.8:eclipse
(default-cli) on project cayenne-doc: Request to merge when
'filtering' is not identical. Original=resource src/main/resources:
output=target/classes, include=[], exclude=[doc/index.html|**/*.java],
test=false, filtering=false, merging with=resource src/main/resources:
output=target/classes, include=[doc/index.html], exclude=[**/*.java],
test=false, filtering=true -> [Help 1]"
In my understanding mvn eclipse should work without mvn install. And
of course mvn eclipse should run through documentation projects too.
Right?
Then I imported everything to Eclipse. At least everything except the
documentation project.
There are a few compilation failures b/c of dependencies.
For example:
cayenne-modeler-mac-ext seems to depend on cayenne-di-unpublished.
I was wondering about that project. Why is it named "unpublished"? Is
it some kind of experimental trunk?
And why is it in scope "provided"? If its not there, there is a
compilation failure- for me this calls for a compile time scope. Maybe
you can explain briefly. I would like to avoid to manually set the
eclipse classpath.
Cheers
Christian
Re: Build from trunk
Posted by Andrus Adamchik <an...@objectstyle.org>.
Ah sorry forgot the list address...
On Apr 12, 2011, at 5:42 PM, Andrus Adamchik wrote:
> This makes sense. It appears that cayenne.xml was created by CayenneModeler v3.0. Trunk is v3.1. I suggest to download CayenneModeler v3.1M2 (the official milestone release) from http://cayenne.apache.org/download.html and perform all the mapping tasks with it. A bit on the differences between stable 3.0 and dev 3.1: http://cayenne.apache.org/doc/guide-to-31-features.html
>
> Andrus
>
>
> On Apr 12, 2011, at 5:36 PM, Christian Grobmeier wrote:
>
>>
>> For some reason my config file is named cayenne.xml which works fine
>> with the prepared package. But when I use the trunk version, it needs
>> this file renamed to CayenneFilter.xml. I was forced to remove the
>> <domains> tag and just put <domain> in it.
>>
>> When I did the renaming, i get another exception. It seems to me
>> Cayenne finds my map, but for some reason this ex is thrown:
>>
>> org.apache.cayenne.configuration.server.DataDomainLoadException:
>> [v.${project.version} ${project.build.date} ${project.build.time}]
>> Error loading DataChannel: '[v.${project.version}
>> ${project.build.date} ${project.build.time}] Invalid class
>> org.apache.cayenne.conf.DriverDataSourceFactory of type
>> org.apache.cayenne.configuration.server.DataSourceFactory'
>> at org.apache.cayenne.configuration.server.DataDomainProvider.get(DataDomainProvider.java:100)
>> at org.apache.cayenne.configuration.server.DataDomainProvider.get(DataDomainProvider.java:1)
>> at org.apache.cayenne.di.spi.CustomProvidersProvider.get(CustomProvidersProvider.java:38)
>> at org.apache.cayenne.di.spi.FieldInjectingProvider.get(FieldInjectingProvider.java:42)
>> at org.apache.cayenne.di.spi.DefaultScopeProvider.get(DefaultScopeProvider.java:49)
>> at org.apache.cayenne.di.spi.DefaultInjector.getInstance(DefaultInjector.java:107)
>> at org.apache.cayenne.di.spi.FieldInjectingProvider.injectMember(FieldInjectingProvider.java:93)
>> at org.apache.cayenne.di.spi.FieldInjectingProvider.injectMembers(FieldInjectingProvider.java:58)
>> at org.apache.cayenne.di.spi.FieldInjectingProvider.get(FieldInjectingProvider.java:43)
>> at org.apache.cayenne.di.spi.DefaultScopeProvider.get(DefaultScopeProvider.java:49)
>> at org.apache.cayenne.di.spi.DefaultInjector.getInstance(DefaultInjector.java:103)
>> at org.apache.cayenne.configuration.web.SessionContextRequestHandler.requestStart(SessionContextRequestHandler.java:71)
>> at org.apache.cayenne.configuration.web.CayenneFilter.doFilter(CayenneFilter.java:95)
>
Re: Build from trunk
Posted by Christian Grobmeier <gr...@gmail.com>.
>> 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 :-)
I will give it a try later ;-) basically I guess its about the
exclusion of the index.html file.
> 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/
Probably I am an idiot sometimes, please forget it. Sorry
> 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.
Will do
>>> 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.
Yes this actually works. I have these two + c-server and c-client in
my classpath.
Doing it that way helps me going into Cayenne easier.
>> 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.
For some reason my config file is named cayenne.xml which works fine
with the prepared package. But when I use the trunk version, it needs
this file renamed to CayenneFilter.xml. I was forced to remove the
<domains> tag and just put <domain> in it.
When I did the renaming, i get another exception. It seems to me
Cayenne finds my map, but for some reason this ex is thrown:
org.apache.cayenne.configuration.server.DataDomainLoadException:
[v.${project.version} ${project.build.date} ${project.build.time}]
Error loading DataChannel: '[v.${project.version}
${project.build.date} ${project.build.time}] Invalid class
org.apache.cayenne.conf.DriverDataSourceFactory of type
org.apache.cayenne.configuration.server.DataSourceFactory'
at org.apache.cayenne.configuration.server.DataDomainProvider.get(DataDomainProvider.java:100)
at org.apache.cayenne.configuration.server.DataDomainProvider.get(DataDomainProvider.java:1)
at org.apache.cayenne.di.spi.CustomProvidersProvider.get(CustomProvidersProvider.java:38)
at org.apache.cayenne.di.spi.FieldInjectingProvider.get(FieldInjectingProvider.java:42)
at org.apache.cayenne.di.spi.DefaultScopeProvider.get(DefaultScopeProvider.java:49)
at org.apache.cayenne.di.spi.DefaultInjector.getInstance(DefaultInjector.java:107)
at org.apache.cayenne.di.spi.FieldInjectingProvider.injectMember(FieldInjectingProvider.java:93)
at org.apache.cayenne.di.spi.FieldInjectingProvider.injectMembers(FieldInjectingProvider.java:58)
at org.apache.cayenne.di.spi.FieldInjectingProvider.get(FieldInjectingProvider.java:43)
at org.apache.cayenne.di.spi.DefaultScopeProvider.get(DefaultScopeProvider.java:49)
at org.apache.cayenne.di.spi.DefaultInjector.getInstance(DefaultInjector.java:103)
at org.apache.cayenne.configuration.web.SessionContextRequestHandler.requestStart(SessionContextRequestHandler.java:71)
at org.apache.cayenne.configuration.web.CayenneFilter.doFilter(CayenneFilter.java:95)
Any ideas?
Thanks
Christian
Re: Build from trunk
Posted by Andrus Adamchik <an...@objectstyle.org>.
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
Re: Build from trunk
Posted by Christian Grobmeier <gr...@gmail.com>.
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.
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
> 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.
> 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. 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.
With the cayenne-*.jar dependencies I have not had the need for
CayenneFilter.xml.
Cheers + Thanks for your response. Always interesting
Christian
Re: Build from trunk
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hi Christian,
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.
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.
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).
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.
Andrus
On Apr 12, 2011, at 4:12 PM, Christian Grobmeier wrote:
> Hello guys,
>
> I am back :-) and would like to include the trunk version of Cayenne
> in my project. No worries, I will use a stable version when it goes to
> production. But I hope to learn more about Cayenne itself when I use
> the direct source. Probably I can do a few patches.
>
> However, i have checked out the source and tried "mvn
> eclipse:eclipse". It failed at the project:
> "Cayenne License and Notice Bundle ."
>
> The i runned mvn install and redid mvn eclipse:eclipse
>
> This time it worked well, except this:
> "[INFO] Cayenne Tutorials ................................. SUCCESS [0.005s]
> [INFO] Cayenne Documentation ............................. FAILURE [12.603s]
> [INFO] Cayenne Documenation Parent ....................... SKIPPED"
>
> The errormessage is:
> "[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-eclipse-plugin:2.8:eclipse
> (default-cli) on project cayenne-doc: Request to merge when
> 'filtering' is not identical. Original=resource src/main/resources:
> output=target/classes, include=[], exclude=[doc/index.html|**/*.java],
> test=false, filtering=false, merging with=resource src/main/resources:
> output=target/classes, include=[doc/index.html], exclude=[**/*.java],
> test=false, filtering=true -> [Help 1]"
>
> In my understanding mvn eclipse should work without mvn install. And
> of course mvn eclipse should run through documentation projects too.
> Right?
>
>
> Then I imported everything to Eclipse. At least everything except the
> documentation project.
>
> There are a few compilation failures b/c of dependencies.
>
> For example:
> cayenne-modeler-mac-ext seems to depend on cayenne-di-unpublished.
>
> I was wondering about that project. Why is it named "unpublished"? Is
> it some kind of experimental trunk?
> And why is it in scope "provided"? If its not there, there is a
> compilation failure- for me this calls for a compile time scope. Maybe
> you can explain briefly. I would like to avoid to manually set the
> eclipse classpath.
>
> Cheers
> Christian
>