refactor out core plugin

jgangemi wrote on Thu Aug  3 17:29:27 MEST 2006:

thoughts on refactoring out "core" epic components from the editor package
into it's own "core" plugin?

we could consolidate and export shared libraries from a single location
and it would offer more flexibility in terms of releasing updates since
a small bugfix to a core library could be published independently of having
to republish all the editor code at the same time.

it seems most large scale plugin projects follow this paradigm as well.

jploski wrote on Thu Aug  3 18:41:58 MEST 2006:

I am not quite sure how smart update sites are - if a feature's version
is increased, and within that feature only one plug-in's version changes,
does Eclipse download just this changed plug-in or all of the feature's
plug-ins anyway?

I see a problem in defining what is 'core' and what is not. Sounds like
a major rework to me, preceded by an analysis of dependencies. AFAIK, Eclipse's
own plug-ins were separated into core and ui from the very beginning. I
don't know if it is worth the effort - the update speedup argument sounds
rather weak to me. An architecture with fewer elements might be simpler
to understand for newcomers.

jgangemi wrote on Sat Aug  5 22:57:09 MEST 2006:

if the editor is going to be treated as the "core", can it export libraries
for others to share (ie the regexp lib) - it would cut down on download
size via the update site, and ensure all plugins were using the same library
version.

jploski wrote on Sat Aug  5 23:19:25 MEST 2006:

Good idea with the export (if it works), but the regexp library is a bad
example. It should not be used at all since we have java.util.regex (indeed,
it's no longer included in org.epic.perleditor, still referenced from org.epic.debug,
though).