Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (athena.apache.org: domain of kwsutter@gmail.com designates
 66.249.92.174 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=CIff+BYfxo1IYNf0+VQ9rCY5tHor6QIZ+xSzasXadPpu3VXOptF9yEiPH/DMKXTJ5Ez/5KfOqgTujaBOgyYiFXEpXSphrr/8YpRf2+DOXyqB48aitMbEzYhEqvrnhG9afIXjY1APnGS5lG0Wwzn3ij+4cpctYEmir755u7KGy+s=
Message-ID: <89c0c52c0708280537k5246f5b9vcb3c1afa006c21aa@mail.gmail.com>
Date: Tue, 28 Aug 2007 07:37:51 -0500
From: "Kevin Sutter" <kwsutter@gmail.com>
To: dev@openjpa.apache.org
Subject: 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
In-Reply-To: <EA98EC8F-5503-4EEC-8017-74AA5D30F410@SUN.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_129209_2504543.1188304671379"
References: <20070824052744.B97E61A9832@eris.apache.org>
	 <28FD6FCF-229C-4CBA-AFC6-7A449A20B6D6@SUN.com>
	 <7262f25e0708261751t5f8ac8f2u476686c58cec2e0e@mail.gmail.com>
	 <C458AF9D-6FA0-4680-A979-94E941A8A86D@SUN.com>
	 <7262f25e0708262129s47f135f0pb0d2e23b70a85203@mail.gmail.com>
	 <89c0c52c0708271429g5f681c07u21e75a6feb49217f@mail.gmail.com>
	 <7262f25e0708271609r26d75cfdt6f3d00d571ff12c3@mail.gmail.com>
	 <27CF9A19-563A-4EA5-8164-9953A55A278B@SUN.com>
	 <45374439-BD87-455E-8A39-767BE46D6D83@apache.org>
	 <EA98EC8F-5503-4EEC-8017-74AA5D30F410@SUN.com>

------=_Part_129209_2504543.1188304671379
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 8/27/07, Craig L Russell <Craig.Russell@sun.com> wrote:
>
>
> On Aug 27, 2007, at 7:45 PM, Marc Prud'hommeaux wrote:
>
> >
> > On Aug 27, 2007, at 9:43 PM, Craig L Russell wrote:
> >
> >> Because I'm of the opinion that the RM should be able to say "I'm
> >> working on the release. Please no checkins until after the release
> >> is built."
> >
> > Note that the checkins were not particularly burdensome. While they
> > had not been explicitly discussed and authorized, they were mostly
> > fixes for identified problems with the release, and since they were
> > relatively minor changes, it wasn't too difficult to handle them.
> > In the future, a better solution would have been to have a parent
> > "1.0" branch (as we've been discussion), and have bugfixes going
> > into the parent branch.
>
> This might be the solution to this issue, assuming that everyone agrees.


Actually, I think this was agreed to "after the fact" via another thread of
discussion.  I actually thought we were going to retrofit this idea into our
current tree to mimic this desired behavior.  I'm assuming that is still
possible.

> The RM can then choose to merge down the changes into the "1.0.0"
> > branch between votes when deemed appropriate. We might even suggest
> > that the RM might want to consider locking the "1.0.0" branch if
> > they are concerned about accidental intra-vote commits slipping in.
>
> Locking the release would only be necessary if people didn't respect
> the RM's control of the release branch.


Agreed.

>
> >> [...] A release cannot be vetoed. If anyone has an issue with an
> >> excluded bit of code that the RM doesn't want to put in, a full
> >> vote is required.
> >
> > On a somewhat related note, I've been wondering if my rescinding of
> > the previous votes were technically legal, since rescinding a vote
> > is tantamount to vetoing it (which can't be done for a release).
>
> The RM can veto a release by simply re-spinning it. For arbitrary and/
> or capricious reasons you can suspend and call another vote. So you
> did nothing out of the ordinary.


Craig provided the "official" response, but I wanted to second your actions
and indicate that your actions with the votes, rescinding, respinning, etc
all seemed very logical and useful.

> While I expect that everyone agrees with the expediency of
> > rescinding and re-starting the vote, I am concerned that it might
> > be bad form.
>
> No, not at all. In exchange for being the go-to guy for the release,
> you get god-like powers.


Cool.

>
> >> By the way, nice job on the release, Marc. You've earned your
> >> vacation/honeymoon.
> >
> > Thank you very much, but I'd hold off on the laudatory remarks
> > until the release is actually published :)
>
> Ok, but my patience is limited. ;-)


Yes, thanks for Marc's patience during this exercise.

Kevin

Craig
> >
> >
> >
> > On Aug 27, 2007, at 9:43 PM, Craig L Russell wrote:
> >
> >>
> >> On Aug 27, 2007, at 4:09 PM, Patrick Linskey wrote:
> >>
> >>>> Granted, some of this discussion is with 20/20 hindsight.  But,
> >>>> we need to
> >>>> figure out our approach and be consistent from the start.  All
> >>>> of us have
> >>>> had various experiences with creating and maintaining branches and
> >>>> releases.  We just need to find a common ground for us to live
> >>>> with.
> >>>
> >>> It sounds a whole lot like Kevin and Craig feel that I somehow made
> >>> the process not work properly.
> >>
> >> No, what I assume is that you had permission from Marc to check in
> >> the changes you made during the release cycle.
> >>
> >>> Can we cite a problem that occurred
> >>> based on what I did? If not, then can we alternately cite any
> >>> concrete
> >>> reason why what I did was undesirable? If not, then why are we
> >>> spending all this time going back and forth about this topic?
> >>
> >> Because I'm of the opinion that the RM should be able to say "I'm
> >> working on the release. Please no checkins until after the release
> >> is built."
> >>>
> >>>> I must really be missing something here, but why would we merge
> >>>> the contents
> >>>> of the 1.0.0 branch back into trunk after the release has been
> >>>> approved?
> >>>
> >>> Typically, in the process of assembling a release, there will be
> >>> changes that have to be made.
> >>
> >> Of course.
> >>
> >>> For example, I noticed that one of the
> >>> first RCs was still shipping with the now-unnecessary JCA jars.
> >>> In my
> >>> experience, there are often quite a number of small tweaks that have
> >>> to be made, and it is typically far easier to make all of these
> >>> in one
> >>> place and then copy them all back to trunk at one time, rather than
> >>> maintaining two branches all along throughout the process.
> >>
> >> That's fine, as long as the RM is willing to then merge the
> >> changes back to the trunk. But I don't believe that the RM should
> >> be required to do this on behalf of everyone who feels that they
> >> want to work on the release branch while the release is being
> >> stabilized.
> >>>
> >>> I think that maybe the big disconnect here is that Craig and Kevin
> >>> seem to be trying to design something that prevents something from
> >>> going wrong during the release process,
> >>
> >> Yes.
> >>
> >>> whereas I feel it's more
> >>> appropriate to design a system that is easy to handle in the happy
> >>> case.
> >>
> >> In my own experience, a project as big as this one can use some
> >> help during release to avoid unnecessary respins simply because a
> >> late-breaking change was not perfect.
> >>
> >> In this case, the only anomaly was Kevin's checkin that missed a
> >> respin. If there had been better communication between Kevin and
> >> Marc, this could have been avoided. Obviously this isn't a big
> >> deal because the release seems to be ok. And I trust that someone
> >> will take responsibility for merging all the 1.0.0 changes into
> >> the trunk.
> >>
> >>> In this situation, the happy case is where people do not commit
> >>> things to the release branch that shouldn't be in there. Assuming
> >>> that
> >>> that happens, then letting multiple people check into the release
> >>> branch helps the release manager by decreasing the patch-moving
> >>> workload, and does not incur any additional cost that I am aware of.
> >>
> >> The critical concept here is "help the release manager". Assuming
> >> they want help. I'm ok with delegating this decision to the RM,
> >> but not mandating it.
> >>>
> >>>> should not have been put into the 1.0.0 branch.  At a minimum,
> >>>> Patrick's
> >>>> changes should have been put into trunk and optionally into the
> >>>> 1.0 branch
> >>>> (in preparation for a 1.0.1 branch).
> >>
> >> I'm not going to go that far. As long as Marc signed up for
> >> cleaning up the trunk after the release is done, I'm fine.
> >>
> >>>> If we determine that an RC5 is
> >>>
> >>> Note that we don't have a 1.0 branch; I believe that the
> >>> consensus on
> >>> that other thread was that the release branch should either directly
> >>> become the maintenance branch, or the release branch should be
> >>> copied
> >>> to the maintenance branch.
> >>
> >> What matters to me is the before-condition and the after-
> >> condition, which I've documented in the other branch (or tag) of
> >> this discussion. How the branch and tag are created are serving
> >> suggestions. But in order to encourage new release managers to
> >> volunteer, we should document what their rights, responsibilities,
> >> and best practices are.
> >>
> >> I'll point out again that the difference between branch and tag is
> >> -0- to svn. It's only we who assign semantic value to a branch
> >> (which I mean to be a continuing code line) and a tag (which I
> >> consider to be a done finished complete point-in-time with a
> >> special name).
> >>
> >>> In any event, it is pretty critical that
> >>> the release branch contents make their way into the maintenance
> >>> branch, and not via trunk.
> >>
> >> Absolutely.
> >>
> >>> Given that this is the case, it seems like
> >>> putting minor fixes directly into the 1.0.0 branch is far and
> >>> away the
> >>> most expedient thing to do, since it means that in the case of a
> >>> failed RC, the RM only needs to re-sync to the 1.0.0 branch. In the
> >>> alternate case, the RM must do a patch-collection phase as well.
> >>
> >> Again, "the RM only needs to do" stuff after the release is
> >> approved seems to unduly burden the RM.
> >>>
> >>> Additionally, FWIW, the concept of designating one person as the
> >>> only
> >>> person qualified to decide if a change should be in the release is
> >>> directly counter to the release voting process.
> >>
> >> Not agree.
> >>
> >>> The RM may make a
> >>> unilateral decision during the release-construction phase, but
> >>> anyone
> >>> can then vote against the release if the RM decides to exclude some
> >>> bit of code from the release.
> >>
> >> Not really. A release cannot be vetoed. If anyone has an issue
> >> with an excluded bit of code that the RM doesn't want to put in, a
> >> full vote is required.
> >>
> >>> IOW, the voting process already provides
> >>> a fail-safe to prevent worst-case scenarios; it seems like the
> >>> rest of
> >>> the process should be designed for expediency.
> >>
> >> There are some cases where autocracy makes sense. I believe this
> >> is one of them. Long Live Release Manager.
> >>
> >> By the way, nice job on the release, Marc. You've earned your
> >> vacation/honeymoon.
> >>
> >> Craig
> >>
> >>>
> >>> -Patrick
> >>>
> >>> On 8/27/07, Kevin Sutter <kwsutter@gmail.com> wrote:
> >>>> Patrick's premise of merging from the 1.0.0 branch back into
> >>>> trunk really
> >>>> threw me...
> >>>>
> >>>> On 8/26/07, Patrick Linskey <plinskey@gmail.com> wrote:
> >>>>>
> >>>>>
> >>>>> (In the case of the 1.0.0 line, I've been committing things to it
> >>>>> directly and not to trunk, on the assumption that we'll be doing a
> >>>>> bulk merge from 1.0.0 to trunk once we're done with the release.)
> >>>>
> >>>>
> >>>> I must really be missing something here, but why would we merge
> >>>> the contents
> >>>> of the 1.0.0 branch back into trunk after the release has been
> >>>> approved?  In
> >>>> my mind, once a given x.y.z release has been approved, there are
> >>>> no more
> >>>> code updates in this branch.  So, any updates done to this
> >>>> branch after the
> >>>> approved svn revision are basically "lost".  They don't apply to
> >>>> any release
> >>>> unless manually moved to the appropriate release.  I think I'm
> >>>> in agreement
> >>>> with Craig here that once a RM has declared a given x.y.z
> >>>> release, then s/he
> >>>> has complete control over what goes in or stays out.  We
> >>>> shouldn't be
> >>>> putting more code against this branch.
> >>>>
> >>>> Here's how I thought the process should have worked...  When we
> >>>> determined
> >>>> that we wanted to do the 1.0.0 release, we create the 1.0 branch
> >>>> like
> >>>> Patrick proposed a few notes back.  Off of this branch, Marc
> >>>> would create
> >>>> the 1.0.0 branch.  We've had a few RC's with fixes getting
> >>>> integrated into
> >>>> the 1.0.0 branch.  Eventually, we declared RC4 on the 1.0.0
> >>>> branch and
> >>>> hopefully this one will pass.  But, each time Marc proposed a
> >>>> 1.0.0 build
> >>>> for a vote, that branch was frozen and under his control as to
> >>>> what went in
> >>>> and what stayed out.  Since Marc didn't explicitly request
> >>>> Patrick's changes
> >>>> into the 1.0.0 branch (and thus force a respin), then Patrick's
> >>>> changes
> >>>> should not have been put into the 1.0.0 branch.  At a minimum,
> >>>> Patrick's
> >>>> changes should have been put into trunk and optionally into the
> >>>> 1.0 branch
> >>>> (in preparation for a 1.0.1 branch).  If we determine that an
> >>>> RC5 is
> >>>> required, then Marc may want Patrick's changes put into the
> >>>> 1.0.0 branch for
> >>>> a respin.  Then again, he may not want to introduce any more
> >>>> churn and only
> >>>> take the specific change that is forcing him to do a respin.
> >>>> (Note that I
> >>>> am only using Patrick's change as an example to discuss, not
> >>>> attempting to
> >>>> associate any type of complexity with it.)
> >>>>
> >>>> As an aside, trunk has become 1.1.0-SNAPSHOT until we determine
> >>>> we need a
> >>>> 1.1 branch.
> >>>>
> >>>> Granted, some of this discussion is with 20/20 hindsight.  But,
> >>>> we need to
> >>>> figure out our approach and be consistent from the start.  All
> >>>> of us have
> >>>> had various experiences with creating and maintaining branches and
> >>>> releases.  We just need to find a common ground for us to live
> >>>> with.
> >>>>
> >>>> Thanks,
> >>>> Kevin
> >>>>
> >>>> -Patrick
> >>>>>
> >>>>> On 8/26/07, Craig L Russell <Craig.Russell@sun.com> wrote:
> >>>>>>
> >>>>>> On Aug 26, 2007, at 5:51 PM, plinskey@gmail.com wrote:
> >>>>>>
> >>>>>>> Why? It seems like if the commiters are responsible about only
> >>>>>>> committing things that would belong on the maintenance branch
> >>>>>>> eventually anyways, then that's good enough.
> >>>>>>
> >>>>>> We're talking about a process here. The RM is trying to cut a
> >>>>>> release
> >>>>>> and if developers are continuing to check code into all
> >>>>>> possible code
> >>>>>> lines I smell disaster. IMHO the RM should be able to play in a
> >>>>>> stable sandbox.
> >>>>>>
> >>>>>> Let's play this out with specifics. Let's say that the 1.0
> >>>>>> branch is
> >>>>>> open to checkins while RM finalizes the release. At some point RM
> >>>>>> tags 1.0.0 before building the release candidate. The 1.0 branch
> >>>>>> continues to have checkins that developers have decided belong in
> >>>>>> both trunk and maintenance. The vote fails. The RM merges the 1.0
> >>>>>> branch into the 1.0.0 tag, picking up the checked in bug fixes
> >>>>>> that
> >>>>>> developers thought would be good. Testing shows one of the bug
> >>>>>> fixes
> >>>>>> is bad and the release has to be respun.
> >>>>>>
> >>>>>> A better process would be to give the RM control over the 1.0
> >>>>>> branch.
> >>>>>> Nothing gets checked in unless RM approves it. RCs are cut
> >>>>>> from the
> >>>>>> living end of 1.0 branch and voted on. At some point the vote
> >>>>>> succeeds and tag 1.0.0 is created. The 1.0 branch is opened
> >>>>>> again to
> >>>>>> developers, although I don't think many developers will bother
> >>>>>> checking anything into it. Once someone wants to make a
> >>>>>> maintenance
> >>>>>> release, RM goes through all the checkins from trunk to decide
> >>>>>> which
> >>>>>> can safely be applied to the maintenance release and merges
> >>>>>> those in.
> >>>>>>
> >>>>>> I'm still curious about why developers would bother checking code
> >>>>>> into both trunk and all the active maintenance branches. Do we
> >>>>>> want
> >>>>>> developers to concern themselves with all the branches that
> >>>>>> the fix
> >>>>>> applies to and run all their tests on each branch? Or do we
> >>>>>> have the
> >>>>>> RM responsible for a maintenance branch review the patches
> >>>>>> that they
> >>>>>> think are relevant?
> >>>>>>
> >>>>>> Craig
> >>>>>>
> >>>>>>> The benefit is that if
> >>>>>>> the release does need to be rebuilt, then the additional tweaks
> >>>>>>> automagically get picked up.
> >>>>>>>
> >>>>>>> Bear in mind that the RM can tag the revision used to make
> >>>>>>> the RC.
> >>>>>>>
> >>>>>>> -Patrick
> >>>>>>>
> >>>>>>> On 8/26/07, Craig L Russell <Craig.Russell@sun.com> wrote:
> >>>>>>>> Hi Kevin,
> >>>>>>>>
> >>>>>>>> On Aug 24, 2007, at 5: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?
> >>>>>>>>
> >>>>>>>> This is a problem. IMHO, the release manager should be the only
> >>>>>>>> person deciding what gets checked into a branch that is
> >>>>>>>> going to be
> >>>>>>>> released. If Marc ok'd the checkin after the release was
> >>>>>>>> voted, then
> >>>>>>>> he should be prepared to respin the release. If he didn't ok
> >>>>>>>> the
> >>>>>>>> checkin, then it should not have been checked in.
> >>>>>>>>
> >>>>>>>>> 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?
> >>>>>>>>
> >>>>>>>> How I think this should be managed is the release manager
> >>>>>>>> for 1.0.0
> >>>>>>>> should be approving all checkins into the branch. (Whether
> >>>>>>>> the branch
> >>>>>>>> is named 1.0.0 or 1.0 isn't relevant to this discussion).
> >>>>>>>> Once a VOTE
> >>>>>>>> is called, no further checkins should be allowed until the
> >>>>>>>> VOTE is
> >>>>>>>> complete or rescinded. If rescinded, other checkins can
> >>>>>>>> happen at the
> >>>>>>>> discretion of the release manager. Once complete, the branch
> >>>>>>>> should
> >>>>>>>> be tagged and the contents reset to be a SNAPSHOT of the
> >>>>>>>> next release
> >>>>>>>> on the branch. In this case, 1.0.1-SNAPSHOT.
> >>>>>>>>
> >>>>>>>> Craig
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Kevin
> >>>>>>>>>
> >>>>>>>>> On 8/24/07, pcl@apache.org <pcl@apache.org> 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
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>> Craig Russell
> >>>>>>>> Architect, Sun Java Enterprise System http://java.sun.com/
> >>>>>>>> products/
> >>>>>>>> jdo
> >>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
> >>>>>>>> P.S. A good JDO? O, Gasp!
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Patrick Linskey
> >>>>>>> 202 669 5907
> >>>>>>
> >>>>>> Craig Russell
> >>>>>> Architect, Sun Java Enterprise System http://java.sun.com/
> >>>>>> products/jdo
> >>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
> >>>>>> P.S. A good JDO? O, Gasp!
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> 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:Craig.Russell@sun.com
> >> P.S. A good JDO? O, Gasp!
> >>
> >
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>

------=_Part_129209_2504543.1188304671379--