| [news.eclipse.technology.ecp] Re: 'Component based assembly' (Was: More on the project name, and relationship to Rich Server Platform) |
Hello, Kenneth!
Thank you at advance, Igor.
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!