Bndtools 2.2+ will be based on Eclipse 3.7 (Indigo)

[Neil Bartlett]

Dear Bndtools users,

I have decided to move Bndtools forward to depend on version 3.7 of Eclipse, also known as Indigo. Since the beginning we have always supported a very wide range of Eclipse versions -- currently all the way from 3.5 (Galileo) up to 4.3 (Kepler). However there are a few features in 3.7 that I would like to start taking advantage of. Therefore starting in version Bndtools 2.2 we will build against Indigo and also support Juno and Kepler... support for Galileo and Helios will be dropped.

Note that this does NOT affect the imminent 2.1 release, it will have the same dependencies as 2.0.

Regards,
Neil

[Marcel Offermans]

On Apr 4, 2013, at 15:27 , Neil Bartlett <njbar...@gmail.com> wrote:

> I have decided to move Bndtools forward to depend on version 3.7 of Eclipse, also known as Indigo. Since the beginning we have always supported a very wide range of Eclipse versions -- currently all the way from 3.5 (Galileo) up to 4.3 (Kepler). However there are a few features in 3.7 that I would like to start taking advantage of. Therefore starting in version Bndtools 2.2 we will build against Indigo and also support Juno and Kepler... support for Galileo and Helios will be dropped.
>
> Note that this does NOT affect the imminent 2.1 release, it will have the same dependencies as 2.0.

Just to let you know, I would not care if we started depending on 4.x completely. After all, 3.x is being phased out and as far as I can see, the 4.x APIs are a lot nicer to use.

Greetings, Marcel

[Paul Bakker]

+1 for dropping 3.x completely soon. Do we have any current usage numbers?

Cheers,

Paul

> --
> You received this message because you are subscribed to the Google Groups "bndtools-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Ferry Huberts]

Marcel, Paul and I discussed this during EclipseCon and we agreed that
we would like to go for 4.x APIs only.
We also concluded that there would be no rush in doing that, even though
we preferred doing it a.s.a.p.

Personally I think it would be a good idea to target this for the end of
the year, since 3.x will be phased out by then.
And after all, we're a developer tool. Not a run-time tool.
Developers can easily upgrade their tools ;-)

> Greetings, Marcel
>
>
> --
> Ferry Huberts

[BJ Hargrave]

Don't rush too fast into the future! There are several commercial developer tools based upon Eclipse that are not always on the latest release of Eclipse. So support for 1-2 older versions of Eclipse will allow bndtools to be installed in these commercials tools. I think the proposal made by Neil is quite reasonable and that we need to support the 3.x line for a little longer.

> --
> You received this message because you are subscribed to the Google Groups "bndtools-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--

BJ

[Ferry Huberts]

On 04/04/13 16:14, BJ Hargrave wrote:
> Don't rush too fast into the future! There are several commercial developer tools based upon Eclipse that are not always on the latest release of Eclipse. So support for 1-2 older versions of Eclipse will allow bndtools to be installed in these commercials tools. I think the proposal made by Neil is quite reasonable and that we need to support the 3.x line for a little longer.

Maybe. Maybe not.

We're an open source project.
If commercial tools want to incorporate bndtools, they can use older
versions, or port the code.

I personally _really_ hate being held back by 'commericial' considerations.
Those considerations are not ours, and we're developing the code.
You do the math :-)

4.x APIs will greatly simplify our codebase and therefore will
accelerate our development.

Therefore I have a strong preference to go with 4.x APIs

>
>
> On Apr 4, 2013, at 09:38 , Ferry Huberts <mail...@hupie.com> wrote:
>
>> On 04/04/13 15:32, Marcel Offermans wrote:
>>> On Apr 4, 2013, at 15:27 , Neil Bartlett <njbar...@gmail.com> wrote:
>>>
>>>> I have decided to move Bndtools forward to depend on version 3.7 of Eclipse, also known as Indigo. Since the beginning we have always supported a very wide range of Eclipse versions -- currently all the way from 3.5 (Galileo) up to 4.3 (Kepler). However there are a few features in 3.7 that I would like to start taking advantage of. Therefore starting in version Bndtools 2.2 we will build against Indigo and also support Juno and Kepler... support for Galileo and Helios will be dropped.
>>>>
>>>> Note that this does NOT affect the imminent 2.1 release, it will have the same dependencies as 2.0.
>>> Just to let you know, I would not care if we started depending on 4.x completely. After all, 3.x is being phased out and as far as I can see, the 4.x APIs are a lot nicer to use.
>>
>> Marcel, Paul and I discussed this during EclipseCon and we agreed that
>> we would like to go for 4.x APIs only.
>> We also concluded that there would be no rush in doing that, even though
>> we preferred doing it a.s.a.p.
>>
>> Personally I think it would be a good idea to target this for the end of
>> the year, since 3.x will be phased out by then.
>> And after all, we're a developer tool. Not a run-time tool.
>> Developers can easily upgrade their tools ;-)
>>
>>> Greetings, Marcel
>>>
>>>
>>> --
>>> Ferry Huberts
>> --
>> You received this message because you are subscribed to the Google Groups "bndtools-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>

