RE: [provisioning-dev] Provisioning going forward

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

I just wanted to clarify the project
intersections list.  Creating this list wasn't a "design by committee"
exercise. Many people with existing open and proprietary technologies came
to the workshop, and this list was just an attempt to identify where the
common areas of interest are between these existing technologies. Then,
going forward, the people who have an interest in those areas can collaborate
on a common technology, under whatever project is appropriate for that
area. I.e., this wasn't an attempt to see how we can mash up these existing
technologies and code into a single blob.

I agree with you that the Equinox provisioning
work is important, as it will likely define the basic foundation on which
other work is built. However, I disagree that everyone needs to focus on
this area alone. There are use cases that lie outside the scope of the
Equinox work, and there is plenty of room for projects to build interesting
new things on top of that foundation. In fact, having other projects building
on the Equinox foundation in parallel is probably the best (only?) way
to ensure that the basic API and metadata is rich and extensible enough
to build upon in the future.  As with the initial Eclipse platform,
that was built in parallel with exemplary extensions (JDT and PDE), the
other provisioning work going on in open and closed source at the same
time will help make the underlying foundation much stronger.

John

"Philippe Ombredanne" <pombredanne@xxxxxxxxx>
Sent by: provisioning-dev-bounces@xxxxxxxxxxx

17/04/2007 08:48 PM

Please respond to
pombredanne@xxxxxxxxx; Please respond to
"Developer discussions for provisioning \(Update Manager\)        initiatives" <provisioning-dev@xxxxxxxxxxx>

To	"'Developer discussions for provisioning \(Update Manager\)initiatives'" <provisioning-dev@xxxxxxxxxxx>
cc	wayne.beaton@xxxxxxxxxxx
Subject	RE: [provisioning-dev] Provisioning going forward

Tim:
I am all with you.
I am a pragmatist, and when it comes to open source , there is only one
truth: the code.
Equinox has a code base, and Maya will have one soon. (That I am
anxious/excited to checkout ASAP if possible)
I highlighted those. Anyone else that has a code base now, and a plan to
make it grow has my respect.
So I am cool. You are cool. 
(Note that BTW, we have one too @ easyeclipse, as we sponsored an intern
last summer to work on a replacement to the update manager, it was fun
stuff, but I do not think it is worthy pursuing for now).

Yet I am worried when I see a gadzillion of projects intersections: it
smells like design by comittee to me. (bad smell)
Variations one one theme and one code base makes sense, as long as it is
clear that there is one theme and code base.
Because being a pragmatist, the solution that is part of the core SDK
will be the most widely distributed and available.
And it will win. So we better make it good, solid and the point of first
focus, rather than diluting efforts (beyond existing code base like
Maya).
Or else we can end up with yet another partially useful and broken story
that has been the update manager so far.

Wa

As a side note, I am the admin for the Google Summer of Code @ Eclipse,
together with Wayne Beaton.  Among the 21 students that have been
selected to contribute to Eclipse this summer, there are a couple which
are closely related to provisioning.
*Eclipse web interface (with a possible use case to trigger provisioning
from an arbitrary web page in any web browser)
*New Update manager UI (which will focus to bring a face to Equinox
provisioning)
*An auto-configuration plugin for Eclipse (in a more holistic view of
provisioning, to get automated preferences and discovered services
configured)
*Java Executable Wrapper Plugin for Eclipse (vaguely related)
*WebDAV EFS Implementation ( a potential transport)
*Semantic-aware software component provisioning: actually reusing
software ( to define a component ontology)

I invite everyone to check out those abstract and stand by to support
and help those students and their mentors when their work will start in
late May, as they can contribute small code bricks to the larger
edifice. The best way to get plugged in the short term is to join
#eclipse-soc on freenode.
http://code.google.com/soc/eclipse/about.html


-- 
Cheers
Philippe
http://easyeclipse.org - http://phpeclipse.net - http://eclipse.org/atf
philippe ombredanne @ eclipse.org
philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com 
nexB - Open by Design (tm) - http://www.nexb.com 




