Skip to main content

[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

To clarify, no one is voting against. Just trying to understand the
consequences once we have converted.
But it looks fine in term of redundancy, it is rather a move of some
details to another file.



                                                                           
             Wassim Melhem                                                 
             <wassimm@xxxxxx.c                                             
             om>                                                        To 
             Sent by:                  "General development mailing list   
             eclipse-dev-bounc         of the Eclipse project."            
             es@xxxxxxxxxxx            <eclipse-dev@xxxxxxxxxxx>           
                                                                        cc 
                                                                           
             04/06/2005 07:43                                      Subject 
             PM                        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."                                                 
                                                                           
                                                                           




>We end up in a situation where we have redundancy in description files.
Again, I cannot comment on the component.xml redundancy.  Please take it up
with our resident API czar.


>Isn't plugin.xml going soon to contain the package
>information, which will we used by PDE to set access rules, and could be
>used to populate the manifest.mf file ?

Not quite.  It's the manifest.mf file that will contain all that
information directly.
No more investments/enhancements are made by the runtime team for the
plugin.xml.
plugin.xml is only used for extensions and extension points.
All new runtime features go into the manifest.mf


>Is that something we can still do once converting as PDE requested ?
This question about the Main-Class header has already been answered by
Pascal.  The answer is yes.  Just append it to the file.

Let me reiterate that PDE did not request this.  It's the performance team
that did.
PDE was certainly the one to propose this well-crafted resolution though,
as this is our domain.
When we referred it to the full court, it was arguably the quickest
unanimous vote in the history of performance teams.
Then again, voting against it would have been like voting against a
resolution to save the environment.....or kittens :-)

 Wassim





             Philippe P Mulet
             <philippe_mulet@f
             r.ibm.com>                                                 To
             Sent by:                  "General development mailing list
             eclipse-dev-bounc         of the Eclipse project."
             es@xxxxxxxxxxx            <eclipse-dev@xxxxxxxxxxx>
                                                                        cc

             04/06/2005 06:27                                      Subject
             AM                        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."






I second Dirk's argument. We end up in a situation where we have redundancy
in description files. Isn't plugin.xml going soon to contain the package
information, which will we used by PDE to set access rules, and could be
used to populate the manifest.mf file ?
BTW, the component.xml is somewhat orthogonal, and has no impact either on
compile-time or runtime, it is an API spec for some other tool. Sadly, it
implies overhead, where some of it could be generated from plugin.xml.

Last question: can we put more information in the manifest.mf file ?
Currently, JDT/Core had one to allow jdtcore.jar to act as a batch
compiler:

Manifest-Version: 1.0
Main-Class: org.eclipse.jdt.internal.compiler.batch.Main

Is that something we can still do once converting as PDE requested ?




             Dirk
             Baeumer/Zurich/IB
             M@IBMCH                                                    To
             Sent by:                  "General development mailing list
             eclipse-dev-bounc         of the Eclipse project."
             es@xxxxxxxxxxx            <eclipse-dev@xxxxxxxxxxx>
                                                                        cc

             04/06/2005 10:31                                      Subject
             AM                        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."






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


_______________________________________________
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




Back to the top