Re: [eclipse-dev] Your plug-in may be a liability if...: ACTION REQUIRED

[Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>]

I think that here you are talking about
another problem, which is how does hibernate access classes and hbm files
from plugins that require hibernate. If this is the case, please see bug
87775.

Otherwise, the manifest should be maintained
to reflect accurately the dependencies of the library and what it exports.
PDE UI will help you to do that.

PaScaL

"Max Rydahl Andersen" <max.andersen@xxxxxxxxx>
Sent by: eclipse-dev-bounces@xxxxxxxxxxx

04/06/2005 12:55 PM

Please respond to
"General development mailing list of the Eclipse project."

To	"General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>
cc
Subject	Re: [eclipse-dev] Your        plug-in        may        be        a        liability        if...:        ACTION        REQUIRED/ACTION REQUISE

On Wed, 06 Apr 2005 18:48:09 +0200, Pascal Rapicault
 
<Pascal_Rapicault@xxxxxxxxxx> wrote:

> In the case of hibernate you unlikely want to re-export everything.
> After a quick look at hibernate, it seems that the only valuable thing
to
> export is the hibernate API packages, since the others are implementation
> details.

I'm using some parts of those, but anyhow its still to avoid having
a maintanence nightmare if e.g. Hibernate 3.0.1 comes out with a new
extra package for something that might be dynamically loaded via the  
configuration
of hibernate - how will plugins that does not list that explicit package
 
name
behave then ? Will they fail in loading that class ?

/max

>
>
>
>
>
>
> "Max Rydahl Andersen" <max.andersen@xxxxxxxxx>
> Sent by: eclipse-dev-bounces@xxxxxxxxxxx
> 04/06/2005 12:41 PM
> Please respond to
> "General development mailing list of the Eclipse project."
>
>
> To
> "General development mailing list of the Eclipse project."
> <eclipse-dev@xxxxxxxxxxx>
> cc
>
> Subject
> Re: [eclipse-dev] Your plug-in  may     be    
 a       liability if...:
> ACTION  REQUIRED/ACTION REQUISE
>
>
>
>
>
>
> On Wed, 06 Apr 2005 18:16:25 +0200, Wassim Melhem <wassimm@xxxxxxxxxx>
> wrote:
>
>> No equivalent to * in a manifest.mf.  For an informative
and
>> frighteningly
>> detailed response, see my comments below.
>
> ok i see the advantages for *plug-in* development.
>
> What i'm mostly worried about is that i have a plugin for the sole
> purpose of exposing all of hibernate and its dependent libraries to
> my other plugins.
>
> For that I *really* want '*' functionallity. Especially if I want
> to allow users to be able to put in a newer version of some library
> which might have a new package that the plugin needs by indirection.
> (before A.doX() called B.doY(), now A.doX() calls C.doQ() and B.doY()).
>
> So looking for solutions to this maintainence burden:
>
> Is there a way to explicitly update the manifest.mf to reflect any
> additional new packages ? (like "reexport" ?)
>
> Is there a better way now in 3.1 to load user libraries ? Like hibernate
> (which can be somewhat statically defined),
> but how about e.g. jdbc drivers which are only known at runtime (is
 
> custom
> urlclassloader still the only known solution ?)
>
> /max
>
>
>
>>
>>
>> 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
>>
>>
>> _______________________________________________
>> 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