You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Aristedes Maniatis <ar...@maniatis.org> on 2010/02/18 23:33:25 UTC

Re: svn commit: r911476 - /cayenne/main/trunk/framework/cayenne-tools/src/main/resources/templates/v1_2/client-datamap-superclass.vm

We'll probably need something in the upgrade guide for 3.1 for this one. Many people will have copies of the templates inside their own project that will need modifying.

Also, remind me again, why are these templates marked as v1.2? Should we get rid of that versioning?

Ari


On 19/02/10 3:32 AM, andrey@apache.org wrote:
> Author: andrey
> Date: Thu Feb 18 16:32:52 2010
> New Revision: 911476
>
> URL: http://svn.apache.org/viewvc?rev=911476&view=rev
> Log:
> CAY-1393 Update velocity to 1.6.3. Fixing templates
>
> Modified:
>      cayenne/main/trunk/framework/cayenne-tools/src/main/resources/templates/v1_2/client-datamap-superclass.vm
>
> Modified: cayenne/main/trunk/framework/cayenne-tools/src/main/resources/templates/v1_2/client-datamap-superclass.vm
> URL: http://svn.apache.org/viewvc/cayenne/main/trunk/framework/cayenne-tools/src/main/resources/templates/v1_2/client-datamap-superclass.vm?rev=911476&r1=911475&r2=911476&view=diff
> ==============================================================================
> --- cayenne/main/trunk/framework/cayenne-tools/src/main/resources/templates/v1_2/client-datamap-superclass.vm (original)
> +++ cayenne/main/trunk/framework/cayenne-tools/src/main/resources/templates/v1_2/client-datamap-superclass.vm Thu Feb 18 16:32:52 2010
> @@ -32,8 +32,8 @@
>   ##    basePackageName
>   ##
>   ${importUtils.setPackage($superPackageName)}##
> -${importUtils.addReservedType("${superPackageName}.${superClassName}")}##
> -${importUtils.addType("${basePackageName}.${baseClassName}")}##
> +#if(${superPackageName})${importUtils.addReservedType("${superPackageName}.${superClassName}")}#end##
> +#if(${basePackageName})${importUtils.addType("${basePackageName}.${baseClassName}")}#end##
>   #if( ${object.hasSelectQueries()} )
>   ${importUtils.addType('java.util.List')}##
>   ${importUtils.addType('org.apache.cayenne.ObjectContext')}##
>
>

-- 
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Re: svn commit: r911476 - /cayenne/main/trunk/framework/cayenne-tools/src/main/resources/templates/v1_2/client-datamap-superclass.vm

Posted by Andrus Adamchik <an...@objectstyle.org>.
On Feb 19, 2010, at 4:43 PM, Mike Kienenberger wrote:

>  I also don't think we need to support cgen 1.1 anymore.

Yep, it is already removed in Cayenne 3.1

Andrus

Re: svn commit: r911476 - /cayenne/main/trunk/framework/cayenne-tools/src/main/resources/templates/v1_2/client-datamap-superclass.vm

Posted by Mike Kienenberger <mk...@gmail.com>.
Agreed.  While we do need a cgen version, we don't need it to be part
of the file names or the directory names.   It can be in the comments.
  I also don't think we need to support cgen 1.1 anymore.