--

Ferry Huberts


--
Ferry Huberts

[Rafał Krzewski]

I understand the benefit of 4.x APIs, but the user experience of 4.x is horrible, at least for me. It's a lot slower that 3.x - especially switching and resizing views and editors, but even when simply typing in a Java editor there's a perceptible lag. 4.3 M6 doesn't appear to be any better than 4.2 in this respect. Maybe this is something specific to Linux / x64 / GTK platform used by minority of developers, otherwise I cannot fathom how people can put up with this. 

Do what you must, but I intend to hold onto 3.8 as long as possible...

Cheers,

Rafał

[Christopher Brind]

Damn, I seem to agree with everyone:

BJ's point is that there's a risk of crippling adoption if older versions aren't supported.

Ferry's point is that the commercial tools have funding to keep up to date so why hold back?

Rafal's point is that 4.x just isn't working for some people (I've seen some developers at one of my customer's sites delete 4.x off their computers in disgust for similar complaints to Rafal's)

I think basically Neil is doing the right thing just now.

Could I be any more of a yes man?  Sure. ;-)

--

[Paul Bakker]

I guess one of the goals (for most of us) is to get as many users as possible. If it turns out that this commercial tooling issue affects a large percentage of our users, we should consider slowing down. If this is not the case I would prefer to move forward and speed up development. I have absolutely no clue about usage numbers, so it's hard to say...

[BJ Hargrave]

On Apr 4, 2013, at 11:41 , Ferry Huberts <mail...@hupie.com> wrote:

> If commercial tools want to incorporate bndtools, they can use older
> versions, or port the code.

I am not talking about a commercial product incorporating bndtools. I am talking about a company which has standardized on a commercial product and the developers want to play with/move to OSGi using bndtools. By being able to install bndtools in their existing commercial IDE, we have a larger addressable market. If bndtools always only works with the very latest Eclipse version then we (unnecessarily) limit the addressable market.

Neil wants to use something introduced in 3.7 so that is a fine reason to move up the minimum version of Eclipse supported. There is a technical need. But simply wanting to always be on the latest version of Eclipse is not a technical need. It is unnecessarily limiting the addressable market for bndtools.

--

BJ

[Ferry Huberts]

Maybe you missed my

"4.x APIs will greatly simplify our codebase and therefore will
accelerate our development."

which basically amounts to "I would really like to use the new features
that the 4.x APIs offer"

An example: consuming OSGi services is waaaaaay easier in 4.x, a simple
@Inject is sufficient....
Another example: the WindowBuilder tools for 4.x is really excellent:
our UI will have way more generated code
Want more?? :-)

[BJ Hargrave]

On Apr 4, 2013, at 12:24 , Ferry Huberts <ferry....@pelagic.nl> wrote:

> Maybe you missed my

>
>
> "4.x APIs will greatly simplify our codebase and therefore will
> accelerate our development."
>
>

I did not miss it. I just filed it under "I want to use the latest, shiniest toys" rather than a genuine technical need.

> which basically amounts to "I would really like to use the new features
> that the 4.x APIs offer"
>
> An example: consuming OSGi services is waaaaaay easier in 4.x, a simple
> @Inject is sufficient....
> Another example: the WindowBuilder tools for 4.x is really excellent:
> our UI will have way more generated code
> Want more?? :-)

Not really.

I come from OSGi where we put a lot of effort into continuing to support older versions of Java since it gives OSGi the broadest market. People still use it on CDC/Foundation today. We consciously avoid touching each shiny new feature added by each new version of Java despite the strong pull of the precious.

The corporate world does not update to new versions of things as fast at the open source world. So there is a tension here. I am suggesting you err on the side of supporting the stodgy corporate user who has little choice in which version of Eclipse he must use.

--

BJ

[Ferry Huberts]

