MylynViaOSGi

(Difference between revisions)
(NetBinox)
(NetBinox)
 
(3 intermediate revisions not shown)
Line 11: Line 11:
=== [[apidesign:Netbinox|NetBinox]] ===
=== [[apidesign:Netbinox|NetBinox]] ===
-
Mylyn requires [[Equinox]], thus we will put [[apidesign:Netbinox|NetBinox]] into the ''platform'' cluster (''ide'' still being option). As there already is [[Felix]], we'll make [[apidesign:Netbinox|NetBinox]] autoload. The module will export token '''org.netbeans.Netbinox''', so every module that will particulary require [[OSGi]] via [[apidesign:Netbinox|NetBinox]] will have to ''need'' that token.
+
Mylyn requires [[Equinox]], thus we will put [[apidesign:Netbinox|NetBinox]] into the ''platform'' cluster (''ide'' still being an option). As there already is [[Felix]], we'll make [[apidesign:Netbinox|NetBinox]] an autoload. The module will export token '''org.netbeans.Netbinox''', so every module (or [[OSGi]] bundle) needing [[apidesign:Netbinox|NetBinox]] will have to ''need'' that token by adding '''OpenIDE-Module-Needs: org.netbeans.Netbinox''' into its manifest.
-
[[apidesign:Netbinox|NetBinox]] will be built from sources and part of [[NetBeans]] Hg repository.
+
[[apidesign:Netbinox|NetBinox]] will be built from sources and part of [[NetBeans]] Hg repository. As part of conversion of the sources, the name of the module will be changed to '''org.netbeans.modules.netbinox''' ([[API]] change compared to previous module from ''apidesign.org'') and internal packages will be changed (not an [[API]] change).
 +
 
 +
The sample [[Equinox]] Based [[Platform]] Application is changed to no longer require a download (as [[Netbinox]] is already present in the system), but rather ''need'' the appropriate token.
== The Tasks  ==
== The Tasks  ==
Line 19: Line 21:
* [[Image:Yes.png]] [[apidesign::Equinox|Equinox]] support - [[apidesign::Mylyn|Mylyn]] does not seem to be satisfied with [[apidesign::Felix|Felix]].
* [[Image:Yes.png]] [[apidesign::Equinox|Equinox]] support - [[apidesign::Mylyn|Mylyn]] does not seem to be satisfied with [[apidesign::Felix|Felix]].
* TODO, '''3days''': Create "wrapper modules" of [[OSGi]] bundles, as used in [[apidesign::NetbinoxTutorial|NetbinoxTutorial]]
* TODO, '''3days''': Create "wrapper modules" of [[OSGi]] bundles, as used in [[apidesign::NetbinoxTutorial|NetbinoxTutorial]]
-
:* Depends on {{iz|197842}}
+
:* [[Image:Yes.png]] Depends on {{iz|197842}}
* Avoid performance degradation of the NetBeans IDE caused by additional ([[OSGi]]) module system - [[apidesign:Netbinox|Netbinox]] is the fastest OSGi container now! Just verify.
* Avoid performance degradation of the NetBeans IDE caused by additional ([[OSGi]]) module system - [[apidesign:Netbinox|Netbinox]] is the fastest OSGi container now! Just verify.
 +
:* Usage of [[apidesign:Netbinox|Netbinox]] seems to add about '''280''' new classes
* TODO, '''2days''': [[apidesign::Mylyn|Mylyn]] needs org.eclipse.core.runtime.compatibility.auth when storing authentication credentials. The question is if we should let it the way it is or look for a unified solution with  {{iz|173413}} for the [[NetBeans]] IDE.
* TODO, '''2days''': [[apidesign::Mylyn|Mylyn]] needs org.eclipse.core.runtime.compatibility.auth when storing authentication credentials. The question is if we should let it the way it is or look for a unified solution with  {{iz|173413}} for the [[NetBeans]] IDE.
** should be possible to make Keyring API bridge: create new source project which generates an OSGi bundle depending on org.netbeans.modules.keyring and org.eclipse.core.runtime.compatibility.auth, registering an impl of the right extension point
** should be possible to make Keyring API bridge: create new source project which generates an OSGi bundle depending on org.netbeans.modules.keyring and org.eclipse.core.runtime.compatibility.auth, registering an impl of the right extension point
-
* TODO: Modify API support to recognize the new cluster and its binaries and properly assemble classpath
 

Current revision as of 08:40, 28 June 2011

When OSGiAndNetBeans became friends in 6.9, we dropped one thing - rewrite of Mylyn to really use OSGi. It is time to fix this for NetBeans 7.1. Tracked as Issue 198248

Contents

The Vision

Let's start to reuse work done by other IDEs and published as OSGi. The NetBeans code already uses the mylyn libraries in the bugtracker connectors ( just as regular jars), and this project would switch their usage from "a library jar" integration to a "osgi bundle" integration.

Cluster

OSGi bundles will be regular "wrapper" projects (just no wrapper JAR will be generated, only config/Modules/*.xml and update_tracking/*.xml). They will be allowed to reside in any cluster (not platform, for now). Tracked as Issue 197842.

NetBinox

Mylyn requires Equinox, thus we will put NetBinox into the platform cluster (ide still being an option). As there already is Felix, we'll make NetBinox an autoload. The module will export token org.netbeans.Netbinox, so every module (or OSGi bundle) needing NetBinox will have to need that token by adding OpenIDE-Module-Needs: org.netbeans.Netbinox into its manifest.

NetBinox will be built from sources and part of NetBeans Hg repository. As part of conversion of the sources, the name of the module will be changed to org.netbeans.modules.netbinox (API change compared to previous module from apidesign.org) and internal packages will be changed (not an API change).

The sample Equinox Based Platform Application is changed to no longer require a download (as Netbinox is already present in the system), but rather need the appropriate token.

The Tasks

  • Avoid performance degradation of the NetBeans IDE caused by additional (OSGi) module system - Netbinox is the fastest OSGi container now! Just verify.
  • Usage of Netbinox seems to add about 280 new classes
  • TODO, 2days: Mylyn needs org.eclipse.core.runtime.compatibility.auth when storing authentication credentials. The question is if we should let it the way it is or look for a unified solution with Issue 173413 for the NetBeans IDE.
    • should be possible to make Keyring API bridge: create new source project which generates an OSGi bundle depending on org.netbeans.modules.keyring and org.eclipse.core.runtime.compatibility.auth, registering an impl of the right extension point
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo