[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] About the fwk rewrite

One of my main motivations behind the framework "restructuring" is to simplify the codebase.  Right now the codebase has way too many layers and each added layer gets in the way when prototyping new ideas in the framework.  Also, it makes it very hard for someone to understand the full picture of the framework implementation.  I want to get more folks involved in the codebase and I think one of the main roadblocks to getting involved is the level of (sometimes unnecessary) complication.

The restructured framework currently has no FrameworkAdaptor layer.  It only provides isolated hooks that can be used to augment specific behavior of the framework.  Even these equinox specific hooks I would like to reduce the usage of and try to have folks use the standard OSGi hooks where possible (located in the subpackages of org.osgi.framework.hooks).  For example the Equinox Weaving project needs to move over to the standard hooks (see bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=377422).

It is good to understand any new requirements that may be needed by a restructured framework implementation, but right now I am looking for more things that I can throw away in order to make the framework more lightweight, faster and easier to maintain and adapt in the future.

Tom



Inactive hide details for Raymond Auge ---09/05/2012 09:16:16 AM---On roughly the same topic (handling of storage & configuratiRaymond Auge ---09/05/2012 09:16:16 AM---On roughly the same topic (handling of storage & configuration) I was wondering during such a re-factor if it might be possible


    From:

Raymond Auge <raymond.auge@xxxxxxxxxxx>

    To:

Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,

    Date:

09/05/2012 09:16 AM

    Subject:

Re: [equinox-dev] About the fwk rewrite




On roughly the same topic (handling of storage & configuration) I was wondering during such a re-factor if it might be possible to provide for alternative implementations of FrameworkAdaptor as opposed to the currently hard wired BaseAdaptor.

I think this may provide the necessary avenue for changing any behaviors of storage or configuration handling by third parties.


Thoughts?

--
Raymond Augé  | Senior Software Architect | Liferay, Inc. 

---

8-9 October 2012 | Liferay North America Symposium | liferay.com/northamerica2012

16-17 October 2012 | Liferay Europe Symposium | liferay.com/europe2012

24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

GIF image

GIF image