openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@gmail.com>
Subject Re: svn commit: r569253 - in /openjpa/branches/1.0.0/openjpa-kernel/src/main: java/org/apache/openjpa/enhance/PCEnhancer.java resources/org/apache/openjpa/enhance/localizer.properties
Date Fri, 24 Aug 2007 20:17:27 GMT
> 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 <mprudhom@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 <mprudhom@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 <mprudhom@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 <michael.d.dick@gmail.com> wrote:
> >>>>>> On 8/24/07, Patrick Linskey <plinskey@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 <mprudhom@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 <pcl@apache.org>
wrote:
> >>>>>>>>>>
> >>>>>>>>>> Author: pcl
> >>>>>>>>>> Date: Thu Aug 23 22:27:43 2007
> >>>>>>>>>> New Revision: 569253
> >>>>>>>>>>
> >>>>>>>>>> URL: http://svn.apache.org/viewvc?rev=569253&view=rev
> >>>>>>>>>> Log:
> >>>>>>>>>> Minor logging / exception handling improvements
> >>>>>>>>>>
> >>>>>>>>>> Modified:
> >>>>>>>>>>
> >>>>>>>>>>     openjpa/branches/1.0.0/openjpa-kernel/src/main/java/org/
> >>>>>>>>>> apache/
> >>>>>>>>>> openjpa/enhance/PCEnhancer.java
> >>>>>>>>>>     openjpa/branches/1.0.0/openjpa-kernel/src/main/resources/
> >>>>>>>>>> org/
> >>>>>>>>>> apache/openjpa/enhance/localizer.properties
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Modified:
> >>>>>>>>>> openjpa/branches/1.0.0/openjpa-kernel/src/main/java/org/
> >>>>>>>>>> apache/
> >>>>>>>>>> openjpa/enhance/PCEnhancer.java
> >>>>>>>>>> URL:
> >>>>>>>>>> http://svn.apache.org/viewvc/openjpa/branches/1.0.0/openjpa-
> >>>>>>>>>> kernel/
> >>>>>>>>>> src/main/java/org/apache/openjpa/enhance/PCEnhancer.java?
> >>>>>>>>>> rev=569253&r1=569252&r2=569253&view=diff
> >>>>>>>>>> =============================================================
> >>>>>>>>>> ==
> >>>>>>>>>> ==
> >>>>>>>>>> ====
> >>>>>>>>>> =========
> >>>>>>>>>>
> >>>>>>>>>> ---
> >>>>>>>>>> openjpa/branches/1.0.0/openjpa-kernel/src/main/java/org/
> >>>>>>>>>> apache/
> >>>>>>>>>> openjpa/enhance/PCEnhancer.java
> >>>>>>>>>> (original)
> >>>>>>>>>> +++
> >>>>>>>>>> openjpa/branches/1.0.0/openjpa-kernel/src/main/java/org/
> >>>>>>>>>> apache/
> >>>>>>>>>> openjpa/enhance/PCEnhancer.java
> >>>>>>>>>> Thu Aug 23 22:27:43 2007
> >>>>>>>>>> @@ -467,7 +467,8 @@
> >>>>>>>>>>          } catch (OpenJPAException ke) {
> >>>>>>>>>>              throw ke;
> >>>>>>>>>>          } catch (Exception e) {
> >>>>>>>>>> -            throw new GeneralException(e);
> >>>>>>>>>> +            throw new GeneralException(_loc.get("enhance-
> >>>>>>>>>> error",
> >>>>>>>>>> +                _managedType.getType().getName(),
> >>>>>>>>>> e.getMessage
> >>>>>>>>>> ()), e);
> >>>>>>>>>>          }
> >>>>>>>>>>      }
> >>>>>>>>>>
> >>>>>>>>>> @@ -2736,7 +2737,10 @@
> >>>>>>>>>>              } catch (Throwable t) {
> >>>>>>>>>>                  // last-chance catch for bug
#283 (which can
> >>>>>>>>>> happen
> >>>>>>>>>>                  // in a variety of ClassLoading
> >>>>>>>>>> environments)
> >>>>>>>>>> -                _log.warn(_loc.get("enhance-uid-access",
> >>>>>>>>>> _meta), t);
> >>>>>>>>>> +                if (_log.isTraceEnabled())
> >>>>>>>>>> +                    _log.warn(_loc.get("enhance-uid-access",
> >>>>>>>>>> _meta), t);
> >>>>>>>>>> +                else
> >>>>>>>>>> +                    _log.warn(_loc.get("enhance-uid-access",
> >>>>>>>>>> _meta));
> >>>>>>>>>>              }
> >>>>>>>>>>
> >>>>>>>>>>              // if we couldn't access the
> >>>>>>>>>> serialVersionUID, we
> >>>>>>>>>> will have
> >>>>>>>>>> to
> >>>>>>>>>> @@ -3672,10 +3676,13 @@
> >>>>>>>>>>       * attribute name for the backing field
<code>name</
> >>>>>>>>>> code>.
> >>>>>>>>>>       */
> >>>>>>>>>>      private String fromBackingFieldName(String
name) {
> >>>>>>>>>> -        if (_meta.getAccessType() ==
> >>>>>>>>>> ClassMetaData.ACCESS_PROPERTY
> >>>>>>>>>> +        // meta is null when doing persistence-aware
> >>>>>>>>>> enhancement
> >>>>>>>>>> +        if (_meta != null
> >>>>>>>>>> +            && _meta.getAccessType()
==
> >>>>>>>>>> ClassMetaData.ACCESS_PROPERTY
> >>>>>>>>>>              && _fieldsToAttrs.containsKey(name))
> >>>>>>>>>> -            name = (String) _fieldsToAttrs.get(name);
> >>>>>>>>>> -        return name;
> >>>>>>>>>> +            return (String) _fieldsToAttrs.get(name);
> >>>>>>>>>> +        else
> >>>>>>>>>> +            return name;
> >>>>>>>>>>      }
> >>>>>>>>>>
> >>>>>>>>>>      /**
> >>>>>>>>>>
> >>>>>>>>>> Modified:
> >>>>>>>>>> openjpa/branches/1.0.0/openjpa-kernel/src/main/resources/org/
> >>>>>>>>>> apache/openjpa/enhance/localizer.properties
> >>>>>>>>>> URL:
> >>>>>>>>>> http://svn.apache.org/viewvc/openjpa/branches/1.0.0/openjpa-
> >>>>>>>>>> kernel/
> >>>>>>>>>> src/main/resources/org/apache/openjpa/enhance/
> >>>>>>>>>> localizer.properties?
> >>>>>>>>>> rev=569253&r1=569252&r2=569253&view=diff
> >>>>>>>>>> =============================================================
> >>>>>>>>>> ==
> >>>>>>>>>> ==
> >>>>>>>>>> ====
> >>>>>>>>>> =========
> >>>>>>>>>>
> >>>>>>>>>> ---
> >>>>>>>>>> openjpa/branches/1.0.0/openjpa-kernel/src/main/resources/org/
> >>>>>>>>>> apache/openjpa/enhance/localizer.properties
> >>>>>>>>>> (original)
> >>>>>>>>>> +++
> >>>>>>>>>> openjpa/branches/1.0.0/openjpa-kernel/src/main/resources/org/
> >>>>>>>>>> apache/openjpa/enhance/localizer.properties
> >>>>>>>>>> Thu Aug 23 22:27:43 2007
> >>>>>>>>>> @@ -197,4 +197,5 @@
> >>>>>>>>>> no-accessor: Could not find method called {0}
in type {1}.
> >>>>>>>>>> unspecified-unenhanced-types: One or more of
the types in {0}
> >>>>>>>>>> have
> >>>>>>>>>> relations \
> >>>>>>>>>>      to other unenhanced types that were not
specified. These
> >>>>>>>>>> unspecified
> >>>>>>>>>> types \
> >>>>>>>>>> -    are: {1}
> >>>>>>>>>> \ No newline at end of file
> >>>>>>>>>> +    are: {1}
> >>>>>>>>>> +enhance-error: An error occurred while enhancing
{0}.
> >>>>>>>>>> Exception
> >>>>>>>>>> message:
> >>>>>>>>>> {1}
> >>>>>>>>>> \ No newline at end of file
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> 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

Mime
View raw message