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 <[email protected]> > 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 <[email protected]> > > 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 <[email protected]> >> 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
