Re: Update version to SNAPSHOT
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 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 Ant users. Exactly -- mvn users will use the dependencies, but people who want to download and use the distribution directly may not want a billion little jars. Yes, my experience says it's ok to have 10 dependencies on e.g. commons-logger, antlr, etc. but having 10 dependencies on openjpa- kernel4, openjpa-kernel5, openjpa-api, openjpa-blah is annoying. So if possible, I'd also like to have a jar with all the stuff in it. That'd be nice. Some jar that contains all the openjpa-*.jar files is perfect for my needs. The good news is that the maven-assembly- plugin allows you to define several assembly xml files and build multiple archives containing whatever you like. So if people want, we could have: openjpa-0.9.0-full.jar // contains all openjpa code, openjpa- *.jars merged openjpa-0.9.0-nodep.jar // contains all openjpa code and all third party dependency jars There's a naming convention for this kind of thing, hope I've got it right. -David Craig -Patrick ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Update version to SNAPSHOT
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 OpenJPA library and be done with it, but it's always nice for Ant users. Exactly -- mvn users will use the dependencies, but people who want to download and use the distribution directly may not want a billion little jars. Yes, my experience says it's ok to have 10 dependencies on e.g. commons-logger, antlr, etc. but having 10 dependencies on openjpa- kernel4, openjpa-kernel5, openjpa-api, openjpa-blah is annoying. So if possible, I'd also like to have a jar with all the stuff in it. That'd be nice. Some jar that contains all the openjpa-*.jar files is perfect for my needs. The good news is that the maven-assembly- plugin allows you to define several assembly xml files and build multiple archives containing whatever you like. So if people want, we could have: openjpa-0.9.0-full.jar // contains all openjpa code, openjpa-*.jars merged openjpa-0.9.0-nodep.jar // contains all openjpa code and all third party dependency jars There's a naming convention for this kind of thing, hope I've got it right. -David Craig -Patrick _ __ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: Update version to SNAPSHOT
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 getting a list of resources beneath a
certain directly, I would be uncomfortable with that approach, since
it makes a lot of packaging assumption (it looks like it only works
if the resources are stored in a top-level jar or on the file
system). What if the resources are embedded in multiple levels of
jars (like in a WAR or RAR)? Or what if an exotic custom classloader
(common in EJB containers) is being used to load the classes that
doesn't report a protocol in a way that ResourceFinder understands,
or if it is using a network ClassLoader?
Also, it will be nice to remain compatible with the upcoming JDK 1.6
java.util.ServiceLoader utility.
It's probably safer just to manually append he services files, even
though it requires writing something to manage the merging of the jars.
On Aug 15, 2006, at 3:14 PM, David Blevins wrote:
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.:
openjpa-jdbc/src/main/resources/META-INF/services/
org.apache.openjpa.conf.ProductDerivation
openjpa-persistence-jdbc/src/main/resources/META-INF/services/
org.apache.openjpa.conf.ProductDerivation
openjpa-persistence/src/main/resources/META-INF/services/
org.apache.openjpa.conf.ProductDerivation
It's probably not rocket science to fix these (we would would just
need to figure out a way to append them to each other), but it
would prevent OpenJPA from working if we were to just merge the
jars and overwrite same-named files.
I've had this issue too. I wrote a small library (one class) in
xbean to spin the /META-INF/services/ concept any way you like
pretty much.
This would cover the way you do things now:
import org.apache.xbean.finder.ResourceFinder;
ResourceFinder resourceFinder = new ResourceFinder("META-INF/
services/");
List classes = resourceFinder.findAllImplementations
(org.apache.openjpa.conf.ProductDerivation.class);
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.
Here's an example directory:
http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/
src/test/resources/META-INF/java.net.URLStreamHandler/
Here's how you'd get your implementations:
import org.apache.xbean.finder.ResourceFinder;
ResourceFinder resourceFinder = new ResourceFinder("META-INF/");
Map streamHandersMap =
resourceFinder.mapAllImplementations(java.net.URLStreamHandler.class);
You could just grab all the values from the map and be done with
it. But the keys will the file name under "META-INF/
java.net.URLStreamHandler/", which can be useful for all sorts of
things.
Here is the full test case: http://svn.apache.org/repos/asf/
geronimo/xbean/trunk/xbean-finder/src/test/java/org/apache/xbean/
finder/ResourceFinderTest.java
-David
On Aug 15, 2006, at 12:46 PM, David Blevins wrote:
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
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 guess you are talking specifically
about some
pluggable strategy to merge two files of the same name such
as two
META-INF/persistence.xml files or two META-INF/ejb-jar.xml
files?
Actually, I was thinking about META-INF/MANIFEST.MF and
META-INF/services/*. But yes, merging of resources.
Everything in META-INF/services/* will be copied into the new
jar and you can redefine MANIFEST entries for the new jar using
the same syntax as for the maven-jar-plugin. But it won't
intelligently concatenate the contents of individual matching
files from the source jars as I assume Brett was referring to
with the plexus components.xml.
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 MANIFEST.MF file itself, are there any jars of our own
that contain the same file in the same place in the jar and those
contents are different
Re: [jira] Commented: (OPENJPA-12) Default to strictIdentityTypes for JPA
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 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=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 at hand is whether the default should be to be strict or to be lenient for JPA installations. Does anyone have a dissenting opinion? > Default to strictIdentityTypes for JPA > -- > > Key: OPENJPA-12 > URL: http://issues.apache.org/jira/browse/ OPENJPA-12 > Project: OpenJPA > Issue Type: Bug > Components: jpa >Reporter: Michael Dick >Priority: Minor > Attachments: patch.txt > > > The default behavior with OpenJPA is to be very forgiving regarding the Primary Key types passed in when calling EntityManager.find or EntityManager.getReference . > For example if an Entity has an ID of type Long OpenJPA will attempt to convert anything that extend java.lang.Number and Strings (maybe others). > This is a nice feature, but I don't think it should be the default behavior. The JPA spec indicates that an IllegalArgumentException should be thrown if the second argument is not a valid type for the Entity's primary key. There is some room for interpretation as to what constitutes a valid type, conversion for all Numbers makes sense, but String might be pushing it. > Workaround : > Add the following to persistence.xml > value="strictIdentityValues=true" /> > Proposed Solution : > The OpenJPA compatibility plugin provides a mechanism to enforce strict identity checking (defaulting to false). There's no need to change the default in the kernel (other persistence apis like JDO might be more lenient) so I propose changing the default in PersistenceProductDerivation.beforeConfigurationLoad(). > Changing it there should only effect the JPA facade and leave the OpenJPA kernel's default in place for other facades. > The value may be overridden by adding the following property to persistence.xml > value="strictIdentityValues=false" /> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/ software/jira -- -Michael Dick Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
[jira] Commented: (OPENJPA-13) GenerationType.IDENTITY problem with MS SQL Server
[
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)
@Column(name="Id")
private int id;
> GenerationType.IDENTITY problem with MS SQL Server
> --
>
> Key: OPENJPA-13
> URL: http://issues.apache.org/jira/browse/OPENJPA-13
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Environment: Microsoft SQL Server 2000
> Windows XP
> Java SE 1.5
> OpenJPA - source downloaded today (Aug 14, 2006)
>Reporter: Megan
>Priority: Critical
>
> Cannot persist entity with identity column. To reproduce, create a simple
> object with identity column
> @Entity
> @Table(name="JpaType")
> public class JpaType implements Serializable
> {
> @Id
> @GeneratedValue(strategy=GenerationType.IDENTITY)
> @Column(name="Id")
> private Integer id = null;
>
> @Column(name="Name")
> private String name = null;
>
> public Integer getId() { return id; }
> public String getName() { return name; }
> public void setName(String name) { this.name = name; }
> }
> create table JpaType (
> Id int identity(1, 1) not null
> , Name varchar(50) null
> , constraint JpaType_PK primary key (Id)
> )
> JpaType jpa = new JpaType();
> jpa.setName("Test 1");
> em.persist(jpa);
> em.flush();
> It works OK if I remove identity column (and set ID myself).
> Stack trace
> <0|true|0.9.0> org.apache.openjpa.persistence.PersistenceException:
> java.math.BigDecimal
> at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1576)
> at
> org.apache.openjpa.kernel.DelegatingBroker.flush(DelegatingBroker.java:927)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.flush(EntityManagerImpl.java:421)
> at mytest.domain.JpaTest.testJpa(JpaTest.java:30)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
> at
> org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
> at
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
> at
> org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
> at
> org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
> at
> org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:71)
> at
> org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35)
> at
> org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
> at
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
> at
> org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> Caused by: java.lang.ClassCastException: java.math.BigDecimal
> at mytest.domain.model.JpaType.pcReplaceField(JpaType.java)
> at
> org.apache.openjpa.kernel.StateManagerImpl.replaceField(StateManagerImpl.java:2824)
> at
> org.apache.openjpa.kernel.StateManagerImpl.storeObjectField(StateManagerImpl.java:2284)
> at
> org.apache.openjpa.kernel.StateManagerImpl.storeField(StateManagerImpl.java:2380)
> at
> org.apache.openjpa.kernel.StateManagerImpl.storeField(StateManagerImpl.java:723)
> at
> org.apache.openjpa.kernel.StateManagerImpl.store(StateManagerImpl.java:719)
> at
> org.apache.openjpa.jdbc.meta.strats.HandlerFieldStrategy.setAutoAssignedValue(HandlerFieldStrategy.java:361)
> at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:119)
> at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:68)
> at
> org.apac
Re: Update version to SNAPSHOT
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.:
openjpa-jdbc/src/main/resources/META-INF/services/
org.apache.openjpa.conf.ProductDerivation
openjpa-persistence-jdbc/src/main/resources/META-INF/services/
org.apache.openjpa.conf.ProductDerivation
openjpa-persistence/src/main/resources/META-INF/services/
org.apache.openjpa.conf.ProductDerivation
It's probably not rocket science to fix these (we would would just
need to figure out a way to append them to each other), but it
would prevent OpenJPA from working if we were to just merge the
jars and overwrite same-named files.
I've had this issue too. I wrote a small library (one class) in
xbean to spin the /META-INF/services/ concept any way you like pretty
much.
This would cover the way you do things now:
import org.apache.xbean.finder.ResourceFinder;
ResourceFinder resourceFinder = new ResourceFinder("META-INF/
services/");
List classes = resourceFinder.findAllImplementations
(org.apache.openjpa.conf.ProductDerivation.class);
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.
Here's an example directory:
http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/
src/test/resources/META-INF/java.net.URLStreamHandler/
Here's how you'd get your implementations:
import org.apache.xbean.finder.ResourceFinder;
ResourceFinder resourceFinder = new ResourceFinder("META-INF/");
Map streamHandersMap =
resourceFinder.mapAllImplementations(java.net.URLStreamHandler.class);
You could just grab all the values from the map and be done with it.
But the keys will the file name under "META-INF/
java.net.URLStreamHandler/", which can be useful for all sorts of
things.
Here is the full test case: http://svn.apache.org/repos/asf/geronimo/
xbean/trunk/xbean-finder/src/test/java/org/apache/xbean/finder/
ResourceFinderTest.java
-David
On Aug 15, 2006, at 12:46 PM, David Blevins wrote:
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
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 guess you are talking specifically about
some
pluggable strategy to merge two files of the same name such as
two
META-INF/persistence.xml files or two META-INF/ejb-jar.xml files?
Actually, I was thinking about META-INF/MANIFEST.MF and
META-INF/services/*. But yes, merging of resources.
Everything in META-INF/services/* will be copied into the new
jar and you can redefine MANIFEST entries for the new jar using
the same syntax as for the maven-jar-plugin. But it won't
intelligently concatenate the contents of individual matching
files from the source jars as I assume Brett was referring to
with the plexus components.xml.
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 MANIFEST.MF file itself, 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?
It's pretty easy to make a new MANIFEST.MF that better describes
the new "uber" jar.
-David
[jira] Commented: (OPENJPA-13) GenerationType.IDENTITY problem with MS SQL Server
[
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 INFO [main] openjpa.Tool - No targets were given. Running on
all classes listed in org.apache.openjpa.PersistentClasses, or all metadata
files in classpath directories if the property is not specified.
[openjpac] 1261 INFO [main] openjpa.Tool - Enhancer running on type "class
mytest.domain.model.JpaType".
[openjpac] <4|true|0.9.0> org.apache.openjpa.util.MetaDataException: Type
"class mytest.domain.model.JpaType" declares field "id" as a primary key, but
keys of type "java.math.BigDecimal" are not supported.
[openjpac] at
org.apache.openjpa.meta.ClassMetaData.validateAppIdClass(ClassMetaData.java:1676)
[openjpac] at
org.apache.openjpa.meta.ClassMetaData.validateIdentity(ClassMetaData.java:1655)
[openjpac] at
org.apache.openjpa.meta.ClassMetaData.validateMeta(ClassMetaData.java:1572)
[openjpac] at
org.apache.openjpa.meta.ClassMetaData.resolve(ClassMetaData.java:1462)
[openjpac] at
org.apache.openjpa.meta.MetaDataRepository.processBuffer(MetaDataRepository.java:641)
[openjpac] at
org.apache.openjpa.meta.MetaDataRepository.resolveMeta(MetaDataRepository.java:548)
[openjpac] at
org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java:493)
[openjpac] at
org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:294)
[openjpac] at
org.apache.openjpa.enhance.PCEnhancer.(PCEnhancer.java:163)
[openjpac] at
org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:3473)
[openjpac] at
org.apache.openjpa.ant.PCEnhancerTask.executeOn(PCEnhancerTask.java:86)
[openjpac] at
org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:166)
[openjpac] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
[openjpac] at org.apache.tools.ant.Task.perform(Task.java:364)
[openjpac] at org.apache.tools.ant.Target.execute(Target.java:341)
[openjpac] at org.apache.tools.ant.Target.performTasks(Target.java:369)
[openjpac] at org.apache.tools.ant.Project.executeTarget(Project.java:1214)
[openjpac] at
org.apache.tools.ant.Project.executeTargets(Project.java:1062)
[openjpac] at org.apache.tools.ant.Main.runBuild(Main.java:673)
[openjpac] at org.apache.tools.ant.Main.startAnt(Main.java:188)
[openjpac] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:196)
[openjpac] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:55)
BUILD FAILED
C:\appd\renux\mytest.domain\build.xml:31: <4|true|0.9.0>
org.apache.openjpa.util.MetaDataException: Type "class
mytest.domain.model.JpaType" declares field "id" as a primary key, but keys of
type "java.math.BigDecimal" are not supported.
> GenerationType.IDENTITY problem with MS SQL Server
> --
>
> Key: OPENJPA-13
> URL: http://issues.apache.org/jira/browse/OPENJPA-13
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Environment: Microsoft SQL Server 2000
> Windows XP
> Java SE 1.5
> OpenJPA - source downloaded today (Aug 14, 2006)
>Reporter: Megan
>Priority: Critical
>
> Cannot persist entity with identity column. To reproduce, create a simple
> object with identity column
> @Entity
> @Table(name="JpaType")
> public class JpaType implements Serializable
> {
> @Id
> @GeneratedValue(strategy=GenerationType.IDENTITY)
> @Column(name="Id")
> private Integer id = null;
>
> @Column(name="Name")
> private String name = null;
>
> public Integer getId() { return id; }
> public String getName() { return name; }
> public void setName(String name) { this.name = name; }
> }
> create table JpaType (
> Id int identity(1, 1) not null
> , Name varchar(50) null
> , constraint JpaType_PK primary key (Id)
> )
> JpaType jpa = new JpaType();
> jpa.setName("Test 1");
> em.persist(jpa);
> em.flush();
> It works OK if I remove identity column (and set ID myself).
> Stack trace
> <0|true|0.9.0> org.apache.openjpa.persistence.PersistenceException:
> java.math.BigDecimal
> at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1576)
> at
> org.apache.openjpa.kernel.DelegatingBroker.flush(DelegatingBroker.java:927)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.flush(EntityManagerImpl.java:421)
> at mytest.domain.JpaTest.testJpa(JpaTest.java:30)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
Re: [jira] Commented: (OPENJPA-12) Default to strictIdentityTypes for JPA
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=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 at hand is whether the default should be to be strict or to be lenient for JPA installations. Does anyone have a dissenting opinion? > Default to strictIdentityTypes for JPA > -- > > Key: OPENJPA-12 > URL: http://issues.apache.org/jira/browse/OPENJPA-12 > Project: OpenJPA > Issue Type: Bug > Components: jpa >Reporter: Michael Dick >Priority: Minor > Attachments: patch.txt > > > The default behavior with OpenJPA is to be very forgiving regarding the Primary Key types passed in when calling EntityManager.find or EntityManager.getReference . > For example if an Entity has an ID of type Long OpenJPA will attempt to convert anything that extend java.lang.Number and Strings (maybe others). > This is a nice feature, but I don't think it should be the default behavior. The JPA spec indicates that an IllegalArgumentException should be thrown if the second argument is not a valid type for the Entity's primary key. There is some room for interpretation as to what constitutes a valid type, conversion for all Numbers makes sense, but String might be pushing it. > Workaround : > Add the following to persistence.xml > > Proposed Solution : > The OpenJPA compatibility plugin provides a mechanism to enforce strict identity checking (defaulting to false). There's no need to change the default in the kernel (other persistence apis like JDO might be more lenient) so I propose changing the default in PersistenceProductDerivation.beforeConfigurationLoad(). > Changing it there should only effect the JPA facade and leave the OpenJPA kernel's default in place for other facades. > The value may be overridden by adding the following property to persistence.xml > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- -Michael Dick
[jira] Commented: (OPENJPA-13) GenerationType.IDENTITY problem with MS SQL Server
[
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 be that we just aren't coercing the return type
correctly, and setting it to Number might work around the problem.
> GenerationType.IDENTITY problem with MS SQL Server
> --
>
> Key: OPENJPA-13
> URL: http://issues.apache.org/jira/browse/OPENJPA-13
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Environment: Microsoft SQL Server 2000
> Windows XP
> Java SE 1.5
> OpenJPA - source downloaded today (Aug 14, 2006)
>Reporter: Megan
>Priority: Critical
>
> Cannot persist entity with identity column. To reproduce, create a simple
> object with identity column
> @Entity
> @Table(name="JpaType")
> public class JpaType implements Serializable
> {
> @Id
> @GeneratedValue(strategy=GenerationType.IDENTITY)
> @Column(name="Id")
> private Integer id = null;
>
> @Column(name="Name")
> private String name = null;
>
> public Integer getId() { return id; }
> public String getName() { return name; }
> public void setName(String name) { this.name = name; }
> }
> create table JpaType (
> Id int identity(1, 1) not null
> , Name varchar(50) null
> , constraint JpaType_PK primary key (Id)
> )
> JpaType jpa = new JpaType();
> jpa.setName("Test 1");
> em.persist(jpa);
> em.flush();
> It works OK if I remove identity column (and set ID myself).
> Stack trace
> <0|true|0.9.0> org.apache.openjpa.persistence.PersistenceException:
> java.math.BigDecimal
> at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1576)
> at
> org.apache.openjpa.kernel.DelegatingBroker.flush(DelegatingBroker.java:927)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.flush(EntityManagerImpl.java:421)
> at mytest.domain.JpaTest.testJpa(JpaTest.java:30)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
> at
> org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
> at
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
> at
> org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
> at
> org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
> at
> org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:71)
> at
> org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35)
> at
> org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
> at
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
> at
> org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> Caused by: java.lang.ClassCastException: java.math.BigDecimal
> at mytest.domain.model.JpaType.pcReplaceField(JpaType.java)
> at
> org.apache.openjpa.kernel.StateManagerImpl.replaceField(StateManagerImpl.java:2824)
> at
> org.apache.openjpa.kernel.StateManagerImpl.storeObjectField(StateManagerImpl.java:2284)
> at
> org.apache.openjpa.kernel.StateManagerImpl.storeField(StateManagerImpl.java:2380)
> at
> org.apache.openjpa.kernel.StateManagerImpl.storeField(StateManagerImpl.java:723)
> at
> org.apache.openjpa.kernel.StateManagerImpl.store(StateManagerImpl.java:719)
> at
> org.apache.openjpa.jdbc.meta.strats.HandlerFieldStrategy.setAutoAssignedValue(HandlerFieldStrategy.java:361)
> at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:119)
> at
> org.apache.openjpa.jdbc.kernel.PreparedStatem
Re: Update version to SNAPSHOT
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.openjpa.conf.ProductDerivation openjpa-persistence-jdbc/src/main/resources/META-INF/services/ org.apache.openjpa.conf.ProductDerivation openjpa-persistence/src/main/resources/META-INF/services/ org.apache.openjpa.conf.ProductDerivation It's probably not rocket science to fix these (we would would just need to figure out a way to append them to each other), but it would prevent OpenJPA from working if we were to just merge the jars and overwrite same-named files. On Aug 15, 2006, at 12:46 PM, David Blevins wrote: 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 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 guess you are talking specifically about some pluggable strategy to merge two files of the same name such as two META-INF/persistence.xml files or two META-INF/ejb-jar.xml files? Actually, I was thinking about META-INF/MANIFEST.MF and META-INF/services/*. But yes, merging of resources. Everything in META-INF/services/* will be copied into the new jar and you can redefine MANIFEST entries for the new jar using the same syntax as for the maven-jar-plugin. But it won't intelligently concatenate the contents of individual matching files from the source jars as I assume Brett was referring to with the plexus components.xml. 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 MANIFEST.MF file itself, 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? It's pretty easy to make a new MANIFEST.MF that better describes the new "uber" jar. -David
RE: Update version to SNAPSHOT
> > 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 > MANIFEST.MF file itself, 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? Yes. -Patrick ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Update version to SNAPSHOT
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 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 guess you are talking specifically about some pluggable strategy to merge two files of the same name such as two META-INF/persistence.xml files or two META-INF/ejb-jar.xml files? Actually, I was thinking about META-INF/MANIFEST.MF and META-INF/services/*. But yes, merging of resources. Everything in META-INF/services/* will be copied into the new jar and you can redefine MANIFEST entries for the new jar using the same syntax as for the maven-jar-plugin. But it won't intelligently concatenate the contents of individual matching files from the source jars as I assume Brett was referring to with the plexus components.xml. 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 MANIFEST.MF file itself, 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? It's pretty easy to make a new MANIFEST.MF that better describes the new "uber" jar. -David
Re: Update version to SNAPSHOT
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 definitely add the files from all the META-INF directories into the resulting jar. I guess you are talking specifically about some pluggable strategy to merge two files of the same name such as two META-INF/persistence.xml files or two META-INF/ejb-jar.xml files? Actually, I was thinking about META-INF/MANIFEST.MF and META-INF/services/*. But yes, merging of resources. Everything in META-INF/services/* will be copied into the new jar and you can redefine MANIFEST entries for the new jar using the same syntax as for the maven-jar-plugin. But it won't intelligently concatenate the contents of individual matching files from the source jars as I assume Brett was referring to with the plexus components.xml. 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? Craig Craig Russell [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: Update version to SNAPSHOT
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 directories into the resulting jar. I guess you are talking specifically about some pluggable strategy to merge two files of the same name such as two META-INF/persistence.xml files or two META-INF/ejb-jar.xml files? Actually, I was thinking about META-INF/MANIFEST.MF and META-INF/services/*. But yes, merging of resources. Everything in META-INF/services/* will be copied into the new jar and you can redefine MANIFEST entries for the new jar using the same syntax as for the maven-jar-plugin. But it won't intelligently concatenate the contents of individual matching files from the source jars as I assume Brett was referring to with the plexus components.xml. -David
RE: Extending the OpenJPA implementation
> 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 what I've proposed thus far does > nothing to alleviate it. I think we could probably figure something > out where the extended product looks for its own PersistenceProvider > type in persistence.xml when attempting to load() conf, (this is a > good reason to extend PersistenceProviderImpl even when not > necessary), and the resulting ConfigurationProvider somehow records > this info in the Configuration such that other product > extensions can > check to see if they're compatible with whatever originally loaded > the Configuration in their beforeConfigurationLoad, etc > callbacks. I > don't think this is critical right now and I obviously > haven't worked > out any details, but it might be something we'll want to tackle > eventually. I agree that this is something that we should work out, and is the reason that I mentioned earlier that we might want a Kodo-specific PersistenceProvider at the end of the day. Seems like it's in everyone's best interests for multiple systems with different OpenJPA derivatives to behave deterministically. -Patrick ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Extending the OpenJPA implementation
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. Only the OpenJPAPersistence.toEntityManagerFactory helper creates EMFs. So all we need to do is use our PersistenceProductDerivation to add a lib.conf.PluginValue (or maybe a custom Value if you want to continue to pass the delegate BrokerFactory into the EMF's constructor rather than create a setter for it) to the Configuration in beforeConfigurationLoad. This Value determines what class of EMF to create. The default will be our EntityManagerFactoryImpl, but a later ProductDerivation for a specific extended product could change the default to some extended type. Then we modify OpenJPAPersistence.toEMF to use this Value to instantiate the right EMF type. While we're at it, we change OpenJPAPersistence.toEM to create the EM through the EMF so that the EMF can generate its own EM subclass, rather than constructing an EM directly as it does now. Given the ability to specify a custom EMF type above, I doubt you'd need to create a custom PersistenceProviderImpl +ConfgurationProviderImpl pair. However, if you wanted to do this, you could. The PersistenceProviderImpl extension is obviously easy, as the persistence.xml file specifies it. But recall that that wouldn't cover cases where the user invokes a cmd-line tool and we still have to load specialized configuration. According to my last email, though, we'll now loop over the ProductDerivations when loading conf from most to least derived (based on the derivations getType() return value). So the ProductDerivation for your extended product will be invoked before the standard PersistenceProductDerivation when looking for conf, and you can therefore return your own ConfigurationProvider type (or do as Patrick mentioned and modify the standard one to accept the expected provider class as a parameter). 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 what I've proposed thus far does nothing to alleviate it. I think we could probably figure something out where the extended product looks for its own PersistenceProvider type in persistence.xml when attempting to load() conf, (this is a good reason to extend PersistenceProviderImpl even when not necessary), and the resulting ConfigurationProvider somehow records this info in the Configuration such that other product extensions can check to see if they're compatible with whatever originally loaded the Configuration in their beforeConfigurationLoad, etc callbacks. I don't think this is critical right now and I obviously haven't worked out any details, but it might be something we'll want to tackle eventually. - ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (OPENJPA-12) Default to strictIdentityTypes for JPA
[ 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 at hand is whether the default should be to be strict or to be lenient for JPA installations. Does anyone have a dissenting opinion? > Default to strictIdentityTypes for JPA > -- > > Key: OPENJPA-12 > URL: http://issues.apache.org/jira/browse/OPENJPA-12 > Project: OpenJPA > Issue Type: Bug > Components: jpa >Reporter: Michael Dick >Priority: Minor > Attachments: patch.txt > > > The default behavior with OpenJPA is to be very forgiving regarding the > Primary Key types passed in when calling EntityManager.find or > EntityManager.getReference. > For example if an Entity has an ID of type Long OpenJPA will attempt to > convert anything that extend java.lang.Number and Strings (maybe others). > This is a nice feature, but I don't think it should be the default behavior. > The JPA spec indicates that an IllegalArgumentException should be thrown if > the second argument is not a valid type for the Entity's primary key. There > is some room for interpretation as to what constitutes a valid type, > conversion for all Numbers makes sense, but String might be pushing it. > Workaround : > Add the following to persistence.xml > value="strictIdentityValues=true" /> > Proposed Solution : > The OpenJPA compatibility plugin provides a mechanism to enforce strict > identity checking (defaulting to false). There's no need to change the > default in the kernel (other persistence apis like JDO might be more lenient) > so I propose changing the default in > PersistenceProductDerivation.beforeConfigurationLoad(). > Changing it there should only effect the JPA facade and leave the OpenJPA > kernel's default in place for other facades. > The value may be overridden by adding the following property to > persistence.xml > value="strictIdentityValues=false" /> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Extending the OpenJPA implementation
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(), addProperty(ies)(), setInto().
This keeps ProductDerivations stateless and therefore cacheable and
threadsafe. So when looking for configuration, instead of
instantiating ConfigurationProviders from services and looping
through them to find one that loads, we instead use our loop
through our list of ProductDerviations in order from most-specific
(highest return value from ProductDerivation.getType()) to least,
until one returns a non-null ConfigurationProvider.
As this isn't at all clear, let me sum up. ProductDerivation gains
the load() methods from ConfigurationProvider:
interface ProductDerivation {
ConfigurationProvider loadGlobals(ClassLoader);
ConfigurationProvider load(String, String, ClassLoader);
...
}
And ConfigurationProvider is reduced to the methods dealing with
adding properties and setting into a Configuration.
ProductDerivation remains stateless, but becomes a factory for
ConfigurationProviders.
-
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
Re: Extending the OpenJPA implementation
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 ramblings. But I'll try to describe what I had in mind. First, note that the ConfigurationProvider interface is in lib, and is completely general. It has no notion of specs or persistent stores. The ProductDerivation interface, on the other hand, is in kernel, and it does understand specs and stores (not specific ones, just that those concepts exist). So to move ConfigurationProvider functionality into ProductDerivation while maintaining the meaning of lib vs. kernel, we either have to move the utility methods that utilize ConfigurationProviders out of lib and into kernel, or move a base ProductDerivation interface without spec and store knowledge from kernel into lib. In the latter case, kernel would then derive an OpenJPAProductDerivation interface to add back spec and store knowledge. Granted, OpenJPA (and its extensions) is the only product that builds on lib, so having a distinct, non-persistence-aware lib is of questionable value now, but while it exists I intend to maintain its meaning. Plus, Kodo does have some internal services that use lib without being persistence-specific (and for that reason, it'd be nice to use the latter approach in which ProductDerivation is generalized for use in lib, rather than the former where some current functionality is moved from lib into kernel, though I'm sure we could live with either). 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(), addProperty(ies)(), setInto(). This keeps ProductDerivations stateless and therefore cacheable and threadsafe. So when looking for configuration, instead of instantiating ConfigurationProviders from services and looping through them to find one that loads, we instead use our loop through our list of ProductDerviations in order from most-specific (highest return value from ProductDerivation.getType()) to least, until one returns a non- null ConfigurationProvider. 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. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Update version to SNAPSHOT
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 Ant users. Exactly -- mvn users will use the dependencies, but people who want to download and use the distribution directly may not want a billion little jars. Yes, my experience says it's ok to have 10 dependencies on e.g. commons-logger, antlr, etc. but having 10 dependencies on openjpa- kernel4, openjpa-kernel5, openjpa-api, openjpa-blah is annoying. So if possible, I'd also like to have a jar with all the stuff in it. Craig -Patrick __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
RE: Update version to SNAPSHOT
> > 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 guess you are talking specifically about some > pluggable strategy to merge two files of the same name such as two > META-INF/persistence.xml files or two META-INF/ejb-jar.xml files? Actually, I was thinking about META-INF/MANIFEST.MF and META-INF/services/*. But yes, merging of resources. -Patrick ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: Update version to SNAPSHOT
> 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 the dependencies, but people who want to download and use the distribution directly may not want a billion little jars. -Patrick ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Fixed the geronimo-jpa-spec jar
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 stick with the CDDL version, but thought you might like the option. -David Index: openjpa-persistence/pom.xml === --- openjpa-persistence/pom.xml (revision 430652) +++ openjpa-persistence/pom.xml (working copy) @@ -21,10 +21,9 @@ compile -javax.persistence -persistence-api -1.0 -compile +org.apache.geronimo.specs +geronimo-jpa_3.0_spec +1.0-SNAPSHOT
