David-
This part of the patch fixes what is clearly a bug with scanning
directories:
-scan(new FileMetaDataIterator(dir,
newMetaDataFilter()),
+//TODO should this call setStoreDirectory(file)
+scan(new
[
https://issues.apache.org/jira/browse/OPENJPA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marc Prud'hommeaux resolved OPENJPA-148.
Resolution: Fixed
Applied (partial) patch.
Parsing exception while using an
I'd like reopen the discussion on how to package and name our
artifacts. I think the current setup could be improved, to give a
better experience for users who might not be using maven for
dependency management. It's easy for us to change now before
graduation because once we graduate,
It's not too late to vote. Everyone in the community is encouraged to
review the material, provide any comments, and vote.
Craig
Begin forwarded message:
From: Craig L Russell [EMAIL PROTECTED]
Date: May 3, 2007 7:22:05 AM PDT
To: open-jpa-dev@incubator.apache.org
Subject: [VOTE] Graduate
Hi, Craig. Apologies for not having reviewed this yet; I've been
traveling this week and without much access to e-mail. When does this
vote close?
Thanks.
Eddie
On 5/4/07, Craig L Russell [EMAIL PROTECTED] wrote:
It's not too late to vote. Everyone in the community is encouraged to
review
Some comments below
On 5/4/07, Craig L Russell [EMAIL PROTECTED] wrote:
I'd like reopen the discussion on how to package and name our
artifacts. I think the current setup could be improved, to give a
better experience for users who might not be using maven for
dependency management. It's easy
The vote closes May 6. Standard 3 day period. I should have put this
in the original email.
Craig
On May 4, 2007, at 5:59 AM, Eddie O'Neil wrote:
Hi, Craig. Apologies for not having reviewed this yet; I've been
traveling this week and without much access to e-mail. When does this
vote
No worries and thanks for the update -- I just wanted to make sure I
still had some time to respond to the thread. :)
Eddie
On 5/4/07, Craig L Russell [EMAIL PROTECTED] wrote:
The vote closes May 6. Standard 3 day period. I should have put this
in the original email.
Craig
On May 4, 2007,
[
https://issues.apache.org/jira/browse/OPENJPA-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe White reopened OPENJPA-51:
--
I have to reopen this, as the fix is causing a regression in our test suite.
Given an entity EntityA
+1
Craig L Russell wrote:
This vote is to send the attached draft board resolution to the
incubator for the purpose of graduation from the incubator to the
Apache OpenJPA project.
+1 We're ready; let's graduate
0 Don't care
-1 Let's wait
Establish the Apache OpenJPA project
[
https://issues.apache.org/jira/browse/OPENJPA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493730
]
David Jencks commented on OPENJPA-148:
--
Marc did not apply this part of the patch, which was actually the
[
https://issues.apache.org/jira/browse/OPENJPA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493735
]
Marc Prud'hommeaux commented on OPENJPA-148:
I understand the reason for that part now. I've applied
[
https://issues.apache.org/jira/browse/OPENJPA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493736
]
Craig Russell commented on OPENJPA-148:
---
Just thinking a bit outside the box here. Is it possibly a bug that
Hi Craig,
+1
Regards Michael
This vote is to send the attached draft board resolution to the
incubator for the purpose of graduation from the incubator to the
Apache OpenJPA project.
+1 We're ready; let's graduate
0 Don't care
-1 Let's wait
Establish the Apache OpenJPA project
[
https://issues.apache.org/jira/browse/OPENJPA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493739
]
Florent BENOIT commented on OPENJPA-148:
I tested with the last revision 535321 (that includes the second
+1
Only comment is that we might consider narrowing the scope a tiny
bit, saying something like
to be known as Apache OpenJPA, chartered with the
implementation of the Java Persistence API as well as related object
persistence technology, for dis...
Just so that the board doesn't
[
https://issues.apache.org/jira/browse/OPENJPA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493746
]
David Jencks commented on OPENJPA-148:
--
Craig said...
Just thinking a bit outside the box here. Is it possibly
Just one note (this problem caused us a lot of headaches in GlassFish): I'm not
sure if url.getFile() handles spaces in the url correctly. If it doesn't, our
solution was to use 'new File(url.toURI())'.
-marina
David Jencks (JIRA) wrote:
[
I personally define OpenJPA by the persistence engine and not the
spec it implements. A good persistence engine is very hard to write,
but adapting it to new persistence specs if fairly easy in
comparison. I would like to see the scope be limited to java
persistence with an eye toward
Would we then not have to change the overall name from JPA to openPersistence or
some such? Why not let another project lift out the engine and adapt JDO/SDO/ETC
and maybe we remerge the projects later.
Maybe this idea works if we can fully separate the API from the persistence
engine as it does
SQL reordering to avoid non-nullable foreign key constraint violations
--
Key: OPENJPA-235
URL: https://issues.apache.org/jira/browse/OPENJPA-235
Project: OpenJPA
Issue
[
https://issues.apache.org/jira/browse/OPENJPA-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reece Garrett updated OPENJPA-235:
--
Attachment: sqlreorder.patch
Patch includes code changes and test cases.
SQL reordering to
[
https://issues.apache.org/jira/browse/OPENJPA-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493764
]
Catalina Wei commented on OPENJPA-51:
-
Abe,
Is it really a regression? I replaced the copy of SelectImpl with
On May 4, 2007, at 10:50 AM, Phill Moran wrote:
Would we then not have to change the overall name from JPA to
openPersistence or
some such?
That would suck. I see no reason we would have to change the
name. It is a choice of the community.
Why not let another project lift out the
Without getting any nastier let me explain. I see a discontinuity in calling the
project OpenJPA if in reality the project implements JDO and so forth.
If we can separate the engine from the API and make the API pluggable/selectable
and the project is planning on implementing other APIs then a
I see a discontinuity in calling the
project OpenJPA if in reality the project implements JDO and so forth.
I agree; there is a logical disconnection here.
If we can separate the engine from the API and make the API pluggable/selectable
The engine is very well-separated from the API as
I agree with you on the name change and the timing around it. My comments are
mainly directed towards holding a non-representative name if other APIs are
implemented.
A decision that can be made later along with any necessary re-packaging needs
Sincerely,
Phill
-Original
While we're on the topic, do you have any compelling new name ideas?
Clearly, if we had a new name handy, it could be advantageous to
create that TLP and then an OpenJPA subproject from the start. I don't
think that we should hold up the graduation for this, but it does seem
like the thing that's
Hi Phill,
My sense of this community is that they don't want to be restricted
in the space of API implementations that make sense for their
pluggable persistence engine.
I would like to hear from other community members on this subject.
If you feel that you want to change your vote and
On May 4, 2007, at 1:01 PM, Craig L Russell wrote:
Hi Phill,
My sense of this community is that they don't want to be restricted
in the space of API implementations that make sense for their
pluggable persistence engine.
Agreed wholeheartedly.
I would like to hear from other
I have no desire in calling a new vote my comments where, to some degree,
philosophical. I am well along the road in implementing a application using
OpenJPA so I think we are ready to graduate.
As mentioned we currently have no plans (or restrictions for that matter) on
other APIs so keeping the
[
https://issues.apache.org/jira/browse/OPENJPA-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Linskey reassigned OPENJPA-235:
---
Assignee: Patrick Linskey
SQL reordering to avoid non-nullable foreign key
Here are two quickly made up thoughts (Google shows no one is using them at the
moment in open source)
Persius sounds a little like persistence, and is a good old name
I was thinking North Sea - Thinking association with platform (as in oil
platform) but that is a stretch so how about a Synonym
Now I'm sorry I sent this email and would like to withdraw my
comments. If the community wants to change the charter or name they
can petition the board later.
I'd like to see the vote continue as is.
-dain
On May 4, 2007, at 10:36 AM, Dain Sundstrom wrote:
I personally define OpenJPA by
[
https://issues.apache.org/jira/browse/OPENJPA-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Linskey resolved OPENJPA-235.
-
Resolution: Fixed
SQL reordering to avoid non-nullable foreign key constraint
Hi,
Earlier this week, I wrote a (very) basic OpenJPA / IntelliJ plugin.
It automatically runs the enhancer on persistent types after
compilation completes, for any persistence units that don't have a
persistence provider declared or that declare OpenJPA as their
persistence provider.
Clearly,
36 matches
Mail list logo
