Hi guys,
On Jun 13, 2007, at 16:09 , Philipp Bracher wrote:
Reverting API changes:
- we should keep the new interfaces HierarchyManager, Content,
NodeData in there original core package
- keeping them in the same package would facilitate updating a lot
- since we plan other changes in the api we should not make an
extra tour for three classes now!
As some of you have noticed, we extracted the interface of the
HierarchyManager class a while ago. The implementation has been
renamed DefaultHierarchyManager, stayed in the same package. We first
moved the interface in a new info.magnolia.api package; we will now
revert this to the old package, for lack of a conscensus on the naming.
The same treatment will soon be applied to the Content and NodeData
classes.
The reasons of extracting the interfaces:
* testing
* integration of 3rd party tools (it will be trivial to expose a
Content instance as a javax.jcr.Node)
Ultimately, we'd like to move these to a new package for the
following reasons:
* general cleanup of the package structure and naming
* having a separate jar containing only the public api of Magnolia,
on which external projects/modules/.. could depend
Since we're not happy with the info.magnolia.api naming right now,
we'll just keep on using the current package name for a while. We're
also hoping to get better ideas/solutions for upgrading in the future
(i.e when we'll have update mechanism in place, maybe we'll be able
to come up with more transparent or simpler ideas for this - if we
changed the package now, people would have to update their templates
before actually upgrading to the new version, while ideally, we'd
like them to be able to do this once Magnolia was upgraded, or not
have to do it at all)
Please feel free to comment or suggest ideas !
Cheers,
greg
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------
