[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.alf] Re: Upcoming validation release review

Tim Wagner wrote:
"If ALF includes developer or client side tools in its charter, shouldn't 
you be able to implement them in the open source project itself, as 
examples?...I'm not able to reconcile the inability to test/demonstrate/vet 
the approach in an open source fashion with the idea that it covers the 
entire lifecycle of an application, a very rich and fertile area for tooling 
and user support."

Hi, Tim

You make a good point - the ALF project should look for ways to use its own 
tooling as exemplars.  However, I believe we overlooked that opportunity for 
several reasons:
  1. Usefulness - Since much of the tooling needed to administer ALF is 
already available as Eclipse plug-ins (e.g. BPEL designers) and ALF is 
reusing what is available, ALF required very little in the way of tooling to 
administer it.  Instead, ALF focused more on tools with broader 
applicability and utility.
  2. Ability to illustrate an interesting Use Case - In contrast to general 
purpose tools with a broad audience, such as CVS, Subversion, and Bugzilla, 
the ALF Administration tooling is targeted at a rather narrow audience - an 
administrator of an ALF Environment.  While we could have invented a Use 
Case involving the ALF Admin tool, the community had identified many other 
real life Use Cases involving existing open source and commercial tools, so 
we focused on the real life scenarios.

So it it not that ALF can't demonstrate integrations using its own 
technology, but simply that there were more practical integrations that 
would be of more use to the community.  Clearly we missed an educational and 
testing opportunity in not using the the ALF admin plug-in as an example, 
but I would argue we focused on tools that have more general utility to the 
community.

We also had a larger concern in mind which would have steered us away from 
ALF-enabling the ALF admin plug-in.  We have been coordinating with the 
Eclipse Corona project which was focused more directly on web service 
enabling plug-ins, and had discussed integrations with Corona, such as an 
Event bridge to map platform events into ALF events.  To avoid overlap with 
the work of the Corona project, we  focused more on server-based 
integrations with the expectation that Corona would supply infrastructure 
that would make ALF enablement of Eclipse plug-ins easier.  But please be 
assured that no matter how it is accomplished, we view Eclipse plug-ins as 
important participants in ALF.

Regards,
Brian

Brian Carroll
Architect, Eclipse ALF project
www.eclipse.org/alf
Serena Fellow
Serena Software
(ofc)  (503) 617-2436
(cell)  (503) 318-2017
bcarroll@xxxxxxxxxx