Was a discussion of this
ever initiated on the cross-project list? I don't subscribe to that
list, so was just wondering if I should.
Eric
>
From: Lars Vogel <lars.vogel@xxxxxxxxxxx>> To: Eclipse Packaging Project
<epp-dev@xxxxxxxxxxx>,
> Date: 07/30/2015 04:03 PM> Subject: Re: [epp-dev] Minimum BREE for EPP Neon> Sent by: epp-dev-bounces@xxxxxxxxxxx> > AFAIK every project (in this case EPP) can set
its BREE > independently. As EPP is kind of special as it
consumes others. This > kind of forces them to pick the hightest
BREE of their components.This is
not true. And there have been plenty of exceptions
in past releases (if not every past release). But, most of all, I'm writing to ask please do not
call this thing you are taking about "BREE". BREE is an OSGi
construct, and refers to the minimum Java version required to use that
bundle ... in "isolation", so to speak ... that is, as a "component"
-- not necessarily how *we* ship that bundle. What you are talking about here is the *Product* Execution
Environment ... and is entirely and Eclipse construct ... the minimum
Java
version to run a product. If it so happens someone uses a lower Java
version
than required by some bundles, then those bundles simply would not
function.
And, there are many cases where this is ok (or, has been ok) if not out
right desired. Such as, to give a simple example where it was deemed ok
(though not desired); in Kepler and Luna, I believe, you could run the
product at a "lower" Java version, and you simply would not have
help available (since Jetty required higher). The decision on BREE levels and Product Execution
Environment are related, but, not a direct absolute relationship. Plus,
in the past, we have never decided the EPP level from a "top down"
point of view -- a whole year in advance ... but, simply took stock of
what projects were doing, and at some point the package maintainers
decided
what they wanted the minimum Product Execution Environment to be. I do understand, it is (probably) that "past"
that people are trying to change ... it would make things so much easier
for committers to justify increasing a bundle BREE level, if EPP Product
Execution Environment was already decided to increase. I just thought
it's
be best to be explicit about it. I
think people have made good arguments on both sides
of the issue -- except for one case, and that was the one that implied
25% of our user population was "insignificant" in this decision
(not to mention, that same thread assuming that those that "submit
error reports" somehow magically form a representative sample of our
users -- that seems unlikely, and I've not seen that case made, if
someone
things they are. But, yes, should
move to cross-project list, with
corrected terminology please -- and perhaps with a clarified statement
of "what problem you are trying to solve". Thanks,
AFAIK every
project (in this case EPP) can set its BREE independently. As EPP is
kind of special as it consumes others. This kind of forces them to pick
the hightest BREE of their components.
Actually, this discussion should probably go to the cross projects
list. It’s not clear to me who has the power to make this decision. Does
the EPP have any power over this? It can keep the BREE at 7 and deliver
broken packages, but that’s probably not
a practical path.
Doug
--------------------------------------------------------------------- This
transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
One
more thing… Most of the Java-version issues that we’ve seen in our
support cases could be remedied by enhancing Eclipse launcher to prompt
user to select a compatible JVM. That is, the issue isn’t so much that
users can’t have a particular Java version, but rather that they have
multiple versions and Eclipse chooses the wrong one, or they simply
don’t know that they need to install a new version. -
Konstantin
Well Oomph takes care of that particular problem (although IMO the UI
for it still could use a bit of tweaking); I suspect by the time Neon
ships, Oomph will be in full stride as the most-endorsed way of getting
Eclipse (I'm pretty sure that's the way Ed and Eike would like to see it
be :-). That of course would mean the EPP packages take on a
diminished role to the general user community.
Eric
What’s
wrong with the answer that developers in environments that can’t have
Java 8 have to stay on the Mars service line and rely on long term
support organizations for bug fixes? Another
thing to note is that by the time that Neon ships, Java 9 will be just
around the corner. -
Konstantin Valid
point, Doug. It
gives me a little relief from me concerns, but doesn't totally eliminate
them.
There are pretty easy
workarounds for those users who can’t upgrade their Java yet somehow
found a way to install Eclipse on their machines. The embedded jre in
the Eclipse directory still works. You'd think we're dealing with a user base, being
primarily developers, who could easily deal with such workarounds. But
time has shown that assumption isn't as reliable as one might think. One
problem is that Oracle makes a portable (non-installer) JDK harder and
harder to obtain. Eclipse itself doesn't need a typical Windows
installer, but JDK does.
Eric --------------------------------------------------------------------- This
transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful. Hi Eric, In this context I think
we should look at the current user base. Marcel (cc) recently gave same
real data about the current user base of Mars. @Marcel, please feel free
to provide better numbers, but IIRC approx. 75% of the error reporters
using Eclipse Mars are using already Java 8.
-- Eclipse Platform UI and
e4 project co-lead CEO vogella GmbH
Haindaalwisch 17a, 22395
Hamburg Amtsgericht Hamburg: HRB 127058 Geschäftsführer: Lars
Vogel, Jennifer Nerlich de Vogel USt-IdNr.: DE284122352 Fax (032)
221739404, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com I'm not an EPP
package maintainer or committer,
but I'd like to provide some user-community perspective on this. Java
8 is just over 1 year old, and it's well known that many people and
(especially) corporations are slow to adopt new versions. If Eclipse
packages were to require Java 8, I can pretty much guarantee, based on
many years' experience supporting the community, that there will be many
complaints and confused users. In fact, in a corporate environment
where users literally can not update their own workstations, I'd say
it's highly likely that users would be unable to use Neon, or at least
have to jump through corporate IT hoops to get it working.
I'm
not knocking Java 8 (at least not here), I'm just trying to keep
everyone focused on the users. Just because we, as tool developers, are
enamored and in love with the latest toys doesn't mean we can justify
pushing them down the throats of our large user base.
Eric
And we’re talking about Neon which releases in a year. When Java 8
will be two years old.
Valid point, Doug. It gives me a
little relief from me concerns, but doesn't totally eliminate them.
There are pretty easy workarounds for those users who can’t upgrade
their Java yet somehow found a way to install Eclipse on their
machines. The embedded jre in the Eclipse directory still works.
You'd think we're dealing with a
user base, being primarily developers, who could easily deal with such
workarounds. But time has shown that assumption isn't as reliable as one
might think. One problem is that Oracle makes a portable
(non-installer) JDK harder and harder to obtain. Eclipse itself doesn't
need a typical Windows installer, but JDK does.
Eric
Doug.
--------------------------------------------------------------------- This
transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
Hi
Eric, In
this context I think we should look at the current user base. Marcel
(cc) recently gave same real data about the current user base of Mars.
@Marcel, please feel free to provide better numbers, but IIRC approx.
75% of the error reporters using Eclipse Mars are using already Java 8.
Best
regards, Lars
I'm not an EPP package
maintainer or committer, but I'd like to provide some user-community
perspective on this.
Java 8 is just over 1 year old, and it's well known that many people and
(especially) corporations are slow to adopt new versions. If Eclipse
packages were to require Java 8, I can pretty much guarantee, based on
many years' experience supporting the community, that there will be many
complaints and confused users. In fact, in a corporate environment
where users literally can not update their own workstations, I'd say
it's highly likely that users would be unable to use Neon, or at least
have to jump through corporate IT hoops to get it working.
I'm not knocking Java 8 (at least not here), I'm just trying to keep
everyone focused on the users. Just because we, as tool developers, are
enamored and in love with the latest toys doesn't mean we can justify
pushing them down the throats of our large user base.
Eric
Hi,
I
noticed
yesterday that m2e moved to Java 8, which triggered this request. I
contacted Markus Knauer and he suggested that I should send an email
to this list to trigger the discussion about BREE for the EPP's in
Neon.
I personally think it would be great to require Java 8 as
BREE for the EPP out of the following reasons:
- Java 7 is out
of public maintenance - if the EPP's decide early that they will
require Java 8, other project will have the option to improve their
code base based on Java 8 - if m2e requires Java 8, AFAIK this
would bump the most important EPP's also to Java 8.
In
Platform UI I would also like to support the Java 8 Date and Time API
via Databinding, which would also bump platform to Java 8. This is not
yet implement but on our roadmap. AFAIK the Jetty webserver also requires
Java 8, which would result in a bump in the Eclipse Help system to
Java 8.
Best regards, Lars
_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/epp-dev
And we’re talking about Neon which releases in a year. When Java 8
will be two years old.
There are pretty easy workarounds for those users who can’t upgrade
their Java yet somehow found a way to install Eclipse on their
machines. The embedded jre in the Eclipse directory still works.
Doug.
--------------------------------------------------------------------- This
transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
Hi
Eric, In
this context I think we should look at the current user base. Marcel
(cc) recently gave same real data about the current user base of Mars.
@Marcel, please feel free to provide better numbers, but IIRC approx.
75% of the error reporters using Eclipse Mars are using already Java 8.
Best
regards, Lars
I'm not an EPP package
maintainer or committer, but I'd like to provide some user-community
perspective on this.
Java 8 is just over 1 year old, and it's well known that many people and
(especially) corporations are slow to adopt new versions. If Eclipse
packages were to require Java 8, I can pretty much guarantee, based on
many years' experience supporting the community, that there will be many
complaints and confused users. In fact, in a corporate environment
where users literally can not update their own workstations, I'd say
it's highly likely that users would be unable to use Neon, or at least
have to jump through corporate IT hoops to get it working.
I'm not knocking Java 8 (at least not here), I'm just trying to keep
everyone focused on the users. Just because we, as tool developers, are
enamored and in love with the latest toys doesn't mean we can justify
pushing them down the throats of our large user base.
Eric
And we’re talking about Neon which releases in a year. When Java 8
will be two years old.
Valid point, Doug. It gives me a
little relief from me concerns, but doesn't totally eliminate them.
There are pretty easy workarounds for those users who can’t upgrade
their Java yet somehow found a way to install Eclipse on their
machines. The embedded jre in the Eclipse directory still works.
You'd think we're dealing with a
user base, being primarily developers, who could easily deal with such
workarounds. But time has shown that assumption isn't as reliable as one
might think. One problem is that Oracle makes a portable
(non-installer) JDK harder and harder to obtain. Eclipse itself doesn't
need a typical Windows installer, but JDK does.
Eric
Doug.
--------------------------------------------------------------------- This
transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
Hi
Eric, In
this context I think we should look at the current user base. Marcel
(cc) recently gave same real data about the current user base of Mars.
@Marcel, please feel free to provide better numbers, but IIRC approx.
75% of the error reporters using Eclipse Mars are using already Java 8.
Best
regards, Lars
I'm not an EPP package
maintainer or committer, but I'd like to provide some user-community
perspective on this.
Java 8 is just over 1 year old, and it's well known that many people and
(especially) corporations are slow to adopt new versions. If Eclipse
packages were to require Java 8, I can pretty much guarantee, based on
many years' experience supporting the community, that there will be many
complaints and confused users. In fact, in a corporate environment
where users literally can not update their own workstations, I'd say
it's highly likely that users would be unable to use Neon, or at least
have to jump through corporate IT hoops to get it working.
I'm not knocking Java 8 (at least not here), I'm just trying to keep
everyone focused on the users. Just because we, as tool developers, are
enamored and in love with the latest toys doesn't mean we can justify
pushing them down the throats of our large user base.
Eric
Hi,
I
noticed
yesterday that m2e moved to Java 8, which triggered this request. I
contacted Markus Knauer and he suggested that I should send an email
to this list to trigger the discussion about BREE for the EPP's in
Neon.
I personally think it would be great to require Java 8 as
BREE for the EPP out of the following reasons:
- Java 7 is out
of public maintenance - if the EPP's decide early that they will
require Java 8, other project will have the option to improve their
code base based on Java 8 - if m2e requires Java 8, AFAIK this
would bump the most important EPP's also to Java 8.
In
Platform UI I would also like to support the Java 8 Date and Time API
via Databinding, which would also bump platform to Java 8. This is not
yet implement but on our roadmap. AFAIK the Jetty webserver also requires
Java 8, which would result in a bump in the Eclipse Help system to
Java 8.
Best regards, Lars
|