You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Michael Gentry <bl...@gmail.com> on 2007/12/19 15:31:59 UTC
Cayenne XML Names
I know I've brought this up before, but I don't believe we really
decided on anything (or did anything), so here goes again ...
What do you think about changing the default behavior of Cayenne and
the Modeler to look for directory wrappers for the Cayenne XML files
instead of looking for cayenne.xml? Here are the changes and
advantages as I see them:
* Have Cayenne Modeler save the XML files (cayenne.xml, etc) into a
Cayenne wrapper directory of your naming, such as MyModel.cayenne (it
would append the .cayenne, which is the wrapper signature). You could
also have MyOtherModel.cayenne in the same directory.
* Have Cayenne resolve all *.cayenne wrappers at the root of the
CLASSPATH upon startup. This will make it easier to support multiple
models and also utilize models in other frameworks. For legacy
support, also look for cayenne.xml if no *.cayenne wrappers are found.
(I suppose it could also add cayenne.xml regardless of if *.cayenne
wrappers are found.) It might seem like a performance hit to look for
all *.cayenne, but most things at the root of the CLASSPATH are
directories like "org" or "com", so it seems to me the scanning would
be minimal.
* The *.cayenne wrapper directories could be "branded" with a Cayenne
logo (at least on OS X, not 100% sure about other OS's).
* The *.cayenne wrapper can be double-clicked to launch Cayenne
Modeler (again, on OS X, hopefully on other OS's too).
* It is easier to copy a model around in a GUI (drag and drop one
"file") instead of select multiple files.
There might be other advantages, too. Those are just the ones off the
top of my head. I can't think of any real negatives to this, either,
but feedback is greatly appreciated.
Thanks,
/dev/mrg
Re: Cayenne XML Names
Posted by Michael Gentry <bl...@gmail.com>.
Perhaps it is just my preference (or conditioning) that when an
application creates N (where N > 1) data files, it stores/organizes it
in a directory.
/dev/mrg
On Dec 27, 2007 6:14 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> But you can use a dedicated folder for Cayenne mapping now. I guess my
> disagreement is that we should make folder-based setup a default (even
> if an optional default).
>
> Thanks,
> Andrus
>
>
>
> On Dec 26, 2007, at 5:15 PM, Michael Gentry wrote:
>
> > I don't mind having the mapping (DataMap) in a single file, although
> > perhaps it might make merging harder if two people are editing the
> > same model simultaneously. And I wasn't really suggesting splitting
> > it out into a file-per-entity, like in EOModeler. I was talking about
> > grouping all current Cayenne XML (Domains, Maps, Nodes) files in a
> > single directory wrapper. This would make it easier to make quick
> > copies of a model before you changed something if you wanted (for
> > whatever reason). Of course, if an SCM system is in place, you have
> > to deal with the directory quirks of the system if you actually want
> > to rename or move the file, but that argument could be made about
> > refactoring any bit of the system. It would also be easier to send a
> > copy of the model to someone who isn't set up with the SCM system
> > (like DBAs, etc). They could use the modeler to view the model or,
> > and this is what I'm looking at currently, be able to edit the
> > database with another tool (I've started designing a DBEdit clone that
> > would work with Cayenne Models -- DBEdit is currently dead on Leopard
> > and is an invaluable tool for database-related software development
> > and production support). The branding issue is secondary, although it
> > would be nice to double-click on a model and have it open in CM.
> >
> > Thanks,
> >
> > /dev/mrg
> >
> > PS. Not all models are simple, either -- one of mine had 8 XML files,
> > but would've had more if I weren't creating DataMaps at runtime ...
> > made the root a bit messier.
> >
> > On Dec 19, 2007 11:40 AM, Andrus Adamchik <an...@objectstyle.org>
> > wrote:
> >> I just remembered some background BTW. The conclusion I came to in
> >> the
> >> message below is the same one we made in 2001 when we approached the
> >> initial Cayenne design. The group of people involved all did
> >> WebObjects development on Windows, and used CVS (which is rather
> >> directory-unfriendly). So the feeling was that having mapping in a
> >> single file is a usability feature compared to EOF. Since we are not
> >> going to split map.xml any further, look at it this way: it makes
> >> sense to have an .emodeld folder for EOF as it had one mapping file
> >> per entity... it does not for Cayenne.
> >>
> >> Andrus
> >>
> >>
> >>
> >>
> >> On Dec 19, 2007, at 6:27 PM, Andrus Adamchik wrote:
> >>
> >>> Not saying yes or no just yet, but let me comment on the specific
> >>> items.
> >>>
> >>>> * Have Cayenne Modeler save the XML files (cayenne.xml, etc) into a
> >>>> Cayenne wrapper directory of your naming, such as MyModel.cayenne
> >>>> (it
> >>>> would append the .cayenne, which is the wrapper signature). You
> >>>> could
> >>>> also have MyOtherModel.cayenne in the same directory.
> >>>
> >>> Currently you can have multiple cayenne.xml files either in
> >>> different packages or in the root of different jars (of course this
> >>> will only becomes really useful once we implement CAY-943). Having
> >>> multiple cayenne.xml in a single jar doesn't buy you much really...
> >>>
> >>>> * Have Cayenne resolve all *.cayenne wrappers at the root of the
> >>>> CLASSPATH upon startup.
> >>>
> >>> How are you planning to do that? The only environment independent
> >>> way that I know of in Java is "ClassLoader.getResources(String)"
> >>> which requires an exact name, not a pattern. This would work for
> >>> multiple cayenne.xml in the root of different jars, but won't work
> >>> for "*.cayenne" (there are some workarounds that may potentially
> >>> limit portability).
> >>>
> >>>> * The *.cayenne wrapper directories could be "branded" with a
> >>>> Cayenne
> >>>> logo (at least on OS X, not 100% sure about other OS's).
> >>>
> >>> This would be an OSX only feature.
> >>>
> >>>> * The *.cayenne wrapper can be double-clicked to launch Cayenne
> >>>> Modeler (again, on OS X, hopefully on other OS's too).
> >>>
> >>> This one too.
> >>>
> >>>> * It is easier to copy a model around in a GUI (drag and drop one
> >>>> "file") instead of select multiple files.
> >>>
> >>> True, although usually you'd have .svn in your folder, so you do not
> >>> want to copy that.
> >>>
> >>>> I can't think of any real negatives to this, either,
> >>>> but feedback is greatly appreciated.
> >>>
> >>> The biggest negative to me is that we introduce extra complexity
> >>> without a clear advantage. I am worried of Cayenne turning into Perl
> >>> with multiple redundant ways to solve any given problem (note that
> >>> usually I am the one guilty of this .... for instance now we have 3
> >>> types of persistent objects).
> >>>
> >>> Anyways, we have to weigh potential benefits against this concern.
> >>> And the only benefit I am seeing so far is branding on OS X which is
> >>> probably the least of our concerns.
> >>>
> >>> Andrus
> >>>
> >>
> >>
> >
>
>
Re: Cayenne XML Names
Posted by Andrus Adamchik <an...@objectstyle.org>.
But you can use a dedicated folder for Cayenne mapping now. I guess my
disagreement is that we should make folder-based setup a default (even
if an optional default).
Thanks,
Andrus
On Dec 26, 2007, at 5:15 PM, Michael Gentry wrote:
> I don't mind having the mapping (DataMap) in a single file, although
> perhaps it might make merging harder if two people are editing the
> same model simultaneously. And I wasn't really suggesting splitting
> it out into a file-per-entity, like in EOModeler. I was talking about
> grouping all current Cayenne XML (Domains, Maps, Nodes) files in a
> single directory wrapper. This would make it easier to make quick
> copies of a model before you changed something if you wanted (for
> whatever reason). Of course, if an SCM system is in place, you have
> to deal with the directory quirks of the system if you actually want
> to rename or move the file, but that argument could be made about
> refactoring any bit of the system. It would also be easier to send a
> copy of the model to someone who isn't set up with the SCM system
> (like DBAs, etc). They could use the modeler to view the model or,
> and this is what I'm looking at currently, be able to edit the
> database with another tool (I've started designing a DBEdit clone that
> would work with Cayenne Models -- DBEdit is currently dead on Leopard
> and is an invaluable tool for database-related software development
> and production support). The branding issue is secondary, although it
> would be nice to double-click on a model and have it open in CM.
>
> Thanks,
>
> /dev/mrg
>
> PS. Not all models are simple, either -- one of mine had 8 XML files,
> but would've had more if I weren't creating DataMaps at runtime ...
> made the root a bit messier.
>
> On Dec 19, 2007 11:40 AM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
>> I just remembered some background BTW. The conclusion I came to in
>> the
>> message below is the same one we made in 2001 when we approached the
>> initial Cayenne design. The group of people involved all did
>> WebObjects development on Windows, and used CVS (which is rather
>> directory-unfriendly). So the feeling was that having mapping in a
>> single file is a usability feature compared to EOF. Since we are not
>> going to split map.xml any further, look at it this way: it makes
>> sense to have an .emodeld folder for EOF as it had one mapping file
>> per entity... it does not for Cayenne.
>>
>> Andrus
>>
>>
>>
>>
>> On Dec 19, 2007, at 6:27 PM, Andrus Adamchik wrote:
>>
>>> Not saying yes or no just yet, but let me comment on the specific
>>> items.
>>>
>>>> * Have Cayenne Modeler save the XML files (cayenne.xml, etc) into a
>>>> Cayenne wrapper directory of your naming, such as MyModel.cayenne
>>>> (it
>>>> would append the .cayenne, which is the wrapper signature). You
>>>> could
>>>> also have MyOtherModel.cayenne in the same directory.
>>>
>>> Currently you can have multiple cayenne.xml files either in
>>> different packages or in the root of different jars (of course this
>>> will only becomes really useful once we implement CAY-943). Having
>>> multiple cayenne.xml in a single jar doesn't buy you much really...
>>>
>>>> * Have Cayenne resolve all *.cayenne wrappers at the root of the
>>>> CLASSPATH upon startup.
>>>
>>> How are you planning to do that? The only environment independent
>>> way that I know of in Java is "ClassLoader.getResources(String)"
>>> which requires an exact name, not a pattern. This would work for
>>> multiple cayenne.xml in the root of different jars, but won't work
>>> for "*.cayenne" (there are some workarounds that may potentially
>>> limit portability).
>>>
>>>> * The *.cayenne wrapper directories could be "branded" with a
>>>> Cayenne
>>>> logo (at least on OS X, not 100% sure about other OS's).
>>>
>>> This would be an OSX only feature.
>>>
>>>> * The *.cayenne wrapper can be double-clicked to launch Cayenne
>>>> Modeler (again, on OS X, hopefully on other OS's too).
>>>
>>> This one too.
>>>
>>>> * It is easier to copy a model around in a GUI (drag and drop one
>>>> "file") instead of select multiple files.
>>>
>>> True, although usually you'd have .svn in your folder, so you do not
>>> want to copy that.
>>>
>>>> I can't think of any real negatives to this, either,
>>>> but feedback is greatly appreciated.
>>>
>>> The biggest negative to me is that we introduce extra complexity
>>> without a clear advantage. I am worried of Cayenne turning into Perl
>>> with multiple redundant ways to solve any given problem (note that
>>> usually I am the one guilty of this .... for instance now we have 3
>>> types of persistent objects).
>>>
>>> Anyways, we have to weigh potential benefits against this concern.
>>> And the only benefit I am seeing so far is branding on OS X which is
>>> probably the least of our concerns.
>>>
>>> Andrus
>>>
>>
>>
>
Re: Cayenne XML Names
Posted by Michael Gentry <bl...@gmail.com>.
I don't mind having the mapping (DataMap) in a single file, although
perhaps it might make merging harder if two people are editing the
same model simultaneously. And I wasn't really suggesting splitting
it out into a file-per-entity, like in EOModeler. I was talking about
grouping all current Cayenne XML (Domains, Maps, Nodes) files in a
single directory wrapper. This would make it easier to make quick
copies of a model before you changed something if you wanted (for
whatever reason). Of course, if an SCM system is in place, you have
to deal with the directory quirks of the system if you actually want
to rename or move the file, but that argument could be made about
refactoring any bit of the system. It would also be easier to send a
copy of the model to someone who isn't set up with the SCM system
(like DBAs, etc). They could use the modeler to view the model or,
and this is what I'm looking at currently, be able to edit the
database with another tool (I've started designing a DBEdit clone that
would work with Cayenne Models -- DBEdit is currently dead on Leopard
and is an invaluable tool for database-related software development
and production support). The branding issue is secondary, although it
would be nice to double-click on a model and have it open in CM.
Thanks,
/dev/mrg
PS. Not all models are simple, either -- one of mine had 8 XML files,
but would've had more if I weren't creating DataMaps at runtime ...
made the root a bit messier.
On Dec 19, 2007 11:40 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> I just remembered some background BTW. The conclusion I came to in the
> message below is the same one we made in 2001 when we approached the
> initial Cayenne design. The group of people involved all did
> WebObjects development on Windows, and used CVS (which is rather
> directory-unfriendly). So the feeling was that having mapping in a
> single file is a usability feature compared to EOF. Since we are not
> going to split map.xml any further, look at it this way: it makes
> sense to have an .emodeld folder for EOF as it had one mapping file
> per entity... it does not for Cayenne.
>
> Andrus
>
>
>
>
> On Dec 19, 2007, at 6:27 PM, Andrus Adamchik wrote:
>
> > Not saying yes or no just yet, but let me comment on the specific
> > items.
> >
> >> * Have Cayenne Modeler save the XML files (cayenne.xml, etc) into a
> >> Cayenne wrapper directory of your naming, such as MyModel.cayenne (it
> >> would append the .cayenne, which is the wrapper signature). You
> >> could
> >> also have MyOtherModel.cayenne in the same directory.
> >
> > Currently you can have multiple cayenne.xml files either in
> > different packages or in the root of different jars (of course this
> > will only becomes really useful once we implement CAY-943). Having
> > multiple cayenne.xml in a single jar doesn't buy you much really...
> >
> >> * Have Cayenne resolve all *.cayenne wrappers at the root of the
> >> CLASSPATH upon startup.
> >
> > How are you planning to do that? The only environment independent
> > way that I know of in Java is "ClassLoader.getResources(String)"
> > which requires an exact name, not a pattern. This would work for
> > multiple cayenne.xml in the root of different jars, but won't work
> > for "*.cayenne" (there are some workarounds that may potentially
> > limit portability).
> >
> >> * The *.cayenne wrapper directories could be "branded" with a Cayenne
> >> logo (at least on OS X, not 100% sure about other OS's).
> >
> > This would be an OSX only feature.
> >
> >> * The *.cayenne wrapper can be double-clicked to launch Cayenne
> >> Modeler (again, on OS X, hopefully on other OS's too).
> >
> > This one too.
> >
> >> * It is easier to copy a model around in a GUI (drag and drop one
> >> "file") instead of select multiple files.
> >
> > True, although usually you'd have .svn in your folder, so you do not
> > want to copy that.
> >
> >> I can't think of any real negatives to this, either,
> >> but feedback is greatly appreciated.
> >
> > The biggest negative to me is that we introduce extra complexity
> > without a clear advantage. I am worried of Cayenne turning into Perl
> > with multiple redundant ways to solve any given problem (note that
> > usually I am the one guilty of this .... for instance now we have 3
> > types of persistent objects).
> >
> > Anyways, we have to weigh potential benefits against this concern.
> > And the only benefit I am seeing so far is branding on OS X which is
> > probably the least of our concerns.
> >
> > Andrus
> >
>
>
Re: Cayenne XML Names
Posted by Andrus Adamchik <an...@objectstyle.org>.
I just remembered some background BTW. The conclusion I came to in the
message below is the same one we made in 2001 when we approached the
initial Cayenne design. The group of people involved all did
WebObjects development on Windows, and used CVS (which is rather
directory-unfriendly). So the feeling was that having mapping in a
single file is a usability feature compared to EOF. Since we are not
going to split map.xml any further, look at it this way: it makes
sense to have an .emodeld folder for EOF as it had one mapping file
per entity... it does not for Cayenne.
Andrus
On Dec 19, 2007, at 6:27 PM, Andrus Adamchik wrote:
> Not saying yes or no just yet, but let me comment on the specific
> items.
>
>> * Have Cayenne Modeler save the XML files (cayenne.xml, etc) into a
>> Cayenne wrapper directory of your naming, such as MyModel.cayenne (it
>> would append the .cayenne, which is the wrapper signature). You
>> could
>> also have MyOtherModel.cayenne in the same directory.
>
> Currently you can have multiple cayenne.xml files either in
> different packages or in the root of different jars (of course this
> will only becomes really useful once we implement CAY-943). Having
> multiple cayenne.xml in a single jar doesn't buy you much really...
>
>> * Have Cayenne resolve all *.cayenne wrappers at the root of the
>> CLASSPATH upon startup.
>
> How are you planning to do that? The only environment independent
> way that I know of in Java is "ClassLoader.getResources(String)"
> which requires an exact name, not a pattern. This would work for
> multiple cayenne.xml in the root of different jars, but won't work
> for "*.cayenne" (there are some workarounds that may potentially
> limit portability).
>
>> * The *.cayenne wrapper directories could be "branded" with a Cayenne
>> logo (at least on OS X, not 100% sure about other OS's).
>
> This would be an OSX only feature.
>
>> * The *.cayenne wrapper can be double-clicked to launch Cayenne
>> Modeler (again, on OS X, hopefully on other OS's too).
>
> This one too.
>
>> * It is easier to copy a model around in a GUI (drag and drop one
>> "file") instead of select multiple files.
>
> True, although usually you'd have .svn in your folder, so you do not
> want to copy that.
>
>> I can't think of any real negatives to this, either,
>> but feedback is greatly appreciated.
>
> The biggest negative to me is that we introduce extra complexity
> without a clear advantage. I am worried of Cayenne turning into Perl
> with multiple redundant ways to solve any given problem (note that
> usually I am the one guilty of this .... for instance now we have 3
> types of persistent objects).
>
> Anyways, we have to weigh potential benefits against this concern.
> And the only benefit I am seeing so far is branding on OS X which is
> probably the least of our concerns.
>
> Andrus
>
Re: Cayenne XML Names
Posted by Andrus Adamchik <an...@objectstyle.org>.
Not saying yes or no just yet, but let me comment on the specific items.
> * Have Cayenne Modeler save the XML files (cayenne.xml, etc) into a
> Cayenne wrapper directory of your naming, such as MyModel.cayenne (it
> would append the .cayenne, which is the wrapper signature). You could
> also have MyOtherModel.cayenne in the same directory.
Currently you can have multiple cayenne.xml files either in different
packages or in the root of different jars (of course this will only
becomes really useful once we implement CAY-943). Having multiple
cayenne.xml in a single jar doesn't buy you much really...
> * Have Cayenne resolve all *.cayenne wrappers at the root of the
> CLASSPATH upon startup.
How are you planning to do that? The only environment independent way
that I know of in Java is "ClassLoader.getResources(String)" which
requires an exact name, not a pattern. This would work for multiple
cayenne.xml in the root of different jars, but won't work for
"*.cayenne" (there are some workarounds that may potentially limit
portability).
> * The *.cayenne wrapper directories could be "branded" with a Cayenne
> logo (at least on OS X, not 100% sure about other OS's).
This would be an OSX only feature.
> * The *.cayenne wrapper can be double-clicked to launch Cayenne
> Modeler (again, on OS X, hopefully on other OS's too).
This one too.
> * It is easier to copy a model around in a GUI (drag and drop one
> "file") instead of select multiple files.
True, although usually you'd have .svn in your folder, so you do not
want to copy that.
> I can't think of any real negatives to this, either,
> but feedback is greatly appreciated.
The biggest negative to me is that we introduce extra complexity
without a clear advantage. I am worried of Cayenne turning into Perl
with multiple redundant ways to solve any given problem (note that
usually I am the one guilty of this .... for instance now we have 3
types of persistent objects).
Anyways, we have to weigh potential benefits against this concern. And
the only benefit I am seeing so far is branding on OS X which is
probably the least of our concerns.
Andrus
Re: Cayenne XML Names
Posted by Michael Gentry <bl...@gmail.com>.
I'll have to think about that when I have more spare cycles. I'm not
sure this will help you, but in a previous project I had:
environments/local/MyDataNode.driver.xml
(and also "development", "testing", "acceptance", and "production"
under "environments")
My ant build.xml would pull in and replace the DataNode XML with the
one for the appropriate environment I was building before creating the
JAR.
/dev/mrg
On Dec 19, 2007 10:07 AM, Kevin Menard <km...@servprise.com> wrote:
> My only real criticism is that I would need to keep two .cayenne folders
> around if I understand your proposal.
>
> E.g., I have a "models" JAR that contains both my server and client classes.
> Packaged in the JAR is the cayenne.xml and data map. I don't package the
> domain node at this stage because I want the JAR to be usable by other
> projects that can specify their own connection info. So, the trio of files
> is actually split over different JARs and the class loader just happens to
> pick them all up.
>
> One sort of a pain in the neck part is that every time I load my project
> into the modeler, a new domain node file is auto-generated that I have to
> remove from the project so that it doesn't get packaged with the JAR.
>
> How would your proposal work for that sort of situation?
>
> --
> Kevin
>
>
>
> On 12/19/07 9:31 AM, "Michael Gentry" <bl...@gmail.com> wrote:
>
> > I know I've brought this up before, but I don't believe we really
> > decided on anything (or did anything), so here goes again ...
> >
> > What do you think about changing the default behavior of Cayenne and
> > the Modeler to look for directory wrappers for the Cayenne XML files
> > instead of looking for cayenne.xml? Here are the changes and
> > advantages as I see them:
> >
> > * Have Cayenne Modeler save the XML files (cayenne.xml, etc) into a
> > Cayenne wrapper directory of your naming, such as MyModel.cayenne (it
> > would append the .cayenne, which is the wrapper signature). You could
> > also have MyOtherModel.cayenne in the same directory.
> >
> > * Have Cayenne resolve all *.cayenne wrappers at the root of the
> > CLASSPATH upon startup. This will make it easier to support multiple
> > models and also utilize models in other frameworks. For legacy
> > support, also look for cayenne.xml if no *.cayenne wrappers are found.
> > (I suppose it could also add cayenne.xml regardless of if *.cayenne
> > wrappers are found.) It might seem like a performance hit to look for
> > all *.cayenne, but most things at the root of the CLASSPATH are
> > directories like "org" or "com", so it seems to me the scanning would
> > be minimal.
> >
> > * The *.cayenne wrapper directories could be "branded" with a Cayenne
> > logo (at least on OS X, not 100% sure about other OS's).
> >
> > * The *.cayenne wrapper can be double-clicked to launch Cayenne
> > Modeler (again, on OS X, hopefully on other OS's too).
> >
> > * It is easier to copy a model around in a GUI (drag and drop one
> > "file") instead of select multiple files.
> >
> >
> > There might be other advantages, too. Those are just the ones off the
> > top of my head. I can't think of any real negatives to this, either,
> > but feedback is greatly appreciated.
> >
> > Thanks,
> >
> > /dev/mrg
>
>
Re: Cayenne XML Names
Posted by Kevin Menard <km...@servprise.com>.
My only real criticism is that I would need to keep two .cayenne folders
around if I understand your proposal.
E.g., I have a "models" JAR that contains both my server and client classes.
Packaged in the JAR is the cayenne.xml and data map. I don't package the
domain node at this stage because I want the JAR to be usable by other
projects that can specify their own connection info. So, the trio of files
is actually split over different JARs and the class loader just happens to
pick them all up.
One sort of a pain in the neck part is that every time I load my project
into the modeler, a new domain node file is auto-generated that I have to
remove from the project so that it doesn't get packaged with the JAR.
How would your proposal work for that sort of situation?
--
Kevin
On 12/19/07 9:31 AM, "Michael Gentry" <bl...@gmail.com> wrote:
> I know I've brought this up before, but I don't believe we really
> decided on anything (or did anything), so here goes again ...
>
> What do you think about changing the default behavior of Cayenne and
> the Modeler to look for directory wrappers for the Cayenne XML files
> instead of looking for cayenne.xml? Here are the changes and
> advantages as I see them:
>
> * Have Cayenne Modeler save the XML files (cayenne.xml, etc) into a
> Cayenne wrapper directory of your naming, such as MyModel.cayenne (it
> would append the .cayenne, which is the wrapper signature). You could
> also have MyOtherModel.cayenne in the same directory.
>
> * Have Cayenne resolve all *.cayenne wrappers at the root of the
> CLASSPATH upon startup. This will make it easier to support multiple
> models and also utilize models in other frameworks. For legacy
> support, also look for cayenne.xml if no *.cayenne wrappers are found.
> (I suppose it could also add cayenne.xml regardless of if *.cayenne
> wrappers are found.) It might seem like a performance hit to look for
> all *.cayenne, but most things at the root of the CLASSPATH are
> directories like "org" or "com", so it seems to me the scanning would
> be minimal.
>
> * The *.cayenne wrapper directories could be "branded" with a Cayenne
> logo (at least on OS X, not 100% sure about other OS's).
>
> * The *.cayenne wrapper can be double-clicked to launch Cayenne
> Modeler (again, on OS X, hopefully on other OS's too).
>
> * It is easier to copy a model around in a GUI (drag and drop one
> "file") instead of select multiple files.
>
>
> There might be other advantages, too. Those are just the ones off the
> top of my head. I can't think of any real negatives to this, either,
> but feedback is greatly appreciated.
>
> Thanks,
>
> /dev/mrg