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

[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

From: Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>
Date: Wed, 6 Apr 2005 12:48:09 -0400
Delivered-to: eclipse-dev@xxxxxxxxxxx
List-archive: <http://eclipse.org/pipermail/eclipse-dev>
List-help: <mailto:eclipse-dev-request@eclipse.org?subject=help>
List-subscribe: <https://dev.eclipse.org/mailman/listinfo/eclipse-dev>, <mailto:eclipse-dev-request@eclipse.org?subject=subscribe>
List-unsubscribe: <https://dev.eclipse.org/mailman/listinfo/eclipse-dev>, <mailto:eclipse-dev-request@eclipse.org?subject=unsubscribe>

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.

"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

Follow-Ups:
- Re: [eclipse-dev] Your plug-in may be a liability if...: ACTION REQUIRED/ACTION REQUISE
  - From: Max Rydahl Andersen

References:
- Re: [eclipse-dev] Your plug-in may be a liability if...: ACTION REQUIRED/ACTION REQUISE
  - From: Max Rydahl Andersen

Prev by Date: Re: [eclipse-dev] Your plug-in may be a liability if...: ACTION REQUIRED/ACTION REQUISE
Next by Date: [eclipse-dev] ProblemView
Previous by thread: Re: [eclipse-dev] Your plug-in may be a liability if...: ACTION REQUIRED/ACTION REQUISE
Next by thread: Re: [eclipse-dev] Your plug-in may be a liability if...: ACTION REQUIRED/ACTION REQUISE
Index(es):
- Date
- Thread

Breadcrumbs