RE: [platform-update-dev] Investigating some alternativeupdate manager

["Philippe Ombredanne" <pombredanne@xxxxxxxx>]

Mark_Melvin@xxxxxxxx wrote on Thursday, September 14, 2006 6:34 AM
>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.  
Agreed, that is why for now, even if there is some impedance issues
between the features and OSGi, there should be quite a bit of thinking
to be done before throwing them away.
IMHO anything that would not have some core support in OSGi would mots
likely just end up re-coding features in some else, yet very similar.

>Also, the ability to nest features and provide common blocks of 
>functionality as sub-features is quite useful. 
Note that there some abuse of nesting features, or rather not nesting
but "require" features dependencies  when someone express a dep on a
feature packaged by another project.
I have seen Mylar, TPTP, WTP and many projecst make a require feature on
the platform.
Which means those projects are not only creating a dep on the bundles
which is fine but also on the way those bundles are grouped/packaged
which is rhater bad imho.
--
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
Mark_Melvin@xxxxxxxx
Sent: Thursday, September 14, 2006 6:34 AM
To: Eclipse Platform Update component developers list.
Cc: mjh@xxxxxxxx; remy.suen@xxxxxxxxx; Francois Granade; Eclipse
Platform Update component developers list.
Subject: Re: [platform-update-dev] Investigating some alternativeupdate
manager



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: platform-update-dev-bounces@xxxxxxxxxxx 
09/14/2006 03:56 AM Please respond to
"Eclipse Platform Update component developers list."
<platform-update-dev@xxxxxxxxxxx>

To"Eclipse Platform Update component developers list."
<platform-update-dev@xxxxxxxxxxx> 
ccmjh@xxxxxxxx, Francois Granade <francois@xxxxxxxxxxx>, Benjamin
Muskalla <b.muskalla@xxxxxxx>, remy.suen@xxxxxxxxx 
SubjectRe: [platform-update-dev] Investigating some alternative update
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-ato
m.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.