[news.eclipse.technology.ecp] 'Component based assembly' (Was: More on t

["Kenneth Ölwing" <kenneth@xxxxxxxxx>]

Hello all,

My name is Kenneth Olwing, and  I represent the Buckminster project at 
http://www.eclipse.org/buckminster. Also, see the wiki (links from the 
page). I want to introduce myself and Buckminster and hear of any opinions 
on how the yet-forming ECP community would relate to Buckminster and/or 
whatever other plans you have in the development/life cycle direction at 
this point.

Briefly, Buckminster aims at providing a development environment within 
Eclipse that is truly component aware (note that this is not supposed to 
necessarily be an all new way of doing things - Buckminster wish to be as 
non-intrusive as possible if users don't wish no more, for example by 
natively reading & understanding normal Eclipse artifacts like plugin.xml 
and the like. It can obviously be more capable, again if users wish to pour 
some effort in structuring). This transcends to aspects like dependency 
description and resolvement, scripted actions (like building) etc. We've 
been at this for over a year (and dumping >10 man years of previous attempts 
& experience in it :-). There's still a ways to go, but there's a lot of 
groundbreaking pieces in there.

I find the ECP (until new naming, I'll use this acronym) project interesting 
for the simple reason that it may provide a very good vehicle to bind 
together the runtime approach 'ECP' is primarily looking at (as I presently 
understand it), vs the development angle that Buckminster covers. Looking at 
the comments made by Igor, I'd agree that it's relevant to address 'all 
tiers' - it makes things a lot easier if there is some form of 'seamless' 
transition between development, test/qa, deployment, maintenance etc. While 
Buckminster is intended to be able to agnostically handle any language and 
any desired setup, it is probably obvious that it will best shine in a full 
Eclipse/OSGi setting. Therefore, the ECP approach of a general framework 
rhymes well in our opinion.

As an aside, concerning the discussion about use of 'component' as a term: 
yes, it's very generic, abstract and perhaps even overused. But for 
Buckminster, it makes perfect sense specifically for these reasons - 
Buckminster is very generic in its definition of what a component is, and 
that's as it should be. For example, we rather see things in terms for 
'component types' - which is an extension point, among many others.

Thank you,

ken1

"Igor Shabalov" <ishabalov@xxxxxxxxxx> wrote in message 
news:e0va44$hsl$1@xxxxxxxxxxxxxxxxxxxx
...snip...
>
> What about application life cycle? Our components may have full 
> design-time artifact inside (code, build scripts, documentation, tests 
> etc.).
>
> In all this cases we need (definition of) components, dependencies, 
> assembly, distribution etc, what essentially we all are talking about 
> here. So, we have to address all tiers!