Draft for ?
Proposal on renaming packages. This should be an ongoing effort hopefully finalized in 5.2
We currently have
- an inconsistant package naming scheme
- poor separation of concerns in terms of package choice
Since this is something that will break backwards compatibility (it might be possible to keep it if we don't do it all at once, but there's so much to do that it might be impossible in some cases), maybe it's something we'll only consider for 5.0
Following is a table outlining proposed changes. In some cases, it's just about renaming/moving the package, in other cases, it's about moving classes to more appropriate packages.
In general, grouping classes of related concerns in a package would help:
- controlling dependencies between parts of the system
- getting a generally better and cleaner API by being able to only expose what actually need to be exposed (i.e we currently have a bunch of public classes or methods which should not be, but are only for the sake of being used by their counterparts)
IMO, it is much better practice, and produces a cleaner and simpler API to group classes by concern rather than by "genre" (i.e a specific filter with its related manager, helper, beans in a single package, rather than one package with all filters, one with all beans etc.)
Definition: A package is a grouping of related types providing access protection and name space management. Note that types refers to classes, interfaces, enumerations, and annotation types.
Proposed new package
info.magnolia.cms.filters.VirtualUriFilter, info.magnolia.cms.beans.config.VirtualURIManager, info.magnolia.cms.beans.config.VirtualURIMapping and subclasses
info.magnolia.cms.servlets.MgnlServletContextListener, info.magnolia.cms.beans.config.PropertiesInitializer, info.magnolia.cms.beans.config.ConfigLoader
info.magnolia.config or info.magnolia.init
Could also be cleaned up!
info.magnolia.core , info.magnolia.api ?
We've also been discussed for a long time the getting rid of the .cms subpackage. Otoh, I see now a whole bunch of packages which could be used outside the context of a CMS per se.