Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Re: Suggestion: add Eclipse-UnpackBundlle: to manifest


The "override" could only go from "packed" to "unpacked", right? And, what would the advantage be of using "unpacked"? Faster disk loading?

And, BTW ... I agree, the plugin should definitely "spec" if its packed or not ... I've found its a bit difficult at times to "build one jar" using PDE ... as I have to look at feature to see what it should be, etc.




Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

03/28/2006 12:44 AM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject
Re: [equinox-dev] Re: Suggestion: add Eclipse-UnpackBundlle: to        manifest






yes, this is an interesting direction.  Looking at this a bit more generally there has been discussion of "overrides".  Under this model, the producer of a component (bundle, feature, ...) gets to spec what they think is the reasonable way to run/use/deploy/... their product but some outer scope defined by the consumer is able to override those values.  


Jeff



Mel Martinez <melm@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

03/27/2006 11:27 AM

Please respond to
Equinox development mailing list

To
equinox-dev@xxxxxxxxxxx
cc
Mel Martinez <melm@xxxxxxxxxx>
Subject
[equinox-dev] Re: Suggestion: add Eclipse-UnpackBundlle: to manifest







+1

This would solve a problem we have worried about and improve the
development scoping.  Although it is certainly a 'best practice' to
construct one's plugin for deployment both packed or unpacked, the fact is
that it is not a hard requirement to support both models.   The feature
developer should not be dictating this over the plugin developer since the
latter may not be able to support the mode the feature developer imposes '
after the fact'.  The correct model is that the setting in the feature.xml
should be considered a feature level preference, but it should defer to the
requirements of the plugin.  The suggestion below gives us a path toward
this correct model.

"Alex Blewitt" <alex.blewitt@xxxxxxxxx> wrote on 03/26/2006 12:00:07 PM:

> I'd like to propose an addition of Eclipse-UnpackBundle: to the
> Manfest.MF, in much the same way that Eclipse-AutoStart: is a
> documented entry in the manifest.
>
> The purpose would be to describe whether the bundle should be unpacked
> during installation, or left as a packed Jar file.
>
> Currently, the update manager determines whether a plugin/bundle
> should be unpacked based on an entry in its corresponding feature.xml.
> However, for bundles that are commonly shared between deployments
> (e.g. something like org.apache.log4j) it would be efficient to store
> this information in one place rather than many, since whether a bundle
> should be unpacked or not is a function of the bundle itself rather
> than the feature that hosts it.
>
> Since this entry would be unused at this time, perhaps it would be
> best described as a hint to the underlying platform rather than a
> mandatory entry. However, the PDE tooling could subsequently be
> updated to ensure that the feature.xml and bundle are in step with
> these values. Once the adoption becomes more widespread, an update
> manager that utilises this property would be able to install bundles
> and know whether to unpack them or not regardless of the feature(s)
> that they were associated with.
>

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


Back to the top