You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Kevin Menard <ni...@gmail.com> on 2009/04/16 00:22:56 UTC

Moving SmartNamingStrategy out of modeler

I think this mainly targeted at Andrey, as he wrote SmartNamingStrategy.
What is entailed with moving this out of the modeler and into the core
framework?  I tried just moving the file, but there is a dependency on jvnet
for inflector purposes.  I'd rather not force the dependency on core
framework users, but I'd also like to be able to use the naming strategy
outside of the modeler.  Do you have any ideas on how to accomplish this?

The best I could could up with was:

- Add a dependency on the modeler from the plugin.  Not terrible for maven,
a little more so for ant.

- Add a soft dependency, whereby you only need that Jar on the classpath if
you're using that naming strategy.  We've done this for other classes in the
past.  It works, but can be a pain to maintain.

- Move naming strategies into their own module.  For maven the plugins and
modeler would have a dependency on this new module.  For ant, you'd need the
new JAR on the classpath.

- Find an alternative to the inflector lib.

- Do nothing.  SmartNamingStrategy is only available from modeler.

-- 
Thanks,
Kevin

Re: Moving SmartNamingStrategy out of modeler

Posted by Kevin Menard <ni...@gmail.com>.
On Fri, Apr 17, 2009 at 4:35 PM, Joseph Schmidt
<jo...@yahoo.com>wrote:
>
>
> A big advantage would be also the reduced size:
> cayenne-nodeps.jar(Cayenne2) was 400k, so everybody could see that it's
> much more lightweight than all other solutions. Now, cayenne-server.jar (in
> Cayenne3) is 2MB - quite a jump in size, and now similar to hibernate3.jar
> :(.
>


That's really a personal preference, I guess. I don't know of anyone that
really cares about the size of libraries any more.  What I'm more concerned
about is the usability factor.  I hate having a large mixmatch of JARs in
order to accomplish basic functionality.  Prior to maven, I always used the
fat Cayenne JAR just because I didn't want the headache of keeping track of
all the smaller ones.

-- 
Kevin

Re: Moving SmartNamingStrategy out of modeler

Posted by Joseph Schmidt <jo...@yahoo.com>.
> Maybe what we need is a CayenneTools jar that contains all of these
> non-essential tools that are not needed by the runtime, but are needed
> by the modeler and the ant tasks and the maven tasks.
+1
this sounds like the best idea.

There are many things in cayenne-server.jar that are not needed at 
runtime by most users. Those could go in a cayenne-tools.jar too.
Just a few I saw quickly in cayenne-server.jar:
/dotemplates
/org/apache/cayenne/tools
/org/apache/cayenne/gen (maybe a part of it?)
/?

A big advantage would be also the reduced size:
cayenne-nodeps.jar(Cayenne2) was 400k, so everybody could see that it's 
much more lightweight than all other solutions. Now, cayenne-server.jar 
(in Cayenne3) is 2MB - quite a jump in size, and now similar to 
hibernate3.jar :(.

thanks,
Joseph.


Re: Moving SmartNamingStrategy out of modeler

Posted by Mike Kienenberger <mk...@gmail.com>.
In the past, things like the cgen ant depended on the modeler jar.

Maybe what we need is a CayenneTools jar that contains all of these
non-essential tools that are not needed by the runtime, but are needed
by the modeler and the ant tasks and the maven tasks.


On Fri, Apr 17, 2009 at 3:37 PM, Kevin Menard <ni...@gmail.com> wrote:
> On Thu, Apr 16, 2009 at 1:24 AM, Andrey Razumovsky <
> razumovsky.andrey@gmail.com> wrote:
>
>>
>>
>> You mean to rewrite it from clean sheet? Inflector library is very small
>> and
>> event if we find an alternative, that will be a dependency either (?)
>>
>> It's also OK for me if we move the strategy to Cayenne core. Then we'll
>> need
>> compile dependency in core and "inclusive" - in modeler.
>>
>> So I suggest we either move it to core or create a separate module. But, if
>> latter,  I'm leaving the country today and won't be able to accomplish that
>> in nearest two weeks.
>>
>
>
> Does anyone have an opinion on this?  Dragging the class files directly into
> our assembly may be the easiest thing to do.  We've done this is the past
> for other libs such as JDOM.  Otherwise, I'll plan on adding a new module
> for naming strategies.  I just don't expect that module to grow a whole lot.
>
> --
> Kevin
>

Re: Moving SmartNamingStrategy out of modeler

Posted by Kevin Menard <ni...@gmail.com>.
Well, not my preference, but the ayes have it.  I'll look at adding a new
maven module for cayenne-tools (yay!)
-- 
Kevin


On Sat, Apr 18, 2009 at 4:20 AM, Andrus Adamchik <an...@objectstyle.org>wrote:

>
> On Apr 17, 2009, at 10:37 PM, Kevin Menard wrote:
>
>
>> Does anyone have an opinion on this?  Dragging the class files directly
>> into
>> our assembly may be the easiest thing to do.  We've done this is the past
>> for other libs such as JDOM.  Otherwise, I'll plan on adding a new module
>> for naming strategies.  I just don't expect that module to grow a whole
>> lot.
>>
>
> I am in favor of cayenne-tools idea.
>
> Andrus
>
>

Re: Moving SmartNamingStrategy out of modeler

Posted by Andrus Adamchik <an...@objectstyle.org>.
On Apr 17, 2009, at 10:37 PM, Kevin Menard wrote:

>
> Does anyone have an opinion on this?  Dragging the class files  
> directly into
> our assembly may be the easiest thing to do.  We've done this is the  
> past
> for other libs such as JDOM.  Otherwise, I'll plan on adding a new  
> module
> for naming strategies.  I just don't expect that module to grow a  
> whole lot.

I am in favor of cayenne-tools idea.

Andrus


Re: Moving SmartNamingStrategy out of modeler

Posted by Kevin Menard <ni...@gmail.com>.
On Thu, Apr 16, 2009 at 1:24 AM, Andrey Razumovsky <
razumovsky.andrey@gmail.com> wrote:

>
>
> You mean to rewrite it from clean sheet? Inflector library is very small
> and
> event if we find an alternative, that will be a dependency either (?)
>
> It's also OK for me if we move the strategy to Cayenne core. Then we'll
> need
> compile dependency in core and "inclusive" - in modeler.
>
> So I suggest we either move it to core or create a separate module. But, if
> latter,  I'm leaving the country today and won't be able to accomplish that
> in nearest two weeks.
>


Does anyone have an opinion on this?  Dragging the class files directly into
our assembly may be the easiest thing to do.  We've done this is the past
for other libs such as JDOM.  Otherwise, I'll plan on adding a new module
for naming strategies.  I just don't expect that module to grow a whole lot.

-- 
Kevin

Re: Moving SmartNamingStrategy out of modeler

Posted by Andrey Razumovsky <ra...@gmail.com>.
Well, I see the problem. As it was discussed in past, we moved
SmartNamingStrategy to modeler to get rid of extra dependency on Cayenne
core.


> - Add a dependency on the modeler from the plugin.  Not terrible for maven,
> a little more so for ant.


Likely not the best way, because modeler is heavy and many unwanted
dependencies will be added.


> - Add a soft dependency, whereby you only need that Jar on the classpath if
> you're using that naming strategy.  We've done this for other classes in
> the
> past.  It works, but can be a pain to maintain.


This way anyone will first need to add jar in classpath to use the strategy.
This is really a pain!


> - Move naming strategies into their own module.  For maven the plugins and
> modeler would have a dependency on this new module.  For ant, you'd need
> the
> new JAR on the classpath.


I think this is a better way. Only that creates a new module that can make
our maven structure more complex and unreadable.


> - Find an alternative to the inflector lib.


You mean to rewrite it from clean sheet? Inflector library is very small and
event if we find an alternative, that will be a dependency either (?)

It's also OK for me if we move the strategy to Cayenne core. Then we'll need
compile dependency in core and "inclusive" - in modeler.

So I suggest we either move it to core or create a separate module. But, if
latter,  I'm leaving the country today and won't be able to accomplish that
in nearest two weeks.

Thanks,
Andrey