I'm having a hard time tracking down the thread regarding the discussion
about where the site and docs should be kept. Would someone mind
replying with a URL? I'd like to first go catch up on that, and then
maybe push for a decision from the community so we can move ahead.
Thanks...
Marc
Hi Bryan,
The thread named staging of site changes dated 25-July is the
thread to which I referred. It has some expressed points of view but
no conclusion.
http://mail-archives.apache.org/mod_mbox/incubator-open-jpa-dev/
200607.mbox/thread
Craig
On Aug 22, 2006, at 8:43 AM, Bryan Noll
Thanks Craig for the link...
So... having caught up on that thread, seems like the following are the
key points:
1. People seem to like the easiness of wiki editing for the main
site. (If wiki content is specific to a particular release, it
would just be identified as such, much
Doh! Thanks for the reminder, Bill. I didn't even think of that.
On Windows, I updated the \Documents and Settings\Administrator\Application
Data\Subversion\config file to include the following statement in the
[miscellany] section:
global-ignores = target .*
I re-started Eclipse after
Mike-
jvm${JAVA_HOME}/bin/java/jvm
Unfortunately, I don't think that's portable ... on OSX, the java
command can be at ${JAVA_HOME}/Commands/java, and some versions of
the IBM java command are at ${JAVA_HOME}/jre/sh/java.
Is there some reason why you can't override both the
Marc, there's no reason but I'm just reporting a build failure due to my
environment. Someone else might have the same problem but not know what
the problem is or how to fix it. You should be able to use OS profiles to
extend my fix to work in OSX. I don't have an example of how to do this
Are OS profiles a maven thing? Note that this list is populated largely
with maven newbies.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
-Original Message-
From: Mike Perham [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 22, 2006 11:01 AM
To: open-jpa-dev@incubator.apache.org
Patrick, yes, they are a way to compartmentalize variance between different
build environments. You guys are already using them in your top-level POM
which is why I thought it would be relatively familiar. Here's a decent
start although it does not seem to cover profile activation based on
Mike-
That's a lousy error message, but I'm not sure what it causing it. Do
you have all of the openjpa-*.jar files in your CLASSPATH? It almost
sounds like one of the META-INF/services/ files that reports the
available metadata factories is not being found. How did you create
the jars?
That's a lousy error message, but I'm not sure what it causing it.
Do you have all of the openjpa-*.jar files in your CLASSPATH? It
almost sounds like one of the META-INF/services/ files that reports
the available metadata factories is not being found. How did you
create the jars? Did you
[ http://issues.apache.org/jira/browse/OPENJPA-15?page=all ]
Catalina Wei updated OPENJPA-15:
Attachment: OPENJPA-15.openjpa-kernel.txt
This patch is applied successfully against openjpa-kenel.
please ignore the previous attachments.
EJBQL grammar
I dorked with it some more, and got it to the point where it wrote out a
properties file with the subversion revision info in it (a la David's
example)... but then ran into a wall in terms of getting the scope of
that property to hang around long enough to stuff it into. I hopped on
the
[ http://issues.apache.org/jira/browse/OPENJPA-15?page=all ]
Kevin Sutter updated OPENJPA-15:
Comment: was deleted
EJBQL grammar needs to be updated to relfect JPA specification
--
Now that we have successfully created a patch for OPENJPA-15, what is the
process for getting this validated and hopefully accepted into SVN? I have
been able to verify that the patch can be applied, everything builds, and
the existing testcases still work. But, I'm not an expert with the code
(Note that my response here doesn't really answer your question.)
I think that it's good that we've been using JIRA to store information
about changes we're making, but I think it's far more important that we
create test cases that demonstrate the old bad behavior and assert the
new good
Sounds like a good plan. New or updated tests would be good to demonstrate
that a fix works. Even if we would provide a working testcase with the fix,
that would be a good way to populate our test bucket.
Concerning all of the query related JIRA reports that have been opened, do
we have a base
Sounds like a good plan. New or updated tests would be good to
demonstrate
that a fix works. Even if we would provide a working testcase with
the fix,
that would be a good way to populate our test bucket.
Concerning all of the query related JIRA reports that have been
opened, do
we have
Hi,
Has there been any investigation into providing a JPA-like implementation
that would execute in the JDK 1.4 environment? I know we have the
Java 5.0requirements for generics and enums built right into the JPA
interfaces. I
was just wondering whether anybody has investigated down-grading the
I've gone ahead and committed something that does Bryan's suggestion:
generates a /META-INF/revision.properties file and outputs the
current Subversion revision number to it.
The org.apache.openjpa.conf.OpenJPAVersion class will load that file
and store it in the static REVISION_NUMBER
Kevin-
I applied your patch, but there were a couple problems with our local
tests. This statement caused a parse error:
update kodo.kernel.AttachD x set x.dint = 1 where x.dint
(select min(y.dint) from kodo.kernel.AttachD y)
1)
20 matches
Mail list logo
