You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Kevin Sutter <kw...@gmail.com> on 2007/08/24 14:37:06 UTC
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
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, pcl@apache.org <pc...@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
>
>
>
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
Posted by Marc Prud'hommeaux <mp...@apache.org>.
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 <mp...@apache.org> 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, pcl@apache.org <pc...@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
>>>>
>>>>
>>>>
>>
>>
>
>
> --
> Patrick Linskey
> 202 669 5907
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
Posted by Craig L Russell <Cr...@Sun.COM>.
On Aug 24, 2007, at 11:40 AM, Marc Prud'hommeaux wrote:
>
> On Aug 24, 2007, at 1:11 PM, 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.
>
> OK, that makes sense. I merely bring it up to point out that the
> scope of my branching activity was only ever designed to cover the
> current 1.0.0 release.
>
>
>>> 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.
>
> The issue of whether to have a short-term release-specific branch
> is, in fact, completely orthogonal to the issue of having long-term
> branches with release-targeted bugfixes and features.
>
> Nor is it pathological or in any way specific to OpenJPA version
> 1.0.0. One of the numerous reasons why we should have a release-
> specific branch is that we need a place where we commit the non "-
> SNAPSHOT" version number to the pom.xmls. If we were to do this on
> the trunk or on a long-term branch, then TeamCity or Continuum or
> some other CI system that is running off those branches will create
> release artifacts with the final "1.0.0" release number, a
> situation we want to avoid. This is one of the issues we discussed
> when Craig suggested this release branch strategy back in November
> (see http://mail-archives.apache.org/mod_mbox/openjpa-dev/
> 200611.mbox/%3c442CEE81-07D6-4067-9C74-96ADAD48FE82@SUN.com%3e ).
>
>
>>> 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.
>
> It almost sounds like you think I am intending to manually re-
> create the contents of the branch somewhere else, which isn't the
> case. I just intend to merge the "1.0.0" branch contents into
> either "trunk" to the potential "1.0" branch we've discussed. I
> simply don't understand why you think this is a Bad Idea. Maybe if
> you posted some concrete examples of the specific pitfalls you
> predict, then we would be able to better understand your objections.
>
>
>>> 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.
>>
>>> 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.
>
> I will do this once the release is approved and published.
>
>> 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.
>
> I will do that (probably before #1, since one or two things have
> been already committed to the 1.0.0 branch after the latest
> artifact was uploaded for voting).
>
>> 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.
>>
>> 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.
>
> The source isolation we lose is that if we have a "1.0" branch from
> which we directly cut release 1.0.0, and during the release process
> Developer A commits a typo fix to LICENSE.txt they want in 1.0.0,
> and Developer B fixes a semi-tested bugfix they don't want until
> 1.0.1, then we don't have any way of differentiating or segregating
> those different types of changes. Note that this is not just a
> hypothetical concern: this actually was an issue in past releases
> on OpenJPA.
>
> In conclusion, the crux of the disagreement seems simply to be: do
> we want a transient release-specific branch or not. I think we do,
> for the reasons listed above. You appear to deem it sufficient to
> have only a long-lived parent branch from which we directly cut the
> release. It's a fairly minor issue, but one I expect we will want
> to discuss more and vote on before the the next release.
I think the difference we're discussing is:
1. Make a 1.0 branch and when it's ready, mark (tag) the bits that
were approved. This means that the version number in the branch is
1.0.0 during the final days of the release, and after release we
update the version number to be 1.0.1-SNAPSHOT.
2. Make a 1.0.0 branch and when it is ready, agree that it's read-
only and copy the contents to 1.0 and update the version number
inside the branch to 1.0.1-SNAPSHOT.
Question: What do we do when it's time to cut the 1.0.1 release? I've
been assuming we'd be committing patches to the trunk and the 1.0.1
release manager will merge from trunk to 1.0 branch during the 1.0.1
release process. But the details of when to change the version number
from 1.0.1-SNAPSHOT to 1.0.1 needs to be documented, and it might be
clearer from that documentation how to continue.
I don't know of the specific case you're referring to where
> "Developer A commits a typo fix to LICENSE.txt they want in 1.0.0,
> and Developer B fixes a semi-tested bugfix they don't want until
> 1.0.1."
This needs further discussion. Is this something we want to
encourage? It implies that there are three active development code
bases: 1.0.0, 1.0.1, and trunk.
It might be well to try to update the release process soon.
Craig
>
>
>
>> -Patrick
>>
>> On 8/24/07, Marc Prud'hommeaux <mp...@apache.org> 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
>>>> creating another branch with allegedly-identical contents sounds
>>>> error
>>>> prone and cumbersome.
>>>>
>>>> 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
>>>> 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
>>>> release, we then do not need to create one of these release
>>>> branches,
>>>> 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
>>>> well-suited for a single-branch methodology. That worked well
>>>> while we
>>>> 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 <mi...@gmail.com> wrote:
>>>>> On 8/24/07, Patrick Linskey <pl...@gmail.com> 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.
>>>>>
>>>>>
>>>>> +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 <mp...@apache.org> 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, pcl@apache.org <pc...@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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
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
Posted by Patrick Linskey <pl...@gmail.com>.
> I only had intended to merge back to trunk because that is the only
> other branch we currently have.
... hence this discussion.
> If we had a "1.0" branch, then I'd merge onto that. Alternately, I
> can just rename the "1.0.0" branch to be "1.0" after the release is
> finalized and tagged. AFAIK, these two options would have an
> identical net effect, but it might be better to create a "1.0" branch
> now and merge the release branch "1.0.0" into it after the release
> because that is closer to my ideas for how we might handle the
> release-specific branches.
Personally, I think that they do have the same net effect, and just
renaming 1.0.0 to 1.0 seems like an easier option. I would have
started off the process by just creating a 1.0 branch in the first
place, so I guess it's not surprising that I'd go with just renaming.
-Patrick
On 8/24/07, Marc Prud'hommeaux <mp...@apache.org> wrote:
>
> > This is the first time that you have mentioned merging the 1.0.0
> > branch contents anywhere other than trunk. That is a good thing. I
> > believe that the extra branching is unnecessarily complex, but am
> > perfectly happy with a situation where the x.y.0 branch ends up
> > becoming the x.y branch post-release.
>
> I only had intended to merge back to trunk because that is the only
> other branch we currently have.
>
> If we had a "1.0" branch, then I'd merge onto that. Alternately, I
> can just rename the "1.0.0" branch to be "1.0" after the release is
> finalized and tagged. AFAIK, these two options would have an
> identical net effect, but it might be better to create a "1.0" branch
> now and merge the release branch "1.0.0" into it after the release
> because that is closer to my ideas for how we might handle the
> release-specific branches.
>
>
>
> On Aug 24, 2007, at 3:35 PM, Patrick Linskey wrote:
>
> >> The source isolation we lose is that if we have a "1.0" branch from
> >> which we directly cut release 1.0.0, and during the release process
> >> Developer A commits a typo fix to LICENSE.txt they want in 1.0.0, and
> >> Developer B fixes a semi-tested bugfix they don't want until 1.0.1,
> >> then we don't have any way of differentiating or segregating those
> >> different types of changes. Note that this is not just a hypothetical
> >> concern: this actually was an issue in past releases on OpenJPA.
> >
> > IIRC, this only happened in the past because we had a single line of
> > development. So sure, while cutting 0.9.6, changes that were targeted
> > for 0.9.7 were happening at the same time. But now that we will have a
> > release branch that is separate from trunk, I think that it is much
> > less likely for us to run into those situations. In fact, I think that
> > I would argue that it is usually undesirable to release a patch
> > release while another fix targeted at the same minor release is
> > halfway-implemented, as you've described.
> >
> >> It almost sounds like you think I am intending to manually re-create
> >> the contents of the branch somewhere else, which isn't the case. I
> >> just intend to merge the "1.0.0" branch contents into either "trunk"
> >> to the potential "1.0" branch we've discussed. I simply don't
> >
> > This is the first time that you have mentioned merging the 1.0.0
> > branch contents anywhere other than trunk. That is a good thing. I
> > believe that the extra branching is unnecessarily complex, but am
> > perfectly happy with a situation where the x.y.0 branch ends up
> > becoming the x.y branch post-release.
> >
> > -Patrick
> >
> > On 8/24/07, Marc Prud'hommeaux <mp...@apache.org> wrote:
> >>
> >> On Aug 24, 2007, at 1:11 PM, 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.
> >>
> >> OK, that makes sense. I merely bring it up to point out that the
> >> scope of my branching activity was only ever designed to cover the
> >> current 1.0.0 release.
> >>
> >>
> >>>> 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.
> >>
> >> The issue of whether to have a short-term release-specific branch is,
> >> in fact, completely orthogonal to the issue of having long-term
> >> branches with release-targeted bugfixes and features.
> >>
> >> Nor is it pathological or in any way specific to OpenJPA version
> >> 1.0.0. One of the numerous reasons why we should have a release-
> >> specific branch is that we need a place where we commit the non "-
> >> SNAPSHOT" version number to the pom.xmls. If we were to do this on
> >> the trunk or on a long-term branch, then TeamCity or Continuum or
> >> some other CI system that is running off those branches will create
> >> release artifacts with the final "1.0.0" release number, a situation
> >> we want to avoid. This is one of the issues we discussed when Craig
> >> suggested this release branch strategy back in November (see http://
> >> mail-archives.apache.org/mod_mbox/openjpa-dev/200611.mbox/%
> >> 3c442CEE81-07D6-4067-9C74-96ADAD48FE82@SUN.com%3e ).
> >>
> >>
> >>>> 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.
> >>
> >> It almost sounds like you think I am intending to manually re-create
> >> the contents of the branch somewhere else, which isn't the case. I
> >> just intend to merge the "1.0.0" branch contents into either "trunk"
> >> to the potential "1.0" branch we've discussed. I simply don't
> >> understand why you think this is a Bad Idea. Maybe if you posted some
> >> concrete examples of the specific pitfalls you predict, then we would
> >> be able to better understand your objections.
> >>
> >>
> >>>> 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.
> >>>
> >>>> 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.
> >>
> >> I will do this once the release is approved and published.
> >>
> >>> 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.
> >>
> >> I will do that (probably before #1, since one or two things have been
> >> already committed to the 1.0.0 branch after the latest artifact was
> >> uploaded for voting).
> >>
> >>> 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.
> >>>
> >>> 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.
> >>
> >> The source isolation we lose is that if we have a "1.0" branch from
> >> which we directly cut release 1.0.0, and during the release process
> >> Developer A commits a typo fix to LICENSE.txt they want in 1.0.0, and
> >> Developer B fixes a semi-tested bugfix they don't want until 1.0.1,
> >> then we don't have any way of differentiating or segregating those
> >> different types of changes. Note that this is not just a hypothetical
> >> concern: this actually was an issue in past releases on OpenJPA.
> >>
> >> In conclusion, the crux of the disagreement seems simply to be: do we
> >> want a transient release-specific branch or not. I think we do, for
> >> the reasons listed above. You appear to deem it sufficient to have
> >> only a long-lived parent branch from which we directly cut the
> >> release. It's a fairly minor issue, but one I expect we will want to
> >> discuss more and vote on before the the next release.
> >>
> >>
> >>
> >>> -Patrick
> >>>
> >>> On 8/24/07, Marc Prud'hommeaux <mp...@apache.org> 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
> >>>>> creating another branch with allegedly-identical contents sounds
> >>>>> error
> >>>>> prone and cumbersome.
> >>>>>
> >>>>> 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
> >>>>> 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
> >>>>> release, we then do not need to create one of these release
> >>>>> branches,
> >>>>> 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
> >>>>> well-suited for a single-branch methodology. That worked well
> >>>>> while we
> >>>>> 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 <mi...@gmail.com> wrote:
> >>>>>> On 8/24/07, Patrick Linskey <pl...@gmail.com> 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.
> >>>>>>
> >>>>>>
> >>>>>> +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 <mp...@apache.org> 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, pcl@apache.org <pc...@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
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Patrick Linskey
> >>>>>>> 202 669 5907
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Patrick Linskey
> >>>>> 202 669 5907
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Patrick Linskey
> >>> 202 669 5907
> >>
> >>
> >
> >
> > --
> > Patrick Linskey
> > 202 669 5907
>
>
--
Patrick Linskey
202 669 5907
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
Posted by Marc Prud'hommeaux <mp...@apache.org>.
> This is the first time that you have mentioned merging the 1.0.0
> branch contents anywhere other than trunk. That is a good thing. I
> believe that the extra branching is unnecessarily complex, but am
> perfectly happy with a situation where the x.y.0 branch ends up
> becoming the x.y branch post-release.
I only had intended to merge back to trunk because that is the only
other branch we currently have.
If we had a "1.0" branch, then I'd merge onto that. Alternately, I
can just rename the "1.0.0" branch to be "1.0" after the release is
finalized and tagged. AFAIK, these two options would have an
identical net effect, but it might be better to create a "1.0" branch
now and merge the release branch "1.0.0" into it after the release
because that is closer to my ideas for how we might handle the
release-specific branches.
On Aug 24, 2007, at 3:35 PM, Patrick Linskey wrote:
>> The source isolation we lose is that if we have a "1.0" branch from
>> which we directly cut release 1.0.0, and during the release process
>> Developer A commits a typo fix to LICENSE.txt they want in 1.0.0, and
>> Developer B fixes a semi-tested bugfix they don't want until 1.0.1,
>> then we don't have any way of differentiating or segregating those
>> different types of changes. Note that this is not just a hypothetical
>> concern: this actually was an issue in past releases on OpenJPA.
>
> IIRC, this only happened in the past because we had a single line of
> development. So sure, while cutting 0.9.6, changes that were targeted
> for 0.9.7 were happening at the same time. But now that we will have a
> release branch that is separate from trunk, I think that it is much
> less likely for us to run into those situations. In fact, I think that
> I would argue that it is usually undesirable to release a patch
> release while another fix targeted at the same minor release is
> halfway-implemented, as you've described.
>
>> It almost sounds like you think I am intending to manually re-create
>> the contents of the branch somewhere else, which isn't the case. I
>> just intend to merge the "1.0.0" branch contents into either "trunk"
>> to the potential "1.0" branch we've discussed. I simply don't
>
> This is the first time that you have mentioned merging the 1.0.0
> branch contents anywhere other than trunk. That is a good thing. I
> believe that the extra branching is unnecessarily complex, but am
> perfectly happy with a situation where the x.y.0 branch ends up
> becoming the x.y branch post-release.
>
> -Patrick
>
> On 8/24/07, Marc Prud'hommeaux <mp...@apache.org> wrote:
>>
>> On Aug 24, 2007, at 1:11 PM, 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.
>>
>> OK, that makes sense. I merely bring it up to point out that the
>> scope of my branching activity was only ever designed to cover the
>> current 1.0.0 release.
>>
>>
>>>> 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.
>>
>> The issue of whether to have a short-term release-specific branch is,
>> in fact, completely orthogonal to the issue of having long-term
>> branches with release-targeted bugfixes and features.
>>
>> Nor is it pathological or in any way specific to OpenJPA version
>> 1.0.0. One of the numerous reasons why we should have a release-
>> specific branch is that we need a place where we commit the non "-
>> SNAPSHOT" version number to the pom.xmls. If we were to do this on
>> the trunk or on a long-term branch, then TeamCity or Continuum or
>> some other CI system that is running off those branches will create
>> release artifacts with the final "1.0.0" release number, a situation
>> we want to avoid. This is one of the issues we discussed when Craig
>> suggested this release branch strategy back in November (see http://
>> mail-archives.apache.org/mod_mbox/openjpa-dev/200611.mbox/%
>> 3c442CEE81-07D6-4067-9C74-96ADAD48FE82@SUN.com%3e ).
>>
>>
>>>> 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.
>>
>> It almost sounds like you think I am intending to manually re-create
>> the contents of the branch somewhere else, which isn't the case. I
>> just intend to merge the "1.0.0" branch contents into either "trunk"
>> to the potential "1.0" branch we've discussed. I simply don't
>> understand why you think this is a Bad Idea. Maybe if you posted some
>> concrete examples of the specific pitfalls you predict, then we would
>> be able to better understand your objections.
>>
>>
>>>> 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.
>>>
>>>> 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.
>>
>> I will do this once the release is approved and published.
>>
>>> 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.
>>
>> I will do that (probably before #1, since one or two things have been
>> already committed to the 1.0.0 branch after the latest artifact was
>> uploaded for voting).
>>
>>> 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.
>>>
>>> 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.
>>
>> The source isolation we lose is that if we have a "1.0" branch from
>> which we directly cut release 1.0.0, and during the release process
>> Developer A commits a typo fix to LICENSE.txt they want in 1.0.0, and
>> Developer B fixes a semi-tested bugfix they don't want until 1.0.1,
>> then we don't have any way of differentiating or segregating those
>> different types of changes. Note that this is not just a hypothetical
>> concern: this actually was an issue in past releases on OpenJPA.
>>
>> In conclusion, the crux of the disagreement seems simply to be: do we
>> want a transient release-specific branch or not. I think we do, for
>> the reasons listed above. You appear to deem it sufficient to have
>> only a long-lived parent branch from which we directly cut the
>> release. It's a fairly minor issue, but one I expect we will want to
>> discuss more and vote on before the the next release.
>>
>>
>>
>>> -Patrick
>>>
>>> On 8/24/07, Marc Prud'hommeaux <mp...@apache.org> 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
>>>>> creating another branch with allegedly-identical contents sounds
>>>>> error
>>>>> prone and cumbersome.
>>>>>
>>>>> 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
>>>>> 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
>>>>> release, we then do not need to create one of these release
>>>>> branches,
>>>>> 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
>>>>> well-suited for a single-branch methodology. That worked well
>>>>> while we
>>>>> 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 <mi...@gmail.com> wrote:
>>>>>> On 8/24/07, Patrick Linskey <pl...@gmail.com> 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.
>>>>>>
>>>>>>
>>>>>> +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 <mp...@apache.org> 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, pcl@apache.org <pc...@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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Patrick Linskey
>>>>>>> 202 669 5907
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Patrick Linskey
>>>>> 202 669 5907
>>>>
>>>>
>>>
>>>
>>> --
>>> Patrick Linskey
>>> 202 669 5907
>>
>>
>
>
> --
> Patrick Linskey
> 202 669 5907
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
Posted by Patrick Linskey <pl...@gmail.com>.
> The source isolation we lose is that if we have a "1.0" branch from
> which we directly cut release 1.0.0, and during the release process
> Developer A commits a typo fix to LICENSE.txt they want in 1.0.0, and
> Developer B fixes a semi-tested bugfix they don't want until 1.0.1,
> then we don't have any way of differentiating or segregating those
> different types of changes. Note that this is not just a hypothetical
> concern: this actually was an issue in past releases on OpenJPA.
IIRC, this only happened in the past because we had a single line of
development. So sure, while cutting 0.9.6, changes that were targeted
for 0.9.7 were happening at the same time. But now that we will have a
release branch that is separate from trunk, I think that it is much
less likely for us to run into those situations. In fact, I think that
I would argue that it is usually undesirable to release a patch
release while another fix targeted at the same minor release is
halfway-implemented, as you've described.
> It almost sounds like you think I am intending to manually re-create
> the contents of the branch somewhere else, which isn't the case. I
> just intend to merge the "1.0.0" branch contents into either "trunk"
> to the potential "1.0" branch we've discussed. I simply don't
This is the first time that you have mentioned merging the 1.0.0
branch contents anywhere other than trunk. That is a good thing. I
believe that the extra branching is unnecessarily complex, but am
perfectly happy with a situation where the x.y.0 branch ends up
becoming the x.y branch post-release.
-Patrick
On 8/24/07, Marc Prud'hommeaux <mp...@apache.org> wrote:
>
> On Aug 24, 2007, at 1:11 PM, 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.
>
> OK, that makes sense. I merely bring it up to point out that the
> scope of my branching activity was only ever designed to cover the
> current 1.0.0 release.
>
>
> >> 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.
>
> The issue of whether to have a short-term release-specific branch is,
> in fact, completely orthogonal to the issue of having long-term
> branches with release-targeted bugfixes and features.
>
> Nor is it pathological or in any way specific to OpenJPA version
> 1.0.0. One of the numerous reasons why we should have a release-
> specific branch is that we need a place where we commit the non "-
> SNAPSHOT" version number to the pom.xmls. If we were to do this on
> the trunk or on a long-term branch, then TeamCity or Continuum or
> some other CI system that is running off those branches will create
> release artifacts with the final "1.0.0" release number, a situation
> we want to avoid. This is one of the issues we discussed when Craig
> suggested this release branch strategy back in November (see http://
> mail-archives.apache.org/mod_mbox/openjpa-dev/200611.mbox/%
> 3c442CEE81-07D6-4067-9C74-96ADAD48FE82@SUN.com%3e ).
>
>
> >> 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.
>
> It almost sounds like you think I am intending to manually re-create
> the contents of the branch somewhere else, which isn't the case. I
> just intend to merge the "1.0.0" branch contents into either "trunk"
> to the potential "1.0" branch we've discussed. I simply don't
> understand why you think this is a Bad Idea. Maybe if you posted some
> concrete examples of the specific pitfalls you predict, then we would
> be able to better understand your objections.
>
>
> >> 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.
> >
> >> 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.
>
> I will do this once the release is approved and published.
>
> > 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.
>
> I will do that (probably before #1, since one or two things have been
> already committed to the 1.0.0 branch after the latest artifact was
> uploaded for voting).
>
> > 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.
> >
> > 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.
>
> The source isolation we lose is that if we have a "1.0" branch from
> which we directly cut release 1.0.0, and during the release process
> Developer A commits a typo fix to LICENSE.txt they want in 1.0.0, and
> Developer B fixes a semi-tested bugfix they don't want until 1.0.1,
> then we don't have any way of differentiating or segregating those
> different types of changes. Note that this is not just a hypothetical
> concern: this actually was an issue in past releases on OpenJPA.
>
> In conclusion, the crux of the disagreement seems simply to be: do we
> want a transient release-specific branch or not. I think we do, for
> the reasons listed above. You appear to deem it sufficient to have
> only a long-lived parent branch from which we directly cut the
> release. It's a fairly minor issue, but one I expect we will want to
> discuss more and vote on before the the next release.
>
>
>
> > -Patrick
> >
> > On 8/24/07, Marc Prud'hommeaux <mp...@apache.org> 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
> >>> creating another branch with allegedly-identical contents sounds
> >>> error
> >>> prone and cumbersome.
> >>>
> >>> 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
> >>> 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
> >>> release, we then do not need to create one of these release
> >>> branches,
> >>> 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
> >>> well-suited for a single-branch methodology. That worked well
> >>> while we
> >>> 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 <mi...@gmail.com> wrote:
> >>>> On 8/24/07, Patrick Linskey <pl...@gmail.com> 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.
> >>>>
> >>>>
> >>>> +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 <mp...@apache.org> 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, pcl@apache.org <pc...@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
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Patrick Linskey
> >>>>> 202 669 5907
> >>>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Patrick Linskey
> >>> 202 669 5907
> >>
> >>
> >
> >
> > --
> > Patrick Linskey
> > 202 669 5907
>
>
--
Patrick Linskey
202 669 5907
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
Posted by Marc Prud'hommeaux <mp...@apache.org>.
On Aug 24, 2007, at 1:11 PM, 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.
OK, that makes sense. I merely bring it up to point out that the
scope of my branching activity was only ever designed to cover the
current 1.0.0 release.
>> 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.
The issue of whether to have a short-term release-specific branch is,
in fact, completely orthogonal to the issue of having long-term
branches with release-targeted bugfixes and features.
Nor is it pathological or in any way specific to OpenJPA version
1.0.0. One of the numerous reasons why we should have a release-
specific branch is that we need a place where we commit the non "-
SNAPSHOT" version number to the pom.xmls. If we were to do this on
the trunk or on a long-term branch, then TeamCity or Continuum or
some other CI system that is running off those branches will create
release artifacts with the final "1.0.0" release number, a situation
we want to avoid. This is one of the issues we discussed when Craig
suggested this release branch strategy back in November (see http://
mail-archives.apache.org/mod_mbox/openjpa-dev/200611.mbox/%
3c442CEE81-07D6-4067-9C74-96ADAD48FE82@SUN.com%3e ).
>> 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.
It almost sounds like you think I am intending to manually re-create
the contents of the branch somewhere else, which isn't the case. I
just intend to merge the "1.0.0" branch contents into either "trunk"
to the potential "1.0" branch we've discussed. I simply don't
understand why you think this is a Bad Idea. Maybe if you posted some
concrete examples of the specific pitfalls you predict, then we would
be able to better understand your objections.
>> 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.
>
>> 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.
I will do this once the release is approved and published.
> 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.
I will do that (probably before #1, since one or two things have been
already committed to the 1.0.0 branch after the latest artifact was
uploaded for voting).
> 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.
>
> 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.
The source isolation we lose is that if we have a "1.0" branch from
which we directly cut release 1.0.0, and during the release process
Developer A commits a typo fix to LICENSE.txt they want in 1.0.0, and
Developer B fixes a semi-tested bugfix they don't want until 1.0.1,
then we don't have any way of differentiating or segregating those
different types of changes. Note that this is not just a hypothetical
concern: this actually was an issue in past releases on OpenJPA.
In conclusion, the crux of the disagreement seems simply to be: do we
want a transient release-specific branch or not. I think we do, for
the reasons listed above. You appear to deem it sufficient to have
only a long-lived parent branch from which we directly cut the
release. It's a fairly minor issue, but one I expect we will want to
discuss more and vote on before the the next release.
> -Patrick
>
> On 8/24/07, Marc Prud'hommeaux <mp...@apache.org> 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
>>> creating another branch with allegedly-identical contents sounds
>>> error
>>> prone and cumbersome.
>>>
>>> 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
>>> 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
>>> release, we then do not need to create one of these release
>>> branches,
>>> 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
>>> well-suited for a single-branch methodology. That worked well
>>> while we
>>> 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 <mi...@gmail.com> wrote:
>>>> On 8/24/07, Patrick Linskey <pl...@gmail.com> 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.
>>>>
>>>>
>>>> +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 <mp...@apache.org> 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, pcl@apache.org <pc...@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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Patrick Linskey
>>>>> 202 669 5907
>>>>>
>>>>
>>>
>>>
>>> --
>>> Patrick Linskey
>>> 202 669 5907
>>
>>
>
>
> --
> Patrick Linskey
> 202 669 5907
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
Posted by Patrick Linskey <pl...@gmail.com>.
> Straw proposal: we never merge from any branch to the trunk.
The implication of this is that any fixes that are made on a branch
only need to be manually mirrored back down to trunk.
I'm ok with that, but I think that it is very important that we do
something to ensure that that happens. Otherwise, we'll have bugfixes
in branches but not in trunk.
Also, the rumor is that svn 2 will maintain merge history, which will
make inter-branch merging trivial, so we should be sure to remember
that any rules that we make to simplify our lives with svn 1 are not
written in stone.
-Patrick
On 8/24/07, Craig L Russell <Cr...@sun.com> wrote:
>
> On Aug 24, 2007, at 12:27 PM, Patrick Linskey wrote:
>
> >> 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 we should take a different approach: the people who want
> > particular fixes that were put into trunk should be responsible for
> > merging them into the 1.0 branch, and the release manager should be
> > responsible for merging any work that was done only in the 1.0 branch
> > back into trunk.
> >
> > Merging is a bit of a pain in svn currently, since we need to keep
> > track of when a merge was last made. We might want to write down some
> > procedures for the different types of merges that we expect and what
> > not to do. For example, I think that it's bad to "merge" from trunk to
> > 1.0 by just copying the changes from one branch to another, because
> > then svn will detect a conflict when merging back down.
>
> We should have a policy on merging that resolves this.
>
> Straw proposal: we never merge from any branch to the trunk.
>
> Craig
> >
> > -Patrick
> >
> > On 8/24/07, Craig L Russell <Cr...@sun.com> wrote:
> >>
> >> 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
> >>
> >> 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.
> >>
> >> Craig
> >>>
> >>> 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 <mp...@apache.org> 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
> >>>>> creating another branch with allegedly-identical contents sounds
> >>>>> error
> >>>>> prone and cumbersome.
> >>>>>
> >>>>> 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
> >>>>> 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
> >>>>> release, we then do not need to create one of these release
> >>>>> branches,
> >>>>> 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
> >>>>> well-suited for a single-branch methodology. That worked well
> >>>>> while we
> >>>>> 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 <mi...@gmail.com> wrote:
> >>>>>> On 8/24/07, Patrick Linskey <pl...@gmail.com> 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.
> >>>>>>
> >>>>>>
> >>>>>> +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 <mp...@apache.org> 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, pcl@apache.org <pc...@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
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> 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: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
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
Posted by Craig L Russell <Cr...@Sun.COM>.
On Aug 24, 2007, at 12:27 PM, Patrick Linskey wrote:
>> 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 we should take a different approach: the people who want
> particular fixes that were put into trunk should be responsible for
> merging them into the 1.0 branch, and the release manager should be
> responsible for merging any work that was done only in the 1.0 branch
> back into trunk.
>
> Merging is a bit of a pain in svn currently, since we need to keep
> track of when a merge was last made. We might want to write down some
> procedures for the different types of merges that we expect and what
> not to do. For example, I think that it's bad to "merge" from trunk to
> 1.0 by just copying the changes from one branch to another, because
> then svn will detect a conflict when merging back down.
We should have a policy on merging that resolves this.
Straw proposal: we never merge from any branch to the trunk.
Craig
>
> -Patrick
>
> On 8/24/07, Craig L Russell <Cr...@sun.com> wrote:
>>
>> 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
>>
>> 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.
>>
>> Craig
>>>
>>> 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 <mp...@apache.org> 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
>>>>> creating another branch with allegedly-identical contents sounds
>>>>> error
>>>>> prone and cumbersome.
>>>>>
>>>>> 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
>>>>> 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
>>>>> release, we then do not need to create one of these release
>>>>> branches,
>>>>> 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
>>>>> well-suited for a single-branch methodology. That worked well
>>>>> while we
>>>>> 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 <mi...@gmail.com> wrote:
>>>>>> On 8/24/07, Patrick Linskey <pl...@gmail.com> 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.
>>>>>>
>>>>>>
>>>>>> +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 <mp...@apache.org> 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, pcl@apache.org <pc...@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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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: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!
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
Posted by Patrick Linskey <pl...@gmail.com>.
> 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 we should take a different approach: the people who want
particular fixes that were put into trunk should be responsible for
merging them into the 1.0 branch, and the release manager should be
responsible for merging any work that was done only in the 1.0 branch
back into trunk.
Merging is a bit of a pain in svn currently, since we need to keep
track of when a merge was last made. We might want to write down some
procedures for the different types of merges that we expect and what
not to do. For example, I think that it's bad to "merge" from trunk to
1.0 by just copying the changes from one branch to another, because
then svn will detect a conflict when merging back down.
-Patrick
On 8/24/07, Craig L Russell <Cr...@sun.com> wrote:
>
> 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
>
> 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.
>
> Craig
> >
> > 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 <mp...@apache.org> 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
> >>> creating another branch with allegedly-identical contents sounds
> >>> error
> >>> prone and cumbersome.
> >>>
> >>> 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
> >>> 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
> >>> release, we then do not need to create one of these release
> >>> branches,
> >>> 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
> >>> well-suited for a single-branch methodology. That worked well
> >>> while we
> >>> 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 <mi...@gmail.com> wrote:
> >>>> On 8/24/07, Patrick Linskey <pl...@gmail.com> 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.
> >>>>
> >>>>
> >>>> +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 <mp...@apache.org> 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, pcl@apache.org <pc...@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
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> 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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>
--
Patrick Linskey
202 669 5907
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
Posted by Craig L Russell <Cr...@Sun.COM>.
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
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.
Craig
>
> 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 <mp...@apache.org> 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
>>> creating another branch with allegedly-identical contents sounds
>>> error
>>> prone and cumbersome.
>>>
>>> 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
>>> 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
>>> release, we then do not need to create one of these release
>>> branches,
>>> 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
>>> well-suited for a single-branch methodology. That worked well
>>> while we
>>> 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 <mi...@gmail.com> wrote:
>>>> On 8/24/07, Patrick Linskey <pl...@gmail.com> 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.
>>>>
>>>>
>>>> +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 <mp...@apache.org> 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, pcl@apache.org <pc...@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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
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
Posted by Patrick Linskey <pl...@gmail.com>.
> "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.
> 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.
> 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.
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.
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.
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 <mp...@apache.org> 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
> > creating another branch with allegedly-identical contents sounds error
> > prone and cumbersome.
> >
> > 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
> > 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
> > release, we then do not need to create one of these release branches,
> > 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
> > well-suited for a single-branch methodology. That worked well while we
> > 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 <mi...@gmail.com> wrote:
> >> On 8/24/07, Patrick Linskey <pl...@gmail.com> 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.
> >>
> >>
> >> +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 <mp...@apache.org> 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, pcl@apache.org <pc...@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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Patrick Linskey
> >>> 202 669 5907
> >>>
> >>
> >
> >
> > --
> > Patrick Linskey
> > 202 669 5907
>
>
--
Patrick Linskey
202 669 5907
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
Posted by Marc Prud'hommeaux <mp...@apache.org>.
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
> creating another branch with allegedly-identical contents sounds error
> prone and cumbersome.
>
> 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
> 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
> release, we then do not need to create one of these release branches,
> 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
> well-suited for a single-branch methodology. That worked well while we
> 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 <mi...@gmail.com> wrote:
>> On 8/24/07, Patrick Linskey <pl...@gmail.com> 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.
>>
>>
>> +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 <mp...@apache.org> 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, pcl@apache.org <pc...@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
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Patrick Linskey
>>> 202 669 5907
>>>
>>
>
>
> --
> Patrick Linskey
> 202 669 5907
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
Posted by Patrick Linskey <pl...@gmail.com>.
> 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
creating another branch with allegedly-identical contents sounds error
prone and cumbersome.
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
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
release, we then do not need to create one of these release branches,
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
well-suited for a single-branch methodology. That worked well while we
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 <mi...@gmail.com> wrote:
> On 8/24/07, Patrick Linskey <pl...@gmail.com> 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.
>
>
> +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 <mp...@apache.org> 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, pcl@apache.org <pc...@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
> > > >>
> > > >>
> > > >>
> > >
> > >
> >
> >
> > --
> > Patrick Linskey
> > 202 669 5907
> >
>
--
Patrick Linskey
202 669 5907
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
Posted by Michael Dick <mi...@gmail.com>.
On 8/24/07, Patrick Linskey <pl...@gmail.com> 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.
+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 <mp...@apache.org> 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, pcl@apache.org <pc...@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
> > >>
> > >>
> > >>
> >
> >
>
>
> --
> Patrick Linskey
> 202 669 5907
>
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
Posted by Patrick Linskey <pl...@gmail.com>.
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 <mp...@apache.org> 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, pcl@apache.org <pc...@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
> >>
> >>
> >>
>
>
--
Patrick Linskey
202 669 5907
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
Posted by Marc Prud'hommeaux <mp...@apache.org>.
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, pcl@apache.org <pc...@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
>>
>>
>>
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
Posted by Kevin Sutter <kw...@gmail.com>.
On 8/27/07, Craig L Russell <Cr...@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 <kw...@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 <pl...@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 <Cr...@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 <Cr...@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 <pc...@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!
>
>
>
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
Posted by Craig L Russell <Cr...@Sun.COM>.
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.
> 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.
>
>> [...] 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.
> 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.
>
>> 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. ;-)
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 <kw...@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 <pl...@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 <Cr...@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 <Cr...@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 <pc...@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!
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
Posted by Marc Prud'hommeaux <mp...@apache.org>.
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. 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.
> [...] 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). 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.
> 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 :)
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 <kw...@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 <pl...@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 <Cr...@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 <Cr...@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 <pc...@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!
>
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
Posted by Craig L Russell <Cr...@Sun.COM>.
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 <kw...@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 <pl...@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 <Cr...@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 <Cr...@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 <pc...@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!
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
Posted by Patrick Linskey <pl...@gmail.com>.
> 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. 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?
> 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. 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.
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, whereas I feel it's more
appropriate to design a system that is easy to handle in the happy
case. 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.
> 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
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. In any event, it is pretty critical that
the release branch contents make their way into the maintenance
branch, and not via trunk. 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.
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. 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. 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.
-Patrick
On 8/27/07, Kevin Sutter <kw...@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 <pl...@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 <Cr...@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 <Cr...@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 <pc...@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
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
Posted by Kevin Sutter <kw...@gmail.com>.
Patrick's premise of merging from the 1.0.0 branch back into trunk really
threw me...
On 8/26/07, Patrick Linskey <pl...@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 <Cr...@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 <Cr...@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 <pc...@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
>
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
Posted by Craig L Russell <Cr...@Sun.COM>.
On Aug 26, 2007, at 9:29 PM, Patrick Linskey wrote:
> In my opinion, I think we should let developers check things in
> wherever they want to.
I'm all for giving developers the freedom to scratch their itch, but
I believe this goes too far. If I am a release manager, I really
don't want to have to deal with a moving target. My idea of the role
of RM is to dictate what goes in and what stays out.
> I think that most development work should
> happen in trunk unless we have a reason for it to happen elsewhere.
Sure, and I'd formalize it more. Development happens in the trunk
unless the change you want to make doesn't belong in trunk. When does
that happen? When you're patching released code that has been
reorganized in the trunk so it doesn't apply any more.
> So, for example, if a developer has a fix that I think needs to be in
> a patch release, I think that it should be up to that developer to put
> the fix into the appropriate release branch.
This disempowers the RM. I'm much more comfortable with the RM
deciding whether a patch is worth the potential destabilization of
the release branch.
> We still haven't really
> discussed merging that much in that other thread; if we go with a
> model in which it is not the RM's responsibility to do a post-release
> merge to trunk, then we should require developers to put work into
> trunk as well as whatever release branch they deem fit, as
> appropriate.
There's already enough on the RM's plate to make a successful
release. I'd rather not burden RM with the responsibility of post-
release merge into the trunk that's already changed in the weeks
since the branch was cut.
>
> (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.)
Ok, bygones. "Someone" will need to merge these changes into trunk.
But why wait? The thing I'm missing is that a patch is so important
that it needs to go into the release branch immediately, but it's not
important enough to go into the trunk immediately.
So here's my proposal, using the current state of play.
Trunk is versioned 1.1.0-SNAPSHOT. Branch/1.0 is versioned 1.0.1-
SNAPSHOT. Tag/1.0.0 is versioned 1.0.0 and is frozen.
Developers commit changes to trunk, and if they feel like it, merge
or hand copy the changes to branch/1.0. Any branch that is touched is
tested to make sure the change doesn't break anything. Nothing goes
into tag/1.0.0.
A release manager is volunteered to make 1.0.1. No one is allowed to
commit to branch/1.0 without permission from RM. Branch/1.0 is
versioned 1.0.1 by RM. Release notes are updated in branch/1.0.
Testing occurs. Release candidates are produced. Votes are taken.
Vote passes. Tag/1.0.1 is created from the living end of branch/1.0.
Branch/1.0 is versioned 1.0.2-SNAPSHOT.
Repeat above until we decide to cut a 1.1. RM is volunteered. RM
creates branch/1.1 from trunk. Branch/1.1 is versioned 1.1.0 by RM.
Release notes, testing, release candidates, voting, success. Tag/
1.1.0 is created from the living end of branch/1.1. Branch/1.1 is
versioned 1.1.1-SNAPSHOT.
Life goes on.
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!
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
Posted by Patrick Linskey <pl...@gmail.com>.
In the case of this checkin, I checked it in based on some debugging
that I was doing into potential problems with the 1.0.0 release. So, I
was evaulating the 1.0.0 release, and made some minor fixes along the
way. (In this case, better error messages from the enhancer.)
I did not check these changes into trunk. I only checked them into
1.0.0, since I know that the 1.0.0 line will eventually be merged down
to trunk, and so checkins I make there will make their way to trunk in
their own good time.
This change was something that I believe we would want to put into
1.0.0 if we needed to respin, but is not something worth restarting
the 1.0.0 process for. So, I checked it into the branch that a
hypothetical next cut would come from; if we needed another, it would
get into the next build; if not, it would end up in both 1.0.1 (since
my checkin was on the 1.0.0 branch; assuming that we do an svn mv of
1.0.0 to 1.0.1) and trunk (when the 1.0.0 => trunk merge happens).
IOW, this was a hardening change for the 1.0.0 process, but one that
was too trivial to require a new release (in my opinion).
I think that your process does a good job of isolating the release
management procedure, but it would have made things more complex for
both Marc and I. I do not think that the isolation concern is a
problem that really needs to be solved. I think that to the extent
that we can informally make things work out properly, we should try to
use a more flexible process.
> 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?
In my opinion, I think we should let developers check things in
wherever they want to. I think that most development work should
happen in trunk unless we have a reason for it to happen elsewhere.
So, for example, if a developer has a fix that I think needs to be in
a patch release, I think that it should be up to that developer to put
the fix into the appropriate release branch. We still haven't really
discussed merging that much in that other thread; if we go with a
model in which it is not the RM's responsibility to do a post-release
merge to trunk, then we should require developers to put work into
trunk as well as whatever release branch they deem fit, as
appropriate.
(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.)
-Patrick
On 8/26/07, Craig L Russell <Cr...@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 <Cr...@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 <pc...@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
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
Posted by Craig L Russell <Cr...@Sun.COM>.
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 <Cr...@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 <pc...@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!
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
Posted by pl...@gmail.com.
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. 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 <Cr...@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 <pc...@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
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
Posted by Craig L Russell <Cr...@Sun.COM>.
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 <pc...@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!