The release branch (what is currently called "1.0.0") is used for
exactly one thing: allowing people to continue to make significant
changes on trunk (or any other branch) without messing up the code
for the release, should the need arise to re-spin a release. I don't
see any reason why this technique should need to have any overlap
with how we manage branches for maintenance releases vs. major/minor
releases.
As we discussed before, making branches for major/minor/maintenance
releases might be easier to manage once we have a roadmap for which
features we want to go where.
In any case, my intention is to merge the "1.0.0" back to trunk once
the release is finalized, and then we can cut branches from there as
our leisure.
On Aug 24, 2007, at 11:53 AM, Patrick Linskey wrote:
I agree with most of what Marc is saying. However, I strongly feel
that we need to change how we're doing our branching strategy. In my
opinion, creating these throwaway branches unnecessarily complicates
the process of making a maintenance branch for a given release.
Can someone explain to me where we are going to do 1.0.1 work in the
current process?
-Patrick
On 8/24/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:
Kevin-
Unless Patrick objects to the current (fourth) vote on the 1.0.0
artifact based on this commit, it won't make it into the 1.0.0 final
release bits.
Once 1.0.0 is released, I will tag the currently *released* source
code in the 1.0.0 branch as "1.0.0", and then merge the *latest*
source code in the 1.0.0 branch back into the trunk, so any additions
to the 1.0.0 branch will certainly be merged back to the trunk
(although they will only be released in the 1.0.0 assembly if we
happen to need to cut another release).
I will document this process on the revised release instructions on
the wiki once I get around to assembling them. We are playing a
little fast and loose with last-minute changes in what should
probably be a more solemn process, but since this is the first major
release as a TLP, I think we can make a few exceptions.
On Aug 24, 2007, at 8:37 AM, Kevin Sutter wrote:
Patrick and Marc,
Help me understand our process here. This commit is similar to the
one I
did the other evening. It was committed into the 1.0.0 branch
after the 4th
re-spin and [VOTE] was posted. So, does this require yet another
respin?
If not, then what happens to these changes? The [VOTE] would not
include
these changes. So, would these changes automatically become part
of the
1.0.1 snapshot release?
Thanks,
Kevin
On 8/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: pcl
Date: Thu Aug 23 22:27:43 2007
New Revision: 569253
URL: http://svn.apache.org/viewvc?rev=569253&view=rev
Log:
Minor logging / exception handling improvements
Modified:
openjpa/branches/1.0.0/openjpa-kernel/src/main/java/org/apache/
openjpa/enhance/PCEnhancer.java
openjpa/branches/1.0.0/openjpa-kernel/src/main/resources/org/
apache/openjpa/enhance/localizer.properties
Modified:
openjpa/branches/1.0.0/openjpa-kernel/src/main/java/org/apache/
openjpa/enhance/PCEnhancer.java
URL:
http://svn.apache.org/viewvc/openjpa/branches/1.0.0/openjpa-kernel/
src/main/java/org/apache/openjpa/enhance/PCEnhancer.java?
rev=569253&r1=569252&r2=569253&view=diff
===================================================================
==
=========
---
openjpa/branches/1.0.0/openjpa-kernel/src/main/java/org/apache/
openjpa/enhance/PCEnhancer.java
(original)
+++
openjpa/branches/1.0.0/openjpa-kernel/src/main/java/org/apache/
openjpa/enhance/PCEnhancer.java
Thu Aug 23 22:27:43 2007
@@ -467,7 +467,8 @@
} catch (OpenJPAException ke) {
throw ke;
} catch (Exception e) {
- throw new GeneralException(e);
+ throw new GeneralException(_loc.get("enhance-error",
+ _managedType.getType().getName(), e.getMessage
()), e);
}
}
@@ -2736,7 +2737,10 @@
} catch (Throwable t) {
// last-chance catch for bug #283 (which can
happen
// in a variety of ClassLoading environments)
- _log.warn(_loc.get("enhance-uid-access",
_meta), t);
+ if (_log.isTraceEnabled())
+ _log.warn(_loc.get("enhance-uid-access",
_meta), t);
+ else
+ _log.warn(_loc.get("enhance-uid-access",
_meta));
}
// if we couldn't access the serialVersionUID, we
will have
to
@@ -3672,10 +3676,13 @@
* attribute name for the backing field <code>name</code>.
*/
private String fromBackingFieldName(String name) {
- if (_meta.getAccessType() == ClassMetaData.ACCESS_PROPERTY
+ // meta is null when doing persistence-aware enhancement
+ if (_meta != null
+ && _meta.getAccessType() ==
ClassMetaData.ACCESS_PROPERTY
&& _fieldsToAttrs.containsKey(name))
- name = (String) _fieldsToAttrs.get(name);
- return name;
+ return (String) _fieldsToAttrs.get(name);
+ else
+ return name;
}
/**
Modified:
openjpa/branches/1.0.0/openjpa-kernel/src/main/resources/org/
apache/openjpa/enhance/localizer.properties
URL:
http://svn.apache.org/viewvc/openjpa/branches/1.0.0/openjpa-kernel/
src/main/resources/org/apache/openjpa/enhance/localizer.properties?
rev=569253&r1=569252&r2=569253&view=diff
===================================================================
==
=========
---
openjpa/branches/1.0.0/openjpa-kernel/src/main/resources/org/
apache/openjpa/enhance/localizer.properties
(original)
+++
openjpa/branches/1.0.0/openjpa-kernel/src/main/resources/org/
apache/openjpa/enhance/localizer.properties
Thu Aug 23 22:27:43 2007
@@ -197,4 +197,5 @@
no-accessor: Could not find method called {0} in type {1}.
unspecified-unenhanced-types: One or more of the types in {0} have
relations \
to other unenhanced types that were not specified. These
unspecified
types \
- are: {1}
\ No newline at end of file
+ are: {1}
+enhance-error: An error occurred while enhancing {0}. Exception
message:
{1}
\ No newline at end of file
--
Patrick Linskey
202 669 5907