> -----Original Message-----
> From: Tim Webb (tiwebb) [mailto:tiwebb@xxxxxxxxx] 
> Sent: Tuesday, April 17, 2007 11:14 AM
> To: pombredanne@xxxxxxxxx; Developer discussions for 
> provisioning (Update Manager)initiatives
> Subject: RE: [provisioning-dev] Provisioning going forward
> 
> 
> Philippe,
> 
> Without a doubt everything will ultimately be built on top of the
> Equinox provisioning work as it provides the key enabling technology
> that will provide both consistency and enablement for a variety of
> services.  That said, it is unlikely that Equinox's scope will
(or
> should) grow to cover the full set of use cases that will ultimately
> need to be supported in a the full Eclipse provisioning solution.
> Instead, I would look at Equinox to provide a rich set of capabilities
> for provisioning and then certain projects such as Maya to provide
> additional user interfaces and concrete implementations to 
> meet specific
> user scenarios -- in the case of Maya being targeted for organization
> and enterprise provisioning.
> 
> To pick a particular example, certain consumers of Eclipse require
> central management.  This is an area that will likely 
> continue to reside
> in the Maya project even as the Equinox project evolves.  Similar
to
> Equinox having extensibility, so will the central server 
> component in a
> provisioning system to enable capabilities such as licensing and
> governance.  I personally see the continued need for multiple
projects
> to be successful if we are hoping to have a successful end-to-end
> provisioning story for the 3.4 timeline.  From the workshop,
we
> identified multiple areas of intersection between projects.  
> From those
> intersections we will next be splitting out work to be 
> performed in the
> various provisioning projects.  
> 
> Regarding where to focus attention, I'd suggest focusing it 
> from a given
> interest or need instead of project and then we can work as a 
> community
> to determine which project is the right home for the near term to
> support development of that component.  Once the projects 
> mature out of
> incubator status, we may then decide to restructure project placements
> but only once we've better defined and delivered on the base
> provisioning needs for Eclipse.  At the end of the day, there
are many
> areas of provisioning as was highlighted by discussions at 
> the workshop.
> 
> I absolutely agree that we need to make sure the Equinox provisioning
> work is very successful but I wouldn't want to do that at the 
> expense of
> the other provisioning work needed.  In addition, as we found
at the
> workshop, by talking through projects like Maya, IBM's 
> Install Manager,
> SmartUp and other technologies represented, we were able to further
> mature and identify needs that would be required at the Equinox level.
> Continuing to move the entire provisioning solution forward will help
> ensure we have not only a successful base story to replace 
> what we have
> today but a rich platform that will meet needs of the future.
> 
> Cheers,
> Tim
> 
> -----Original Message-----
> From: provisioning-dev-bounces@xxxxxxxxxxx
> [mailto:provisioning-dev-bounces@xxxxxxxxxxx] On Behalf Of Philippe
> Ombredanne
> Sent: Tuesday, April 17, 2007 10:51 AM
> To: provisioning-dev@xxxxxxxxxxx
> Subject: [provisioning-dev] Provisioning going forward
> 
> Hi all:
> I could not join the provisioning workshop last week, so I 
> did read all
> the posts I could find and here is how I have reformulated the
> conclusion for me:
> - Equinox is the way to go for provisioning and will be the core
> platform way. Everyone will contribute and/or migrate to that.
> - Maya does address some specific use cases and provides a non
> Equinox-based solution for now, but will also migrate to Equinox
> provisioning in a near future, and have specific use cases 
> for Equinox.
> 
> So we all need to focus and concentrate our energies behind Equinox,
> since it will be lowest common denominator.
> Fair enough?
> 
> -- 
> Cheers
> Philippe
> http://easyeclipse.org - http://phpeclipse.net - 
> http://eclipse.org/atf
> philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com 
> nexB - Open by Design (tm) - http://www.nexb.com 
> 
> 
> _______________________________________________
> provisioning-dev mailing list
> provisioning-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/provisioning-dev
> 

_______________________________________________
provisioning-dev mailing list
provisioning-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/provisioning-dev