[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-update-dev] Investigating some alternative update manager
|
As somebody who was there through all the iterations of the Update Manager,
let me assure you that we didn't like features as an idea ourselves.
However, no matter how we tried, we could not shoehorn the distinct
functionality that Mark describes below into a simple plug-in extension
point. Of course, you can cram most of the feature.xml content into an
extension, but all you are doing is overloading the plug-in concept with
addition semantics not initially anticipated. Also note that you will hit
bootstrapping problems because features are used on the server to describe
what can be downloaded. At that point, OSGi runtime is not running and you
need to parse plugin.xml yourself. Essentially you will end up doing
exactly what you are doing today (and the tooling would need to have
specialized knowledge of the 'feature' extension point, which just moves
the problem around but does not makes the code smaller).
No matter how you slice it, you need to be able to provide a 'bill of sale'
for a bunch of plug-ins/bundles you want to move over the wire and install
somewhere. This 'bill of sale' listing the bundles and possibly providing
additional information needs to be somewhere outside of these bundles. If
you put it in one of the bundles, you will need to somehow designate this
bundle as 'special' so that the transporting software can peek into its
plugin.xml and extract the shipping info. What you just did was
re-introduce features by asking this bundle to 'play' the feature role.
Once your product grows, you will realize you need to provide groups of
bundles that provide a distinct function and can be grouped an reused in
larger groups in many interesting ways. Pretty soon, you will check all the
feature spec checkboxes.
You (Alex) do raise an important issue regarding small contributors who
want to publish single plug-ins. For them, having to provide a feature
seems like an overkill. For people who are shipping more complex products,
features make a lot of sense and are very useful. If Update Manager was
able to handle a plug-in by generating a transient feature on the fly, it
would certainly help. However, I don't think that ditching features (or any
grouping concept that the community may come up with) is going to help more
ambitious Eclipse projects.
Regards,
Dejan Glozic, Ph.D.
Manager, Eclipse Development 1A
D1/R0Q/8200/MKM
IBM Canada Ltd.
Tel. 905 413-2745 T/L 969-2745
Fax. 905 413-4850
Mark_Melvin@amis.
com
Sent by: To
platform-update-d "Eclipse Platform Update component
ev-bounces@eclips developers list."
e.org <platform-update-dev@xxxxxxxxxxx>
cc
mjh@xxxxxxxx, remy.suen@xxxxxxxxx,
09/14/2006 09:33 Francois Granade
AM <francois@xxxxxxxxxxx>, "Eclipse
Platform Update component
developers list."
Please respond to <platform-update-dev@xxxxxxxxxxx>
"Eclipse Platform Subject
Update component Re: [platform-update-dev]
developers list." Investigating some alternative
<platform-update- update manager
dev@xxxxxxxxxxx>
While I think that I agree with you that features can be treated as
bundles, and it would be nice in some cases to just update a single plugin
- please don't remove the functionality that features provide. It is nice
to be able to install a whack of plugins as a "feature", as well as
associate behaviour to a group of plugins (like install handlers) - and
features currently handle this quite well. Also, the ability to nest
features and provide common blocks of functionality as sub-features is
quite useful.
Mark.
----------------------------------------------------------
"Alex Blewitt"
<alex.blewitt@xxxxxxxxx>
Sent by: To
platform-update-dev-bounces@e "Eclipse Platform Update component
clipse.org developers list."
<platform-update-dev@xxxxxxxxxxx>
cc
09/14/2006 03:56 AM mjh@xxxxxxxx, Francois Granade
<francois@xxxxxxxxxxx>, Benjamin
Muskalla <b.muskalla@xxxxxxx>,
Please respond to remy.suen@xxxxxxxxx
"Eclipse Platform Update Subject
component developers list." Re: [platform-update-dev]
<platform-update-dev@eclipse Investigating some alternative update
.org> manager
I'd like to be involved with this effort. However, I think that we
look at providing updates to bundles/plugins, rather than features.
Features are an out-moded concept that could easily be handled by a
feature-bundle. Besides which, there are many more uses that people
will be able to have to update individual bundles (e.g. a
xerces/log4j/junit/testng implementation) and the current
'feature-based' approach is wrong. (For example, there's a 'Batik'
feature and a 'Batik' plugin currently as part of (I think) BIRT;
there's a Xerces feature for the Xerces plugin etc. The only reason
these features are there is because the update manager can't handle
updating bundles/plugins.
Secondly, I really think that each bundle-version should be able to
produce an Atom entry (see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=127236 and
http://alblue.blogspot.com/2006/09/eclipse-why-update-site-should-be-atom.html
).
You can then amalgamate as many plugins as you want into an Atom feed;
you then can use Atom feeds as the URL for the updates for a bundle.
(A feature could then be a single Atom feed, for example.)
Note that Atom feeds are valid XML documents; are namespaced; and can
be used to transmit any arbitrary XML content; so whatever sub-XML
format is used to represent a bundle and its required dependencies
(and versions), the Atom entry can be used to transport it in a known
header and with known update time/name/metadata associated with it
(including, for example, copyright information and where it was
originally downloaded from). As an extra bonus, Atom-parsing APIs are
available already, and aggregators (e.g. Planeteclipse) are known; an
internal update site could be expressed as an atom aggregator.
Alex.
On 14/09/06, Philippe Ombredanne <pombredanne@xxxxxxxx> wrote:
> All:
> just a heads up.
> We are embarking on trying to provide an alternative update UI, and
> possibly alternative transports, like BitTorent (using Remy's clean room
> Bittorent implemantion
> http://wiki.eclipse.org/index.php/ECF_BitTorrent_Provider ), and http
> refinements (suspend/resume, threading).
> The fun takes place mostly on IRC in and #easyeclipse
> We did put a wiki page there :
> http://eclipsewiki.editme.com/UpdateManager
> (feel free to comment/add to the page)
> and the code (early, crappy and mostly non working) is there:
> http://easyeclipse.cvs.sourceforge.net/easyeclipse/easyeclipse/easyupdat
> e/
> This is a community effort, with the intent to :
> - provide some working code
> - be a place for experimentation
> - provide alternative inputs for any revamp work that could happen in
> the platform itself.
> Peace.
>
>
> --
> Cheers
> Philippe
>
> philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
> nexB - Open by Design (tm) - http://www.nexb.com
> http://easyeclipse.org - irc://irc.freenode.net/easyeclipse
>
>
>
> _______________________________________________
> platform-update-dev mailing list
> platform-update-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-update-dev
>
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev
AMI Semiconductor - "Silicon Solutions for the Real World"
NOTICE:
This electronic message contains information that may be confidential or
privileged. The information is intended for the use of the individual or
entity named above. If you are not the intended recipient, please be aware
that any disclosure, copying, distribution or use of the contents of this
information is prohibited. If you received this electronic message in
error, please notify the sender and delete the copy you received.
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev
