Re[2]: [equinox-dev] New Module support.

[Peter Kriens <Peter.Kriens@xxxxxxxx>]

We discussed this last week in Boca Raton in the OSGi. It was argued
that the Bundle-Name (and the associated Bundle-Version) never had
strong semantics tied to it and could therefore not be used.

However, I have been thinking about this and I think we can keep this
significantly simpler if we put those semantics on
Bundle-Name/Bundle-Version and not introduce the new module name.

Only new bundles can take advantage of the module system so it
backward compatibility is therefore in my idea not an issue. You only
use the concept with new bundles.

Kind regards,

     Peter Kriens

RC> I noticed that the Export-Module entry value for automatically generated 
RC> manifests contains the bundle name as its first element (see manifest 
RC> generated for the resources plug-in below). Will it always be equal to the 
RC> bundle name? I don't have a problem with redundancy, I was just wondering 
RC> if I can rely on the bundle name to determine the module id.

RC> Generated: true
RC> Bundle-Name: org.eclipse.core.resources
RC> Bundle-Version: 3.0
RC> Bundle-ClassPath: resources.jar
RC> Legacy: true
RC> Bundle-Activator: org.eclipse.core.runtime.compatibility.PluginActivator
RC> Plugin-Class: org.eclipse.core.resources.ResourcesPlugin
RC> Export-Module: org.eclipse.core.resources; module-version=3.0;
RC>  module-package=org.eclipse.core.internal.resources;
RC>  module-package=org.eclipse.core.resources.team;
RC>  module-package=org.eclipse.core.internal.watson;
RC>  module-package=org.eclipse.core.internal.properties;
RC>  module-package=org.eclipse.core.resources;
RC>  module-package=org.eclipse.core.internal.indexing;
RC>  module-package=org.eclipse.core.internal.dtree;
RC>  module-package=org.eclipse.core.internal.localstore;
RC>  module-package=org.eclipse.core.internal.events;
RC>  module-package=org.eclipse.core.internal.utils
RC> DynamicImport-Package: *
RC> Import-Module: 
RC>  org.apache.xerces,
RC>  org.eclipse.core.runtime






RC> Thomas Watson <tjwatson@xxxxxxxxxx>
RC> Sent by: equinox-dev-admin@xxxxxxxxxxx
RC> 25/09/2003 06:59 PM
 
RC>         To:     equinox-dev@xxxxxxxxxxx
RC>         cc: 
RC>         Subject:        [equinox-dev] New Module support.






RC> New module support has been dropped into the Equinox repository.  The new
RC> module support should replace all of the package splitting that was being
RC> done.  As a result all of the hard-coded manifests need to be updated for
RC> the following standard plugins:

RC>     org.apache.xerces
RC>     org.eclipse.swt
RC>     org.eclipse.swt.carbon
RC>     org.eclipse.swt.gtk
RC>     org.eclipse.swt.motif
RC>     org.eclipse.swt.photon
RC>     org.eclipse.swt.win32

RC> The equinox plugin project org.eclipse.core.runtime.osgi contains the
RC> updated manifests for these projects under the folder
RC> org.eclipse.core.runtime.osgi/manifests/.  All other standard plugins
RC> should remove their existing manifest files so that the new manifest
RC> generator will create the properly formated ones.  The following standard
RC> plugins currently have manifests that need to be deleted:

RC>     org.eclipse.text
RC>     org.eclipse.ui
RC>     org.eclipse.ui.editors
RC>     org.eclipse.ui.versioncheck
RC>     org.eclipse.ui.views

RC> Until a new integrated build includes these manifest changes you will need
RC> to manually update or remove the manifests for the plugins mentioned 
RC> above.

RC> Thomas Watson

RC> _______________________________________________
RC> equinox-dev mailing list
RC> equinox-dev@xxxxxxxxxxx
RC> http://dev.eclipse.org/mailman/listinfo/equinox-dev



-- 
Peter Kriens                              Mob. +46705950899
34 Place René Nelli                       Tel. +33467871853
34670 Baillargues, France                 AOL: pkriens