Hi Korosh,
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”,
Mik
From:
mylyn-dev-bounces@xxxxxxxxxxx [mailto:mylyn-dev-bounces@xxxxxxxxxxx] On
Behalf Of Korosh
Sent: Thursday, September 27, 2007 3:07 PM
To: mylyn-dev@xxxxxxxxxxx
Subject: [mylyn-dev] Mylyn code base usage for IntelliJ
Hi folks,
I am contemplating using Mylyn source code and port over into an Intellij
plugin.
I'd appreciate any feedback on the below questions:
- would licensing for Mylyn allow me to do this.
- how does the general development community for Mylyn feel about this.
- does the Mylyn architecture have enough of abstraction points of its object
model to allow this to take place. e.g. using maybe a MVC or
a way to modify the view seamlessly ? Or would the GUI and model be too
intertwined to make this difficult.
- What portions of Eclipse platform does Mylyn heavily depend on for its
functionality ?
- Is there anything in SWT that mylyn relies upon that might not be
present in Swing (IntelliJ) ?
- How well is the code documented
I have a very rudimentary knowledge of the Eclipse plugin architecture, so
forgive me for the basic questions.
Any other suggestions appreciated as to how to go about doing this.
K.