On 04/04/13 18:34, BJ Hargrave wrote:
> On Apr 4, 2013, at 12:24 , Ferry Huberts <ferry....@pelagic.nl> wrote:
>
>> Maybe you missed my
>>
>>
>> "4.x APIs will greatly simplify our codebase and therefore will
>> accelerate our development."
>>
>>
> I did not miss it. I just filed it under "I want to use the latest, shiniest toys" rather than a genuine technical need.
>
>> which basically amounts to "I would really like to use the new features
>> that the 4.x APIs offer"
>>
>> An example: consuming OSGi services is waaaaaay easier in 4.x, a simple
>> @Inject is sufficient....
>> Another example: the WindowBuilder tools for 4.x is really excellent:
>> our UI will have way more generated code
>> Want more?? :-)
> Not really.
>
> I come from OSGi where we put a lot of effort into continuing to support older versions of Java since it gives OSGi the broadest market. People still use it on CDC/Foundation today. We consciously avoid touching each shiny new feature added by each new version of Java despite the strong pull of the precious.

I know the enterprise world.
I'm a Red Hat partner, I sell their solutions.

The difference here is that the Alliance basically has a run-time
product, while bndtools is a build-time product only, see my earlier
remarks about this.

IMHO these are clearly separated. As long as we support building bundles
that run on older frameworks then I see absolutely no issue in moving
onto a newer base.

> The corporate world does not update to new versions of things as fast at the open source world. So there is a tension here. I am suggesting you err on the side of supporting the stodgy corporate user who has little choice in which version of Eclipse he must use.
>

I'm not the one that decides these things.
I'm just trying to make a strong case for moving onto 4.x

I'm guessing we'll have a nice discussion on this during the bnd week in
June.

[Ferry Huberts]

BTW

IMHO there is a _very_ important secondary consideration:
We'll be able to attract more contributors if we move onto 4.x.

Just ask Lars Vogel how many 3.x courses he is currently teaching and
how many 4.x course ;-)

That alone would make it totally worth moving onto 4.x.
That and the simplified codebase

[BJ Hargrave]

On Apr 4, 2013, at 12:42 , Ferry Huberts <mail...@hupie.com> wrote:

> The difference here is that the Alliance basically has a run-time
> product, while bndtools is a build-time product only, see my earlier
> remarks about this.

In this situation bndtools is a product that runs in a runtime (Eclipse). That bndtools happens to be a build tool is incidental in this discussion. So the question is will bndtools always require the latest version of its runtime? What about Java? Does bndtools also require the latest version of Java (-target 1.7)? No, it only requires Java 5 [1]? Why not also require the shiniest version of Java?

[1] https://github.com/bndtools/bndtools/blob/master/bndtools.core/.settings/org.eclipse.jdt.core.prefs#L8
--

BJ

[BJ Hargrave]

On Apr 4, 2013, at 12:50 , Ferry Huberts <mail...@hupie.com> wrote:

> We'll be able to attract more contributors if we move onto 4.x.

:-) I think that is a dubious claim and/or wishful thinking.

> I'm guessing we'll have a nice discussion on this during the bnd week in
> June.

I think it would be good to come up with some version policy here. How many versions back of Eclipse and Java does bndtools/bnd intend to require of its runtime? Similarly, how many version back of OSGi does bndtools/bnd intend to support building bundles for?


--

BJ

[Simon Chemouil]

On Thursday, April 4, 2013 6:25:05 PM UTC+2, Ferry Huberts wrote:

Maybe you missed my


"4.x APIs will greatly simplify our codebase and therefore will
accelerate our development."


which basically amounts to "I would really like to use the new features
that the 4.x APIs offer"

An example: consuming OSGi services is waaaaaay easier in 4.x, a simple
@Inject is sufficient....
Another example: the WindowBuilder tools for 4.x is really excellent:
our UI will have way more generated code
Want more?? :-)

Hi,

As an ex-E4 developer (and committer), and BndTools user, I'd recommend going with Neil's decision and not further, and even keeping 3.7 compatibility for a few years. Most the reasons have been said already, the ones standing out are:

* poor performance/stability (esp. on GNU/Linux distros)

* corporate environments stuck with Eclipse 3.x for reasons good and bad. Including SMEs who won't "fix" their setup and just move elsewhere.

* very few benefits (no new workbench APIs)

The fact that BndTools is open source is irrelevant. My understanding is that one of the goals of BndTools is to help OSGi adoption and make it *easy as a pie* to develop OSGi applications. Moving to Eclipse 4 is likely to make it *more* difficult for many to simply install BndTools.

If OSGi was widespread and BndTools just tried to be the shinest OSGi development tool on the market, I would have no problem with the move... but OSGi has still a lot of way to go.

I also think you overestimate the benefit of these E4 APIs (I used them extensively and would rather use any other kind of DI if I had the choice, like Neil's own extension2services bundle that allows to inject services in Eclipse contributions. It's maybe even less work to round the corners and make it annotation driven than switching straight to E4).

