FYI, I fixed the ASL licensed JPA spec jar in Geronimo svn. It had
some old signatures and was missing two exception classes. Got the
code checked in -- haven't published any snapshots yet though.
I ran the OpenJPA build and tests with it and everything passed. You
may likely decide to s
> Check out the Assembly plugin and it's predefined
> "jar-with-dependencies" descriptor[1]. I'm pretty sure that
> most people
> using Maven will just have a runtime dependency on the core OpenJPA
> library and be done with it, but it's always nice for Ant users.
Exactly -- mvn users will use th
> > Note that that will not merge anything you need in the META-INF
> > directory. It does do it for plexus components.xml files though, so
> > maybe it's a good time to make that pluggable.
> >
>
> It'll definitely add the files from all the META-INF
> directories into
> the resulting jar. I
On Aug 15, 2006, at 6:38 AM, Patrick Linskey wrote:
Check out the Assembly plugin and it's predefined
"jar-with-dependencies" descriptor[1]. I'm pretty sure that
most people
using Maven will just have a runtime dependency on the core OpenJPA
library and be done with it, but it's always nice for
As to the details of how the ProductDerivation interface would take
over for ConfiguraitonProvider: I was thinking we could move
ConfigurationProvider's load() methods into ProductDerivation, but
change them to return a ConfigurationProvider, which will now
consist of just getProperties(),
This sounds good since I was wondering how these two services fit
together.
Can you shed some more light on how you plan to resolve this?
Well, I haven't thought it through all the way, which is why I
volunteered to play with the code myself rather than subject someone
else to my vague ram
[
http://issues.apache.org/jira/browse/OPENJPA-12?page=comments#action_12428175 ]
Patrick Linskey commented on OPENJPA-12:
I know that we changed this in our JPA TCK test-running environment via the
property setting. I guess the question
So that's basically it for combining ConfigurationProviders and
ProductDerivations into a single service. In a followup email I'll
address how we can give ProductDerivations the ability to extend
the EMF, etc.
Adding the ability to extend EMFs though a ProductDerivation is
actually easy.
> There's one last problem, and that is systems with multiple OpenJPA
> extended products available. If you've got Kodo and
> ExtendedOpenJPAProductX in your classpath, chances are they'll
> attempt to overwrite each other's configuration defaults and so
> forth. That's the case now, and
On Aug 15, 2006, at 6:37 AM, Patrick Linskey wrote:
Note that that will not merge anything you need in the META-INF
directory. It does do it for plexus components.xml files though, so
maybe it's a good time to make that pluggable.
It'll definitely add the files from all the META-INF
director
On Aug 15, 2006, at 11:06 AM, David Blevins wrote:
On Aug 15, 2006, at 6:37 AM, Patrick Linskey wrote:
Note that that will not merge anything you need in the META-INF
directory. It does do it for plexus components.xml files though, so
maybe it's a good time to make that pluggable.
It'll d
On Aug 15, 2006, at 11:40 AM, Craig L Russell wrote:
On Aug 15, 2006, at 11:06 AM, David Blevins wrote:
On Aug 15, 2006, at 6:37 AM, Patrick Linskey wrote:
Note that that will not merge anything you need in the META-INF
directory. It does do it for plexus components.xml files
though, so
> > So would it be easier to write a merge-manifest method or to
> > restrict manifest services with the same name to one of the build
> > modules?
>
> Sorry, I think I'm making things clear as mud :) I get the feeling
> we don't even have the issue Brett was mentioning. Aside from the
David-
are there any jars of our own that contain the same file in the
same place in the jar and those contents are different and need to
be merged together?
The only cases I know of are some of the files in services/. E.g.:
openjpa-jdbc/src/main/resources/META-INF/services/
org.apache.
[
http://issues.apache.org/jira/browse/OPENJPA-13?page=comments#action_12428213 ]
Marc Prud'hommeaux commented on OPENJPA-13:
---
If you change the type of the "id" field from Integer to BigDecimal (or just
Number), does it work? It may b
I think it would be better to pass the TCK without any properties that
change behavior.
Does anyone know if Sun has a guideline regarding the configuration
properties?
On 8/15/06, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote:
[
http://issues.apache.org/jira/browse/OPENJPA-12?page=com
[
http://issues.apache.org/jira/browse/OPENJPA-13?page=comments#action_12428249 ]
Megan commented on OPENJPA-13:
--
I tried to change the type of the "id" field from Integer to BigDecimal (and
Number) but openjpac fails.
enhance:
[openjpac] 80 INF
On Aug 15, 2006, at 12:56 PM, Marc Prud'hommeaux wrote:
David-
are there any jars of our own that contain the same file in the
same place in the jar and those contents are different and need to
be merged together?
The only cases I know of are some of the files in services/. E.g.:
open
[
http://issues.apache.org/jira/browse/OPENJPA-13?page=comments#action_12428250 ]
Megan commented on OPENJPA-13:
--
Changing the type of the "id" field from Integer to "int" worked. Thank you.
@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
@C
Sadly, I believe that a discussion of the properties permitted to
pass the TCK is found in the TCK configuration requirements, which I
believe is confidential and therefore out of bounds for this alias.
I hope to be corrected.
Craig
On Aug 15, 2006, at 2:20 PM, Michael Dick wrote:
I think
David-
But you might consider making
"org.apache.openjpa.conf.ProductDerivation" a directory that holds
files that contain the implementation class names. Then you can
have more than one in a jar.
That would solve the problem, but since there is no generic
classloader-based way of gett
On Aug 15, 2006, at 7:42 AM, Craig L Russell wrote:
On Aug 15, 2006, at 6:38 AM, Patrick Linskey wrote:
Check out the Assembly plugin and it's predefined
"jar-with-dependencies" descriptor[1]. I'm pretty sure that
most people
using Maven will just have a runtime dependency on the core OpenJP
This discussion would be great to capture on the wiki for the time
(not too far away) when we will actually package and ship some code.
Craig
On Aug 15, 2006, at 7:20 PM, David Blevins wrote:
On Aug 15, 2006, at 7:42 AM, Craig L Russell wrote:
On Aug 15, 2006, at 6:38 AM, Patrick Linskey
23 matches
Mail list logo
