Page tree
Skip to end of metadata
Go to start of metadata

Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 84 rates

Draft for ?

Proposal on renaming packages. This should be an ongoing effort hopefully finalized in 5.2

Rationale

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

Proposals

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.

 

Current package/classes

Proposed new package

Notes

 

info.magnolia.cms.filters.VirtualUriFilter, info.magnolia.cms.beans.config.VirtualURIManager, info.magnolia.cms.beans.config.VirtualURIMapping and subclasses

info.magnolia.virtualuri

Also see Proposal - merging of URI2RepositoryMapping and VirtualURIMappings

(tick)

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.cms.core

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.