While I have no objections to this renaming in general, you should
know that
this package was already distributed in M5. So this renaming can
cause
potential compilation problems unless we keep old deprecated
"reveng-classes".
We may go through a deprecation, but we don't have to. The promise
about API stability that we give to our users is that *stable* API
will be modified as gently as possible. Milestone releases are
considered alpha and give us the freedom to modify newly introduced
API's at will.
I feel that such decisions should be made in a consensus, but
usually I get
little feedback with that..
Absolutely. In fact what's at work here is "lazy consensus". If you
suggest something and get no relevant feedback, you are absolutely
within your rights as a committer to proceed with your initial idea.
Andrus
On Dec 20, 2008, at 2:14 PM, Andrey Razumovsky wrote:
Hi Andrus,
While I have no objections to this renaming in general, you should
know that
this package was already distributed in M5. So this renaming can
cause
potential compilation problems unless we keep old deprecated
"reveng-classes".
I feel that such decisions should be made in a consensus, but
usually I get
little feedback with that..
2008/12/20 Andrus Adamchik <[email protected]>
I am feeling like the package for the new naming stuff,
"access.reveng",
should either be renamed or moved to some existing package. Two
reasons:
* Classes and interfaces there by themselves do not deal with
"reverse
engineering". They are used during reverse engineering by other
classes
located elsewhere (and can potentially be used for other things, e.g.
creating an ObjEntity in the Modeler from a DbEntity.
* Don't like using an abbreviation ("reveng"). We've been guilty of
that in
the past (ObjEntity), but now trying to stay away from abbrevs.
Not completely sure where it would fit though.
"org.apache.cayenne.map.naming" maybe?
Andrus
