[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [platform-update-dev] Investigating some alternative update manager
|
Dejan Glozic wrote on Thursday, September 14, 2006 7:31 AM
> 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.
> 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.
Agreed , we need the notion of a set for packaging no matter what.
And as long as it is not something that the base framework (ie OSGi) is
aware, whatever replacement could be invented would end up looking like
a feature :-P
Hence the reason why we would not want to replace it for now on this
small exploratory project.
Hopefully we can come with some ideas, and who knows, our code may not
be to shabby that it could help a bit.
Just replacing one abstraction by another would just be a waste imho,
however elegant that new abstraction would be.
And there may be just *a few* existing update site out there that still
need love ;-)
> If Update Manager was
> able to handle a plug-in by generating a transient feature on
> the fly, it would certainly help.
The idea of generating a transient feature is interesting....hummm...
Yet for now, we just would like to experiment with alternate UI and
transports and be plug-compatible, no changes required.
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
> -----Original Message-----
> From: platform-update-dev-bounces@xxxxxxxxxxx
> [mailto:platform-update-dev-bounces@xxxxxxxxxxx] On Behalf Of
> Dejan Glozic
> Sent: Thursday, September 14, 2006 7:31 AM
> To: Eclipse Platform Update component developers list.
> Cc: mjh@xxxxxxxx; remy.suen@xxxxxxxxx;
> platform-update-dev-bounces@xxxxxxxxxxx; Francois Granade;
> Eclipse Platform Update component developers list.
> Subject: Re: [platform-update-dev] Investigating
> somealternative 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-sho
> uld-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
>
>
> _______________________________________________
> platform-update-dev mailing list
> platform-update-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-update-dev
>
>
>
