Re: svn commit: r569253 - in /openjpa/branches/1.0.0/openjpa-kernel/src/main: java/org/apache/openjpa/enhance/PCEnhancer.java resources/org/apache/openjpa/enhance/localizer.properties

[Craig L Russell]

On Aug 24, 2007, at 10:11 AM, Patrick Linskey wrote:

"1.0.0". As we discussed before, we don't have a "1.0" branch because
we have not yet discussed a "1.0" roadmap.

Let's put this bit to rest. I have been assuming per email discussions
from last year and general best practices that we will have patch
releases that contain nothing but bugfixes. Given that, the 1.0.x
roadmap is by definition constrained to patches. A roadmap for 1.1
would be useful, but is totally separate from any need for a 1.0.x
branch.

+1

The current "1.0.0" branch is *only* for changes that are to go into
the 1.0.0 release. Full stop.

... and I think that this is unnecessary. I do not believe that the
concepts that you discussed are at all orthogonal to general 1.0.x
maintenance. It is just a pathological special case in which there has
not yet been a 1.0.0 release, but is otherwise identical to the
requirements for a 1.0.1 release or a 1.0.2 release.

It sounds like there is an *orthogonal* concern that we do not yet
have a branch on which changes destined for 1.0.x should go. That's
an understandable concern, but it has nothing to do with the very
specific and short-lived purpose of the branch that is called
"1.0.0".

I think that having a branch for this specific and short-lived purpose
is a Bad Idea. I see no reason why we should not just create a branch
for a release as described in my last two emails, rather than creating
a branch, throwing it away, and hopefully properly re-creating a
branch with the same contents.

I'm perfectly fine with making a "1.0" branch on which we will commit
changes destined for 1.0.x releases. Ideally, this would have been
done before we branched for "1.0.0", so that we could have branched
from the "1.0" branch, but I don't know if subversion actually cares
about the hierarchy of branches when it comes to merging.

Indeed, I think that ideally, it should have been done *instead* of
creating the "1.0.0" branch.

+1

So how about we do the following?

1. Immediately create a branch off of trunk called "1.0". Maintenance
changes destined for 1.0.1 will be made on that branch.
2. Once the 1.0.0 release is approved and published, merge the
changes from the "1.0.0" branch into the "1.0" branch and tag the
released bits in the "1.0.0" branch as "1.0.0", then delete the
"1.0.0" branch.
3. In the future, cut the "1.0.1" branch off of the "1.0" branch.

I think that we should do the following:

1. rename the "1.0.0" branch to "1.0". Maintenance changes destined
fro 1.0.1 will be made on that branch.

+1

2. Once the 1.0.0 release is approved and published, create a 1.0.0
tag, and do not delete the 1.0 branch.

+1

Just note that the terms tag and branch have no meaning in svn (I think they actually did mean something in cvs). In svn, you just name a revision of a module and svn remembers it using copy-on-write. So there's no cost to making a tag or a branch. As a group we can decide that a branch continues to have development on it and a tag is read- only.

3. In the future, do not cut a "1.0.1" branch at all. Instead, when
the time comes for 1.0.1 work, do it directly from the 1.0 branch
(which, per my assertion above, contains only bugfixes, and so does
not risk tainting the branch), and create a tag from the branch.

Once we agree on the naming we need to update http://cwiki.apache.org/ confluence/display/openjpa/Releasing+OpenJPA

Craig

Since we will have active development on the trunk and on the 1.0 branch, the release manager for the 1.0.1 release will need to do the work of merging desired fixes from the trunk back to the branch.

I think that this simplifies and streamlines the process, and loses
none of the current source-isolation that we have in our
transient-branch strategy.

-Patrick

On 8/24/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:

I think the point of having a release branch is so that:

1. Cosmetic/miscellaneous changes can be made in the release branch
to fix problems with the candidate builds.
2. More importantly, other people can make changes on one of the
parent branch(es) during the sometimes multi-week release voting
process without messing up the release branch.

The current "1.0.0" branch is *only* for changes that are to go into
the 1.0.0 release. Full stop.

It sounds like there is an *orthogonal* concern that we do not yet
have a branch on which changes destined for 1.0.x should go. That's
an understandable concern, but it has nothing to do with the very
specific and short-lived purpose of the branch that is called
"1.0.0". As we discussed before, we don't have a "1.0" branch because
we have not yet discussed a "1.0" roadmap.

I'm perfectly fine with making a "1.0" branch on which we will commit
changes destined for 1.0.x releases. Ideally, this would have been
done before we branched for "1.0.0", so that we could have branched
from the "1.0" branch, but I don't know if subversion actually cares
about the hierarchy of branches when it comes to merging.

So how about we do the following?

1. Immediately create a branch off of trunk called "1.0". Maintenance
changes destined for 1.0.1 will be made on that branch.
2. Once the 1.0.0 release is approved and published, merge the
changes from the "1.0.0" branch into the "1.0" branch and tag the
released bits in the "1.0.0" branch as "1.0.0", then delete the
"1.0.0" branch.
3. In the future, cut the "1.0.1" branch off of the "1.0" branch.




On Aug 24, 2007, at 12:23 PM, Patrick Linskey wrote:

It seems like we should be able to accomplish that by renaming the
1.0.0branch to
1.0. When we're done with 1.0.0 we can create a new branch and tag
with the
correct name.

I agree completely.

I think that making the branch and then throwing it away and then

prone and cumbersome.


that branch is being sourced (trunk, somewhere else, etc.), and then
work on a release on that branch. Once the release is done, we then
tag that moment in time, but keep the x.y release branch alive for
work that should go into x.y.1. When the time comes for the x.y.1

since the only work that's happening in the x.y branch should be
maintenance work anyways. We just work on the release in the release
branch, get it done, and then tag it when it's ready.

I think that our current model of making these transient branches is

were working towards a 1.0.0 release, since we never planned to have
hardening releases off of 0.9.7, for example. But now that we're
moving past 1.0.0, I think that it's important to have a branching
strategy in place that supports patch line maintenance.

Thoughts?

-Patrick

On 8/24/07, Michael Dick <[EMAIL PROTECTED]> wrote:

creating another branch with allegedly-identical contents sounds error As I mentioned earlier, I think that we should change our processes to create a release branch for an x.y.0 release from wherever it is that release, we then do not need to create one of these release branches, well-suited for a single-branch methodology. That worked well while we

On 8/24/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:

I agree with most of what Marc is saying. However, I strongly feel

the process of making a maintenance branch for a given release.

that we need to change how we're doing our branching strategy. In my opinion, creating these throwaway branches unnecessarily complicates

+1. Marc (or any other release manager) shouldn't have to merge
changes back
into trunk.

Can someone explain to me where we are going to do 1.0.1 work in the

current process?

Prior to our discussion in a different thread I thought that 1.0.1
work
would be done in the 1.0.0 branch that we're using now. Basically
when we're
done with 1.0.0 we would create a tag. Anything committed after
that point
would be part of 1.0.1 until we release it and create another tag.

The new plan is to create a branch and call it 1.0. 1.0.0, 1.0.1,
1.0.2 etc
are branches off of 1.0 (I think).

It seems like we should be able to accomplish that by renaming the
1.0.0branch to
1.0. When we're done with 1.0.0 we can create a new branch and tag
with the
correct name.

-Mike

-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.


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).


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:

Once 1.0.0 is released, I will tag the currently *released* source I will document this process on the revised release instructions on

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

respin?

include

of the
1.0.1 snapshot release?

Thanks,
Kevin

On 8/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

re-spin and [VOTE] was posted. So, does this require yet another If not, then what happens to these changes? The [VOTE] would not these changes. So, would these changes automatically become part

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

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);

+                _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

+        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}

message:
{1}
\ No newline at end of file

openjpa/branches/1.0.0/openjpa-kernel/src/main/resources/ org/ =============================================================== == + throw new GeneralException(_loc.get("enhance- error", + // meta is null when doing persistence-aware enhancement =============================================================== == +enhance-error: An error occurred while enhancing {0}. Exception

--
Patrick Linskey
202 669 5907

--
Patrick Linskey
202 669 5907

--
Patrick Linskey
202 669 5907

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