[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-dev] Your plug-in may be a liability if...: ACTION REQUIRED/ACTION REQUISE
|
No equivalent to * in a manifest.mf. For an informative and frighteningly
detailed response, see my comments below.
Wassim.
"Max Rydahl
Andersen"
<max.andersen@jbo To
ss.com> "General development mailing list
Sent by: of the Eclipse project."
eclipse-dev-bounc <eclipse-dev@xxxxxxxxxxx>
es@xxxxxxxxxxx cc
Subject
04/06/2005 04:53 Re: [eclipse-dev] Your plug-in may
AM be a liability if...:
ACTION REQUIRED/ACTION REQUISE
Please respond to
"General
development
mailing list of
the Eclipse
project."
On Wed, 06 Apr 2005 10:31:14 +0200, Dirk Baeumer <dirk_baeumer@xxxxxxxxxx>
wrote:
Is there a way via an manifest to just say * for packages as was the
possiblity before ?
/max
> I totally agree that generating the manifest.mf file on startup and
> adding
> information that can be statically provided should be avoided to speed-up
> startup performance. However, I am a little bit worried about the fact
> that
> we are getting more files which contain package names and that we don't
> add
> tooling to keep them in sync. I am aware of the following:
>
> component.xml file: given that this only contains real API packages it
> might not change very often
> manifest.mf: the list of exported packages. Since we exported all
> packages in the past I think we can't change this so late in the
> cycle.
> IMO this will "break" a lot of existing clients (even Eclipse will not
> start any longer). So from my understanding we have to enumerate all
> packages (this is what at least runtime does when it creates missing
> manifest files).
> access restrictions for the compiler: I don't know exactly where this
> information will be stored but from the discussion I had I got the
> feeling that this goes into the plugin.xml file. Since we have to
> export
> all package (see above) we have to provide access restrictions for all
> packages as well.
>
> I agree that automatically adding an entry for newly created packages
> isn't
> what a user expects. However, If I rename a package and there is a
> reference in some other file (manifest.mf, component.xml,
> access-restriction,...) I as a user would expect that the rename updates
> these references as well. Since the technology to do this is available I
> don't understand why we don't do it.
>
> Dirk
>
>
>
> John Arthorne
> <John_Arthorne@ca
> .ibm.com>
> To
> Sent by: "General development mailing list
> eclipse-dev-bounc of the Eclipse project."
> es@xxxxxxxxxxx <eclipse-dev@xxxxxxxxxxx>
>
cc
> 05.04.2005 23:45 Subject
> Re: [eclipse-dev] Your plug-in may
> be a liability if...:
> Please respond to ACTION REQUIRED/ACTION REQUISE
> "General
> development
> mailing list of
> the Eclipse
> project."
> <eclipse-dev@ecli
> pse.org>
>
>
>
>
>
> I'd like to add a capsule summary to Wassim's informative but
> frighteningly
> detailed response. You only need to update manifest.mf when new API
> packages are added, not for internal packages. This is hopefully a rare
> occurrence for most plugins. Further, the failure mode if you forget to
> update the manifest is very clear: no other plugins will be able to load
> classes in that package. Core and SWT have been using manifests since
> before the 3.0 release and haven't found it to be a particular burden.
>
> I should add in defence of Wassim that he didn't just wake up this
> morning
> and decide to create pain for everyone (at least, I don't think he did).
> The performance dynamic team decided this was an important step to
> improving our startup, class loading, and self-hosting performance in
> 3.1.
> The benefits justify the trivial work required.
>
>
>
> Wassim
> Melhem/Toronto/IBM@IBMCA
>
To
> Sent by: "General development mailing list
> of
> eclipse-dev-bounces@ecli the Eclipse project."
> pse.org <eclipse-dev@xxxxxxxxxxx>
>
cc
> 05/04/2005 05:04 PM Subject
> Re: [eclipse-dev] Your plug-in may
> be a liability if...:
> Please respond to ACTION REQUIRED/ACTION
> "General development REQUISE
> mailing list of the
> Eclipse project."
>
>
>
>
>
>> Will going with an explicit manifest.mf require manually maintaining the
>> list of packages imported/exported by a plug-in?
>
> The ability of a plug-in to import (depend on) a package is similar and
> complementary to requiring another plug-in.
> PDE therefore cannot manage it for you, but the manifest validator will
> flag any unresolved dependencies in both your list of required plug-ins
> and
> import packages list (if any).
>
> Exported packages is the only difference you will notice between your
> usage
> of a plugin.xml and a manifest.mf.
> We are all used to exporting entire libraries and making them visible to
> clients.
> In a manifest.mf, there is no equivalent to the plugin.xml's <export
> name="*"/>. You have to explicitly enumerate all the packages you want
> to
> make visible to your clients.
>
> Although this might at first seem like it's painful, here is how Jeff
> (of
> the Runtime team fame) articulates the benefits of Export-Package:
> "It (Export-Package) does have benefits. Since you explicitly list the
> packages, the runtime always knows exactly where to look for classes in a
> given package.
> Without this explicit information, we would either
> a) we have to open the jars and scan to discover packages (we do this now
> in the converter and it's pretty painful).
> b) scan the plug-ins at classload time and see if they have what we
> want.
> This was the Eclipse 2.1 behavior. When we moved to 3.0 and the new
> behaviour, we saw quite a noticeable improvement in classload time."
>
> We contemplated the idea of having PDE implicitly manage your
> Export-Package for you, but there were more than one good reason to not
> get
> into that business:
>
> 1. As a product, Eclipse is moving away from this whole <export
> name="*"/>
> business in an effort to enforce our API, so this explicit listing of
> packages to be exported is exactly what we want.
>
> 2. The plug-in developer is the only one who knows what packages he wants
> to expose to clients. If you create a new package, who's to say that you
> want to add it to the list? Do you really want PDE to prompt you every
> time you create a new package? do you really want PDE to implicily
> modify
> your manifest.mf and dirty your file without your consent? This is a
> little too much magic, even for PDE. Since we can never guess what the
> developer wants, we prefer to stay out of that business. We can flag
> more
> stuff on the manifest.mf if you want, but to manage Export-Package
> implicitly would be like triggering Refactoring implicitly. It's not a
> function that you want invoked without your consent.
>
> In any event, we always strive for the plug-in development experience to
> be
> as pleasant as it can be, and we haven't had too much feedback from
> manifest.mf users yet.
> Adoption of a manifest.mf is the direction in which we are going and we
> are
> not looking back. So please feel free to open bug reports and ask for
> new
> features.
>
>
>> Why isn't the manifest.mf file generated by the build (releng), if no
> manifest
>> file exists. This would speed up start times as well.
>
> I guess it can be. But this would only alleviate the startup problem.
>
> What is left would be the overhead imposed on PDE by plug-ins in the
> workspace that don't have a manifest.mf
>
> Let me give you a very brief glimpse into what currently happens under
> the
> covers:
>
> The Eclipse runtime is manifest.mf-centric and so is PDE since we
> simulate
> an environment that is as close as possible to the runtime.
>
> So if your plugin does not have a manifest.mf at development time, we
> have
> to convert it to a form that the runtime understands to maintain our
> state
> up-to-date.
> Every time you save a plugin.xml, an implicit conversion takes place.
> That is the painful conversion Jeff refers to above. How many times do
> you
> modify a plugin.xml? That tells you how many conversions we have to do.
>
> Also, for a while now (since M4), developers rise and sleep under the
> blanket of reassurance from PDE that they never have to launch a runtime
> workbench with -clean ever again.
> This was a gigantic improvement over the brute force launch with -clean,
> especially when you are launching with thousands of plug-ins.
> However, the cost of the bookkeeping required on the part of PDE to
> provide that reassurance is > 0, and thus technically an overhead.
>
>
> With PDE tooling in place and 3.1 being a performance release, that is
> why
> we called for the immediate adoption of a manifest.mf
>
>
> Wassim.
>
>
>
>
>
> Dirk Baeumer
> <dirk_baeumer@ch.
> ibm.com> To
> Sent by: "General development mailing list
> eclipse-dev-bounc of the Eclipse project."
> es@xxxxxxxxxxx <eclipse-dev@xxxxxxxxxxx>
> cc
>
> 04/05/2005 12:24 Subject
> PM Re: [eclipse-dev] Your plug-in may
> be a liability if...:
> ACTION REQUIRED/ACTION REQUISE
> Please respond to
> "General
> development
> mailing list of
> the Eclipse
> project."
>
>
>
>
>
>
> Wassim,
>
> if we have to track additions and renames of packages manually then there
> seems to be some risk that manifest.mf file gets easily out of sync. Why
> isn't the manifest.mf file generated by the build (releng), if no
> manifest
> file exists. This would speed up start times as well.
>
> Thanks
>
> Dirk
>
>
>
> Nick Edgar
> <Nick_Edgar@xxxxx
> m.com> To
> Sent by: "General development mailing list
> eclipse-dev-bounc of the Eclipse project."
> es@xxxxxxxxxxx <eclipse-dev@xxxxxxxxxxx>
> cc
>
> 05.04.2005 17:54 Subject
> Re: [eclipse-dev] Your plug-in may
> be a liability if...: ACTION
> Please respond to REQUIRED/ACTION REQUISE
> "General
> development
> mailing list of
> the Eclipse
> project."
> <eclipse-dev@ecli
> pse.org>
>
>
>
>
>
>
> Wassim,
>
> Will going with an explicit manifest.mf require manually maintaining the
> list of packages imported/exported by a plug-in?
> Or does PDE make that a pleasant experience too?
>
> Thanks,
> Nick
>
>
>
>
> Wassim Melhem/Toronto/IBM@IBMCA
> Sent by: eclipse-dev-bounces@xxxxxxxxxxx
> 04/05/2005 11:39 AM
> Please respond to
> "General development mailing list of the Eclipse project."
>
>
> To
> eclipse-dev@xxxxxxxxxxx
> cc
>
> Subject
> [eclipse-dev] Your plug-in may be a liability if...: ACTION
> REQUIRED/ACTION REQUISE
>
>
>
>
>
>
> All Eclipse teams,
>
> If you have not already done so, please plan on creating a manifest.mf
> for
> your plug-in for NEXT WEEK's I-build.
>
> To do so:
> 1. Open your plugin.xml/fragment.xml in the PDE manifest editor.
> 2. In the Plug-in Content section of the Overview page, click on the
> 'Create an OSGi bundle manifest' link.
> This will create a manifest.mf file, trim down your plugin.xml and
> update
> your build.properties.
> 3. Save and check in the changes into HEAD.
> DONE!
>
> At that point, you will notice that the first three pages of the manifest
> editor have changed and you will be able to explore many of the cool
> runtime capabilities that you probably did not even know they existed.
>
>
> Please note that:
>
> 1. If your plug-in does not have a manifest.mf, you are (and always have
> been) an overhead for the runtime, and you are (and always have been)
> nothing short of a liability to PDE.
> So startup, launching, etc. and many of your day-to-day self-hosting
> activities will become significantly faster once you convert.
>
> 2. PDE tooling makes the conversion process transparent, and your
> development process afterwards will not be affected in any way.
> For example, when you use the plug-in editor to edit your plug-in's
> manifest files, PDE takes care of writing the data to the right files.
>
> 3. We are NOT suggesting that a plug-in will not work in 3.1 if it
> doesn't
> have a manifest.mf.
> PDE will continue to make your plug-in experience as pleasant as it has
> always been if you don't have one.
>
> 4. As of next week's I-build, the default option to create one with a
> manifest.mf in the New Plug-in Project wizard will be turned on, as this
> is
> the recommended format for 3.1.
>
>
> If you have any questions, please send them to this list.
>
>
> To sum up:
>
> If your plug-in does not have a manifest.mf, it ain't happening.
>
>
>
> _______________________________________________
> eclipse-dev mailing list
> eclipse-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
>
>
> _______________________________________________
> eclipse-dev mailing list
> eclipse-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
>
>
> _______________________________________________
> eclipse-dev mailing list
> eclipse-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
>
>
> _______________________________________________
> eclipse-dev mailing list
> eclipse-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
> _______________________________________________
> eclipse-dev mailing list
> eclipse-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
>
>
> _______________________________________________
> eclipse-dev mailing list
> eclipse-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/eclipse-dev
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
max@xxxxxxxxxxxxx
http://hibernate.org
JBoss Inc
max.andersen@xxxxxxxxx
http://jboss.com
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev
