|RE: [mylyn-dev] Mylyn code base usage for IntelliJ|
Yes, as far as I know the EPL licensing will allow you to do this.
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