|RE: [mylyn-dev] Mylyn code base usage for IntelliJ
Yes, as far as I know the EPL licensing will allow you to do
I can’t speak for others but I see this as a positive
thing. Mylyn provides several core frameworks that are not coupled to the
Eclipse UI, and having non-Eclipse clients for those frameworks should provide
value to the Mylyn user community in the long run by helping establish those
frameworks as the de facto Java API for task repositories and for the task
context model. The alternative is that we expect other projects (e.g.
IntelliJ) to re-implement those APIs, and I think that provides less overall
benefit to the project. In addition to this Eclipse/Mylyn centric point
of view, in my experience this kind of open source reuse and collaboration is
not a zero sum game and provides benefit to both parties when it works.
In terms of expectations, the best way to expect progress on any
changes to the framework that you would like to see would be to drive them yourself
with design discussion and patches. This is because having a richer
headless framework is not a core part of the current Mylyn 3.0 plan, so
committers will not be dedicating significant time to it, but will support
contributions as usual.
In terms of architecture and coupling to Eclipse/RCP/SWT, I think
that the best place to start is by extending the headless frameworks only (see http://wiki.eclipse.org/Mylyn_Architecture).
These are already intended to run outside of Eclipse, and I have previously embedded
OSGi based plug-ins of this sort in both a NetBeans and IntelliJ addplug-ins (for
AspectJ) and can verify that the approach works. The task context model
has also been prototyped in a Swing app by the Chisel group at the University
of Victoria: http://protege.stanford.edu/conference/2006/submissions/abstracts/9.1_d'Entremont_adaptiveViz_1_column.pdf
For AspectJ I made a UI abstraction layer that worked for both SWT
and Swing, but I’m not sure that this approach is worth it overall.
So I think the best place to start would be with reuse of the core (i.e. model)
parts of the frameworks.
To summarize what I’m saying is to start out by taking a
look at the ..core plug-ins, check out the current documentation on the headless
frameworks, but note that most committers efforts goes towards refactoring
an improving the source and tests and much less towards documenting them.
Keep us posted, and “may the source be with you”,
Back to the top