Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [pde-dev] PDE Incubator "b3" project proposal

Agree with Pascal - I also think simplicity is the key requirement. 

I think the things everyone typically does wrt. building should be as as easy to use as the interactive edit-compile-debug/run cycle.
It should just "be there" and work, it is not until you want something "non default" you would have to edit something. And when you do have to edit something you should not have to completely switch to a different far more complex environment.

Looking forward to hearing more about Pascal's and Andrew’s vision...


On Jul 29, 2009, at 12:08 AM, Pascal Rapicault wrote:

Being partly responsible for where we are at with PDE Build and p2, I'm interested in participating in this effort at least from an advisory point of view and pass on the initial vision that Andrew and I had developed around those two technologies and the ideal separation that each release bring us closer to.

To many respect I'm excited by this project, however I'm concerned about two things:

1) the alignment of the objectives with the problems encountered by day to day developers. I think we need to have additional objectives that are more concrete:
* Simplicity. If there was only one thing that needed to be done, it would be that. I think this is a cross cutting effort and it has to be the main driver. Sure model transformation, traceability and all that are good things to have and are certainly things that lead to some degree of simplicity. However as I discovered attending several talks about build at OSGi DevCon in Zurich, people want dead simple tools and don't want to have to edit files to start. An example of such tool are the PAX tools for OSGi which are a bunch of helper scripts around Maven making it just trivial to setup a build environment. It may not have all the bell and whistles that PDE Build or Buckminster have but it seemed to be appreciated by the developers I have met. This last point brings me to OSGi.
* Relevance to OSGi. We have successfully promoted OSGi, however despite all our effort of tooling OSGi is still perceived too complex to work with when compared to plain Java. I think that a new build system has to be relevant to OSGi and address different ways of working (e.g. manifest first or project dependency first) and be more incremental.
* Relevance to e4. As e4 becomes more heterogeneous in terms of language (_javascript_, Java, CSS, Clojure, etc) a new build mechanism has to free us from the strong coupling that PDE Build has today on Java, and be able to produce various artifacts (bundles, WARs, flex files, etc).

2) the set of technologies being considered. I surely understand that initial proponents of this project have a vested interest and knowledge about PDE Build, Buckmister or p2. However I think that we have to be more inclusive of the technologies we are considering as potential replacement even if they are not coming from the Eclipse ecosystem or even if they are not a perfect match. Creating another build engine just because it is not initiated or done at eclipse will just alienate our community of users. Some of the technologies that are coming to mind at this point are:
* Maven / Maven Tycho. Over the years Maven became the defacto standard way of building Java projects. It may have things that you like and other that you don't however it works and has a good ecosystem. Also recently Maven has started providing top notch OSGi integration with its Tycho plug-in and finally on top of that, I believe that Maven 3 will be an OSGi application running on Equinox.
* PAX tools. Even though it is not a build engine in itself, it should be looked at for its attempt at simplifying things.
* Eclipse Athena. This should be looked at for the simplicity it provides and the kind of complexity (or indeed simplicity) that people are willing to deal with.

What do you think?

PaScaL

<graycol.gif>Re: [pde-dev] PDE Incubator "b3" project proposal


<ecblank.gif>
<22798545.gif>
<ecblank.gif>
Re: [pde-dev] PDE Incubator "b3" project proposal
<ecblank.gif>
Andrew Niefer
<ecblank.gif>
to:
<ecblank.gif>
Eclipse PDE general developers list.
<ecblank.gif>
07/28/2009 08:37 PM
<ecblank.gif>
<ecblank.gif>
Sent by:
<ecblank.gif>
pde-dev-bounces@xxxxxxxxxxx
Please respond to "Eclipse PDE general developers list."
<ecblank.gif>





I will also be adding my name to this project.

With the reminder that PDE/Build has its own history of backwards compatibility to maintain, I think it would be good discover what changes can be made to make it easier for other projects to extend and take advantage of what is available in build. Similarly, I would like to look at places where PDE/Build can provide points so that other bundles could contribute information to the build. Target platforms (https://bugs.eclipse.org/bugs/show_bug.cgi?id=284480) are a perfect example of this.

PDE/Build has never had much of an official API beyond what it exposes to PDE/UI., it would be good to identify which pieces are generally interesting and can be exposed to others.

-Andrew


From: Ian Bull <irbull@xxxxxxxxxxxxxxxxx>
To: "Eclipse PDE general developers list." <pde-dev@xxxxxxxxxxx>
Date: 07/28/2009 01:36 PM
Subject: Re: [pde-dev] PDE Incubator "b3" project proposal
Sent by: pde-dev-bounces@xxxxxxxxxxx





I am very excited about the b3 proposal and I would like to join the project. I have knowledge of p2, modeling and I'm getting better with PDE/Build ;). I have been thinking about the Eclipse build story for a while, and here are some random thoughts:

1. Eclipse has shown great leadership with respect to OSGi. Eclipse provides the reference implementation, arguably the most widely adopted OSGi platform, an excellent provisioning system and some of the best tool support for OSGi. I see b3 as an opportunity for the Eclipse community to design "the" build environment for OSGi.

2. Provide a consistent build model at all levels of abstraction. Whether your are building features, products, bundles or collections of things, providing a consistent model is key. Currently (with PDE/Build -- please don't take this as a criticism) consistency among build types is lacking. Different scripts and properties are used to build "seemingly" similar things. B3 provides an opportunity to review some of these inconsistencies and look for areas of improvement.

3. Review our abstraction story. Currently features (and in many respects, products) are primarily a build / deployment time construct (they have little use at run-time, and are seldom used during development time). B3 provides an opportunity to review this (and other build time abstractions). I'm not saying we should remove / rewrite the notation of features -- just review their role.

4. Bring target management to build. PDE has done an excellent job of bringing target management to the developers, this same functionality (and top-notch tooling) should be brought to the build infrastructure.

Cheers,
Ian

On Tue, Jul 28, 2009 at 7:47 AM, Chris Aniszczyk <
zx@xxxxxxxxxxxxxxxxx> wrote:
On Tue, Jul 28, 2009 at 4:57 AM, Pascal Rapicault <
Pascal_Rapicault@xxxxxxxxxx> wrote:
The web interface for newsgroup does not allow for new posts to be posted on eclipse.b3. Is this normal?

The newsgroup isn't created yet as this is just the draft of the project proposal. You can use this mailing list for comments now.

Cheers,

--
Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465

http://twitter.com/eclipsesource | http://twitter.com/caniszczyk

_______________________________________________
pde-dev mailing list

pde-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-dev




--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484

http://eclipsesource.com | http://twitter.com/eclipsesource_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/pde-dev

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


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

GIF image


Back to the top