In general, I'm all for using the new shiny stuff, truly, but this is imo just not worth it. I, for one, keep on using Eclipse 3.7 to develop because it's much snappier, uses less RAM, and that I don't have to restart it everyday. Also I'm an happy LXer. ;)

my two cents :)

-- 

Simon

[jerome moliere]

Hi neil and all bndtools users
Excepted peter i don t know anyone using 3.5 anymore..lol
I hope that upcoming release packs will increase stability and usability of the 4.x branch
Jerome

--

[Neil Bartlett]

Wow I didn't realise this proposal would spark such a long and philosophical discussion! My inclination at this time is not to depend on Eclipse 4, for the following reasons:

1) I still see a lot of Eclipse 3 at my customers, I do believe that requiring 4.x will hinder adoption.

2) I'm unconvinced by the claimed productivity gains of using the 4.x APIs; likewise by the idea we will suddenly get a flood of contributions if we adopt it. Show me a concrete example of a feature in Bndtools that can be developed significantly more quickly and easily with E4. By the way, the Window Builder in 3.x is pretty damn good as well, many of the existing panels in Bndtools were built with it.

3) Like Rafal, I have found Eclipse 4 to be slower and buggier than 3.x. I've heard things will improve significantly in Kepler... that's great, let's revisit this discussion when Kepler is out (but points 1 and 2 will still need to be addressed).

In reply to your question BJ, I don't want to commit to supporting a fixed number of versions back of either Eclipse or Java. We require Java 6 because bnd requires it, and that's fine because J6 is pretty much universal. J7 is not, so we can't use it yet.

Neil

[Neil Bartlett]

Hi Jerome,

Guess what, not even Peter runs Eclipse 3.5 any more!

Neil

[jerome moliere]

He was the latest one...so feel free to depend to the 3 7 if you think it s the right choice...i am not ready to the 4.2 from my point of view...

[Pete Carapetyan]

Ahhhh no wonder things broke for me. I had moved to Juno and couldn't figure out why I had to uninstall bndtools to get rid of the odd error messages.

I had been monitoring the list digest just to see when things settled down - I guess it will be a while before I can use bndtools again. Fortunately my current client doesn't even know what OSGi is :( so I am safe in the interim.

[Ferry Huberts]

You can use bndtools on Juno just fine.

We just build against 3.5 (on the master branch, so all versions up to and including the impending 2.1.0 release).
We build against 3.7 (on the next branch, so all versions after the impending 2.1.0 release).

--

You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

-- 
Ferry Huberts

[Dan Gravell]

On Thursday, 4 April 2013 17:18:24 UTC+1, BJ Hargrave wrote:

On Apr 4, 2013, at 11:41 , Ferry Huberts <mail...@hupie.com> wrote:

> If commercial tools want to incorporate bndtools, they can use older
> versions, or port the code.

I am not talking about a commercial product incorporating bndtools. I am talking about a company which has standardized on a commercial product and the developers want to play with/move to OSGi using bndtools. By being able to install bndtools in their existing commercial IDE, we have a larger addressable market. If bndtools always only works with the very latest Eclipse version then we (unnecessarily) limit the addressable market.

Or: not even standardising on a commercial project. I use bndtools, Scala IDE, m2e, the Tigris SVN plugin and the Google plugins. Commercial or not, if each plugin started picking and choosing narrow slices of eclipse versions that were supported I'd soon be stuck...

I haven't tried 4.x yet, and from what Rafal says it sounds like it won't be a good experience (I'm on Linux).

I support the original proposal.

Dan

[Ferry Huberts]

I'm on Linux as well, and I find that since the last update of Juno it works quite well.
In the beginning of Juno I also dumped it.
Last month I switched to Juno and enjoy it.
I did switch the theme to classic and disabled animations.

I support the original proposal.

Dan

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

-- 
Ferry Huberts

[Dan Gravell]

Sound like better news.

But... animations? ;)

[Neil Bartlett]

Hi Pete,

No I think that's a different issue entirely. To be clear, the move to Eclipse 3.7 will happen in Bndtools 2.2, which does not yet exist. Bndtools 2.0 and 2.1 remain compatible with Eclipse 3.5 through 4.2.

The update problem is because we screwed up. We changed the names of the Bndtools "features" between 1.0 and 2.0, which means p2 does not see them as upgrades but as a whole new product. So you can't upgrade directly from 1.0 to 2.0, you just end up with both versions installed. Instead you need to uninstall 1.0 before you install 2.0.

Regards
Neil

--