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).
Note: The above is an archived snapshot of a forum thread. Use the original thread at sf.net to post comments.