On Fri, Feb 19, 2010 at 2:38 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> On Feb 19, 2010, at 9:25 AM, Andrey Razumovsky wrote:
>
>> If we really need to show cgen version, i'd rather we do it in templates'
>> comments (##this is template for use with cgen 1.2), not in directory
>> name.
>
> Keep in mind that we may have more than one template version in one distro
> simultaneously, just like we do in Cayenne 3.0 (although I wish we didn't).
>
> Until we face this situation again though, I have no problem if we get rid
> of the version folder.
>
> Andrus
>

Re: svn commit: r911476 - /cayenne/main/trunk/framework/cayenne-tools/src/main/resources/templates/v1_2/client-datamap-superclass.vm

Posted by Andrus Adamchik <an...@objectstyle.org>.
On Feb 19, 2010, at 9:25 AM, Andrey Razumovsky wrote:

> If we really need to show cgen version, i'd rather we do it in  
> templates'
> comments (##this is template for use with cgen 1.2), not in  
> directory name.

Keep in mind that we may have more than one template version in one  
distro simultaneously, just like we do in Cayenne 3.0 (although I wish  
we didn't).

Until we face this situation again though, I have no problem if we get  
rid of the version folder.

Andrus

Re: svn commit: r911476 - /cayenne/main/trunk/framework/cayenne-tools/src/main/resources/templates/v1_2/client-datamap-superclass.vm

Posted by Andrey Razumovsky <ra...@gmail.com>.
If we really need to show cgen version, i'd rather we do it in templates'
comments (##this is template for use with cgen 1.2), not in directory name.

2010/2/19 Andrey Razumovsky <ra...@gmail.com>

> About this commit:
> Again, I don't know how this worked before. There's no basePackageName
> defined for client datamap (and I think never should be - datamap generated
> class doesn't have a superclass. maybe we should remove that row?) so
> ImportUtils added something like ${basePackageName}.${baseClassName}. So
> maybe we should've fixed ImportUtils behavior, but I decided to do minor
> change for now.
> So, in spite of it is velocity upgrade that broke the builds, our templates
> are not perfect. Note that new templates (hopefully) will work with both
> versions of Velocity.
>
> About versions:
> I think that we don't need them. Who's using cgen 1.1 now [with Cayenne 3]?
> Also cgen is part of Cayenne, so I'd say we have cgen 3.1 right now.
>
> 2010/2/19 Mike Kienenberger <mk...@gmail.com>
>
> Yes, we need a cgen version, although it will probably change very
>> infrequently.
>>
>> No, it is not the same version as the templates.  Even though Andrey
>> had to change the templates, we do not have to change cgen itself.
>>
>> It's been a long time since I upgraded cgen from version 1.1 to 1.2,
>> but basically the version determines what cgen puts into the velocity
>> context.
>>
>> For cgen 1.1, I think the only thing we made available to the template
>> was a java class instance called "classGen".
>>
>> For 1.2, the exposed data model was completely changed.  Here's some
>> of the variables exposed to the template (from the 1.2 standard
>> template comments):
>>
>> ##    objEntity - the ObjEntity class: See
>> org.objectstyle.cayenne.map.ObjectEntity
>> ##    stringUtils - class for string "helper" functions: See
>> org.objectstyle.cayenne.gen.StringUtils
>> ##    entityUtils - class for entity "helper" functions: See
>> org.objectstyle.cayenne.gen.EntityUtils
>> ##    importUtils - class for import statement management: See
>> org.objectstyle.cayenne.gen.ImportUtils
>>
>> So a template written against 1.1 cannot work under 1.2, nor can a
>> template under 1.2 work under cgen 1.1.
>>
>> As for the confusion, if it hasn't confused anyone in several years,
>> it's unlikely to start confusing them just because we're now on 3.1 :)
>>
>> However, a cgen 1.1 template can work with Velocity 1.3 or 1.6 or
>> whatever.
>> A cgen 1.2 template can likewise work with different versions of velocity.
>>
>> So someone who has a ton of velocity templates (like myself) can be
>> assured that they don't need to be rewritten under Cayenne 3.1.   Yes,
>> we might have to tweak a couple of things here and there if we upgrade
>> to velocity 1.6, but anyone who's maintaining their own velocity
>> templates has pretty much been aware (for a few years now) that we
>> were going to have to handle this at one point or another.
>>
>> And quite honestly, I doubt that there's really anything stopping
>> someone from reverting back to Velocity 1.3 if they so desire.
>> There's nothing architecturally different that I'm aware of.  I
>> haven't looked at velocity changes in a couple of years, but I'm
>> pretty sure that velocity 1.6 is at least a couple of years old at
>> this point.
>>
>> On Thu, Feb 18, 2010 at 7:42 PM, Aristedes Maniatis <ar...@maniatis.org>
>> wrote:
>> > On 19/02/10 9:44 AM, Mike Kienenberger wrote:
>> >>
>> >> v1.2 is the cgen version.  It's fine and doesn't need to be changed.
>> >> We would only change that version if we did further work on the cgen
>> >> engine.
>> >
>> > End users will probably confuse 1.2 with the Cayenne 1.2 release version
>> > number.
>> >
>> > * why do we have a version at all? Surely the templates which ship with
>> > Cayenne 3.1 are the templates which work with 3.1. Should the user be
>> given
>> > the choice to use version 1.1 templates or 1.2 templates, when only the
>> 1.2
>> > templates will work.
>> >
>> > * Andrey just introduced a change which makes the templates non-backward
>> > compatible. So if we keep the versioning, we should move to 1.3 to
>> identify
>> > to the user that things have changed.
>> >
>> >
>> >
>> > Ari
>> >
>> > --
>> > -------------------------->
>> > Aristedes Maniatis
>> > GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>> >
>>
>
>
>
> --
> Andrey
>



-- 
Andrey

Re: svn commit: r911476 - /cayenne/main/trunk/framework/cayenne-tools/src/main/resources/templates/v1_2/client-datamap-superclass.vm

Posted by Andrey Razumovsky <ra...@gmail.com>.
About this commit:
Again, I don't know how this worked before. There's no basePackageName
defined for client datamap (and I think never should be - datamap generated
class doesn't have a superclass. maybe we should remove that row?) so
ImportUtils added something like ${basePackageName}.${baseClassName}. So
maybe we should've fixed ImportUtils behavior, but I decided to do minor
change for now.
So, in spite of it is velocity upgrade that broke the builds, our templates
are not perfect. Note that new templates (hopefully) will work with both
versions of Velocity.

About versions:
I think that we don't need them. Who's using cgen 1.1 now [with Cayenne 3]?
Also cgen is part of Cayenne, so I'd say we have cgen 3.1 right now.

2010/2/19 Mike Kienenberger <mk...@gmail.com>

> Yes, we need a cgen version, although it will probably change very
> infrequently.
>
> No, it is not the same version as the templates.  Even though Andrey
> had to change the templates, we do not have to change cgen itself.
>
> It's been a long time since I upgraded cgen from version 1.1 to 1.2,
> but basically the version determines what cgen puts into the velocity
> context.
>
> For cgen 1.1, I think the only thing we made available to the template
> was a java class instance called "classGen".
>
> For 1.2, the exposed data model was completely changed.  Here's some
> of the variables exposed to the template (from the 1.2 standard
> template comments):
>
> ##    objEntity - the ObjEntity class: See
> org.objectstyle.cayenne.map.ObjectEntity
> ##    stringUtils - class for string "helper" functions: See
> org.objectstyle.cayenne.gen.StringUtils
> ##    entityUtils - class for entity "helper" functions: See
> org.objectstyle.cayenne.gen.EntityUtils
> ##    importUtils - class for import statement management: See
> org.objectstyle.cayenne.gen.ImportUtils
>
> So a template written against 1.1 cannot work under 1.2, nor can a
> template under 1.2 work under cgen 1.1.
>
> As for the confusion, if it hasn't confused anyone in several years,
> it's unlikely to start confusing them just because we're now on 3.1 :)
>
> However, a cgen 1.1 template can work with Velocity 1.3 or 1.6 or whatever.
> A cgen 1.2 template can likewise work with different versions of velocity.
>
> So someone who has a ton of velocity templates (like myself) can be
> assured that they don't need to be rewritten under Cayenne 3.1.   Yes,
> we might have to tweak a couple of things here and there if we upgrade
> to velocity 1.6, but anyone who's maintaining their own velocity
> templates has pretty much been aware (for a few years now) that we
> were going to have to handle this at one point or another.
>
> And quite honestly, I doubt that there's really anything stopping
> someone from reverting back to Velocity 1.3 if they so desire.
> There's nothing architecturally different that I'm aware of.  I
> haven't looked at velocity changes in a couple of years, but I'm
> pretty sure that velocity 1.6 is at least a couple of years old at
> this point.
>
> On Thu, Feb 18, 2010 at 7:42 PM, Aristedes Maniatis <ar...@maniatis.org>
> wrote:
> > On 19/02/10 9:44 AM, Mike Kienenberger wrote:
> >>
> >> v1.2 is the cgen version.  It's fine and doesn't need to be changed.
> >> We would only change that version if we did further work on the cgen
> >> engine.
> >
> > End users will probably confuse 1.2 with the Cayenne 1.2 release version
> > number.
> >
> > * why do we have a version at all? Surely the templates which ship with
> > Cayenne 3.1 are the templates which work with 3.1. Should the user be
> given
> > the choice to use version 1.1 templates or 1.2 templates, when only the
> 1.2
> > templates will work.
> >
> > * Andrey just introduced a change which makes the templates non-backward
> > compatible. So if we keep the versioning, we should move to 1.3 to
> identify
> > to the user that things have changed.
> >
> >
> >
> > Ari
> >
> > --
> > -------------------------->
> > Aristedes Maniatis
> > GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
> >
>



-- 
Andrey

Re: svn commit: r911476 - /cayenne/main/trunk/framework/cayenne-tools/src/main/resources/templates/v1_2/client-datamap-superclass.vm

Posted by Mike Kienenberger <mk...@gmail.com>.
Yes, we need a cgen version, although it will probably change very infrequently.

No, it is not the same version as the templates.  Even though Andrey
had to change the templates, we do not have to change cgen itself.

It's been a long time since I upgraded cgen from version 1.1 to 1.2,
but basically the version determines what cgen puts into the velocity
context.

For cgen 1.1, I think the only thing we made available to the template
was a java class instance called "classGen".

For 1.2, the exposed data model was completely changed.  Here's some
of the variables exposed to the template (from the 1.2 standard
template comments):

##    objEntity - the ObjEntity class: See
org.objectstyle.cayenne.map.ObjectEntity
##    stringUtils - class for string "helper" functions: See
org.objectstyle.cayenne.gen.StringUtils
##    entityUtils - class for entity "helper" functions: See
org.objectstyle.cayenne.gen.EntityUtils
##    importUtils - class for import statement management: See
org.objectstyle.cayenne.gen.ImportUtils

So a template written against 1.1 cannot work under 1.2, nor can a
template under 1.2 work under cgen 1.1.

As for the confusion, if it hasn't confused anyone in several years,
it's unlikely to start confusing them just because we're now on 3.1 :)

However, a cgen 1.1 template can work with Velocity 1.3 or 1.6 or whatever.
A cgen 1.2 template can likewise work with different versions of velocity.

So someone who has a ton of velocity templates (like myself) can be
assured that they don't need to be rewritten under Cayenne 3.1.   Yes,
we might have to tweak a couple of things here and there if we upgrade
to velocity 1.6, but anyone who's maintaining their own velocity
templates has pretty much been aware (for a few years now) that we
were going to have to handle this at one point or another.

And quite honestly, I doubt that there's really anything stopping
someone from reverting back to Velocity 1.3 if they so desire.
There's nothing architecturally different that I'm aware of.  I
haven't looked at velocity changes in a couple of years, but I'm
pretty sure that velocity 1.6 is at least a couple of years old at
this point.

On Thu, Feb 18, 2010 at 7:42 PM, Aristedes Maniatis <ar...@maniatis.org> wrote:
> On 19/02/10 9:44 AM, Mike Kienenberger wrote:
>>
>> v1.2 is the cgen version.  It's fine and doesn't need to be changed.
>> We would only change that version if we did further work on the cgen
>> engine.
>
> End users will probably confuse 1.2 with the Cayenne 1.2 release version
> number.
>
> * why do we have a version at all? Surely the templates which ship with
> Cayenne 3.1 are the templates which work with 3.1. Should the user be given
> the choice to use version 1.1 templates or 1.2 templates, when only the 1.2
> templates will work.
>
> * Andrey just introduced a change which makes the templates non-backward
> compatible. So if we keep the versioning, we should move to 1.3 to identify
> to the user that things have changed.
>
>
>
> Ari
>
> --
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>

Re: svn commit: r911476 - /cayenne/main/trunk/framework/cayenne-tools/src/main/resources/templates/v1_2/client-datamap-superclass.vm

Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 19/02/10 9:44 AM, Mike Kienenberger wrote:
> v1.2 is the cgen version.  It's fine and doesn't need to be changed.
> We would only change that version if we did further work on the cgen
> engine.

End users will probably confuse 1.2 with the Cayenne 1.2 release version number.

* why do we have a version at all? Surely the templates which ship with Cayenne 3.1 are the templates which work with 3.1. Should the user be given the choice to use version 1.1 templates or 1.2 templates, when only the 1.2 templates will work.

* Andrey just introduced a change which makes the templates non-backward compatible. So if we keep the versioning, we should move to 1.3 to identify to the user that things have changed.



Ari

-- 
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Re: svn commit: r911476 - /cayenne/main/trunk/framework/cayenne-tools/src/main/resources/templates/v1_2/client-datamap-superclass.vm

Posted by Mike Kienenberger <mk...@gmail.com>.
v1.2 is the cgen version.  It's fine and doesn't need to be changed.
We would only change that version if we did further work on the cgen
engine.

You're definitely going to be wanting to add something in the upgrade guide.

Even if end-users don't have to change their cayenne cgen templates,
they may have other velocity templates that need to be changed.

For instance, my Cayenne project in maintenance uses velocity for
custom Cayenne templates, email templates, and web page templates.
Upgrading velocity would force upgrading everything else.   I think
3.1 is a fine place to force an upgrade.


On Thu, Feb 18, 2010 at 5:33 PM, Aristedes Maniatis <ar...@maniatis.org> wrote:
> We'll probably need something in the upgrade guide for 3.1 for this one.
> Many people will have copies of the templates inside their own project that
> will need modifying.
>
> Also, remind me again, why are these templates marked as v1.2? Should we get
> rid of that versioning?
>
> Ari
>
>
> On 19/02/10 3:32 AM, andrey@apache.org wrote:
>>
>> Author: andrey
>> Date: Thu Feb 18 16:32:52 2010
>> New Revision: 911476
>>
>> URL: http://svn.apache.org/viewvc?rev=911476&view=rev
>> Log:
>> CAY-1393 Update velocity to 1.6.3. Fixing templates
>>
>> Modified:
>>
>> cayenne/main/trunk/framework/cayenne-tools/src/main/resources/templates/v1_2/client-datamap-superclass.vm
>>
>> Modified:
>> cayenne/main/trunk/framework/cayenne-tools/src/main/resources/templates/v1_2/client-datamap-superclass.vm
>> URL:
>> http://svn.apache.org/viewvc/cayenne/main/trunk/framework/cayenne-tools/src/main/resources/templates/v1_2/client-datamap-superclass.vm?rev=911476&r1=911475&r2=911476&view=diff
>>
>> ==============================================================================
>> ---
>> cayenne/main/trunk/framework/cayenne-tools/src/main/resources/templates/v1_2/client-datamap-superclass.vm
>> (original)
>> +++
>> cayenne/main/trunk/framework/cayenne-tools/src/main/resources/templates/v1_2/client-datamap-superclass.vm
>> Thu Feb 18 16:32:52 2010
>> @@ -32,8 +32,8 @@
>>  ##    basePackageName
>>  ##
>>  ${importUtils.setPackage($superPackageName)}##
>> -${importUtils.addReservedType("${superPackageName}.${superClassName}")}##
>> -${importUtils.addType("${basePackageName}.${baseClassName}")}##
>>
>> +#if(${superPackageName})${importUtils.addReservedType("${superPackageName}.${superClassName}")}#end##
>>
>> +#if(${basePackageName})${importUtils.addType("${basePackageName}.${baseClassName}")}#end##
>>  #if( ${object.hasSelectQueries()} )
>>  ${importUtils.addType('java.util.List')}##
>>  ${importUtils.addType('org.apache.cayenne.ObjectContext')}##
>>
>>
>
> --
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>