[HEADS UP] Eclipse dropping 32-bit arches

[Mat Booth]

The message about Ceph [1] reminded me that we should probably make the
same notification for Eclipse Platform.

The Eclipse Platform upstream is in the process of dropping all support for
32bit arches.

The current state is that upstream are no longer building for 32bit arches
upstream for 4.10 (release 2018-12) onwards. I expect them to start
actively removing 32bit specific code in future releases.

You can read more about the decision on the upstream bug [2]

In Fedora, Eclipse 4.10 which I am building for Rawhide and F29 right now,
still builds for 32bit arches, but this will not last long. I expect in a
future release (4.11 or later) Eclipse will no longer build on x86/arm and
at that time I will no longer be able to support these architectures in
Fedora -- I expect to exclude those arches from Fedora builds.

If you depend on the ECJ batch compiler, this will continue to be available
on all arches as a noarch package. (It is packaged as a discrete SRPM and
has no build or runtime dependency on the Eclipse Platform itself.)

Regards,
Mat


[1]
https://lists.fedoraproject.org/archives/list/[e-mail].o...
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=526620

[fedora-java] [HEADS UP] Eclipse dropping 32-bit arches

[Aleksandar Kurtakov]

On Wed, Dec 5, 2018 at 5:32 PM Mat Booth <fedora(a)matbooth.co.uk&gt; wrote:

>  The message about Ceph [1] reminded me that we should probably make
> the
>  same notification for Eclipse Platform.
>
>  The Eclipse Platform upstream is in the process of dropping all support
>  for 32bit arches.
>
>  The current state is that upstream are no longer building for 32bit arches
>  upstream for 4.10 (release 2018-12) onwards. I expect them to start
>  actively removing 32bit specific code in future releases.
>  
Speaking as upstream representative here - even if we don't have plans to
start removing 32 bit specific code, we are not planning to check that the
whole pointer size magic to support 32 bit is done proper in new code so
native bits of Eclipse will probably fail to compile and it would be up to
Fedora maintainers providing these fixes and keep maintaining them as it
makes  no sense to upstream such changes when support is on its way out.
What is worse though is that sometimes these issues are not catched at
compile time but at runtime resulting in crashing the whole Eclipse -
experience that would give bad name for both Eclipse and Fedora thus
definetely not wanted.


>  You can read more about the decision on the upstream bug [2]
>
>  In Fedora, Eclipse 4.10 which I am building for Rawhide and F29 right now,
>  still builds for 32bit arches, but this will not last long. I expect in a
>  future release (4.11 or later) Eclipse will no longer build on x86/arm and
>  at that time I will no longer be able to support these architectures in
>  Fedora -- I expect to exclude those arches from Fedora builds.
>  
That's the best thing to do IMHO.


>  If you depend on the ECJ batch compiler, this will continue to be
>  available on all arches as a noarch package. (It is packaged as a discrete
>  SRPM and has no build or runtime dependency on the Eclipse Platform itself.
>  )
>
>  Regards,
>  Mat
>
>
>  [1]
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=526620
>  _______________________________________________
>  java-devel mailing list -- java-devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to java-devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]...
>  

-- 
Alexander Kurtakov
Red Hat Eclipse Team

[Mat Booth]

On Wed, 5 Dec 2018 at 15:29, Mat Booth <fedora(a)matbooth.co.uk&gt; wrote:

>  The Eclipse Platform upstream is in the process of dropping all
> support
>  for 32bit arches.
>
>  The current state is that upstream are no longer building for 32bit arches
>  upstream for 4.10 (release 2018-12) onwards. I expect them to start
>  actively removing 32bit specific code in future releases.
>
>  You can read more about the decision on the upstream bug [2]
>
>  In Fedora, Eclipse 4.10 which I am building for Rawhide and F29 right now,
>  still builds for 32bit arches, but this will not last long. I expect in a
>  future release (4.11 or later) Eclipse will no longer build on x86/arm and
>  at that time I will no longer be able to support these architectures in
>  Fedora -- I expect to exclude those arches from Fedora builds.
>
>  If you depend on the ECJ batch compiler, this will continue to be
>  available on all arches as a noarch package. (It is packaged as a discrete
>  SRPM and has no build or runtime dependency on the Eclipse Platform itself.
>  )
>
>  Regards,
>  Mat
>
>
>  [1]
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=526620
>  
It's three months later and I wanted to follow up on this.

Eclipse in Fedora has dropped support for 32 bit architectures. The newest
builds of Eclipse 4.11 for F30 and newer reflect this and are built for 64
bit architectures only.

By now I have touched most Eclipse plug-in packages to limit their
availability to the same architectures as Eclipse itself. If you own a
package that is not an Eclipse plug-in but it does have a build or runtime
dependency on Eclipse, then you will need to follow suit and make your
package also exclude 32 bit architecture. If your package simply depends on
Eclipse/Equinox for OSGi APIs, then you might be better switching your
package to build against the OSGi APIs provided by the
osgi-core/osgi-compendium packages instead to stay available on all
architecture. Feel free to ping if you are unsure how to proceed.

Regards,
Mat

PS. My next job is modularising Eclipse in Fedora so that it remains
available in the distro after the great package retiring happens.

-- 
Mat Booth
http://fedoraproject.org/get-fedora

Java packages FTBFS/FTI on 32-bit arches

[Mikolaj Izdebski]

On Mon, Mar 18, 2019 at 3:20 PM Mat Booth <fedora(a)matbooth.co.uk&gt; wrote:
>  Eclipse in Fedora has dropped support for 32 bit architectures. The
> newest builds of Eclipse 4.11 for F30 and newer reflect this and are built for 64 bit
> architectures only.
>
>  By now I have touched most Eclipse plug-in packages to limit their availability to the
> same architectures as Eclipse itself. If you own a package that is not an Eclipse plug-in
> but it does have a build or runtime dependency on Eclipse, then you will need to follow
> suit and make your package also exclude 32 bit architecture. If your package simply
> depends on Eclipse/Equinox for OSGi APIs, then you might be better switching your package
> to build against the OSGi APIs provided by the osgi-core/osgi-compendium packages instead
> to stay available on all architecture. Feel free to ping if you are unsure how to proceed.
I'd like to follow up on this. Right now many Java packages fail to
install and/or build on 32-bit arches (primary and secondary) in
Fedora 30 and rawhide to install or build.

For example, for Apache Log4j (one of basic libraries that many other
packages depend on):

 Problem: package log4j-2.11.1-3.fc30.noarch requires
mvn(org.eclipse.persistence:javax.persistence), but none of the
providers can be installed
  - conflicting requests
  - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed by
eclipselink-persistence-api-2.1.0-7.fc30.noarch

Java modules (maven, ant, javapackages-tools) are not affected by this
issue and they continue to work and build on 32-bit arches.

--
Mikolaj Izdebski

Java packages FTBFS/FTI on 32-bit arches

[Fabio Valentini]

On Fri, Apr 12, 2019 at 5:03 PM Mikolaj Izdebski <mizdebsk(a)redhat.com&gt; wrote:
>  On Mon, Mar 18, 2019 at 3:20 PM Mat Booth <fedora(a)matbooth.co.uk&gt; wrote:
>  > Eclipse in Fedora has dropped support for 32 bit architectures. The newest builds of
> Eclipse 4.11 for F30 and newer reflect this and are built for 64 bit architectures only.
>  >
>  > By now I have touched most Eclipse plug-in packages to limit their availability to
> the same architectures as Eclipse itself. If you own a package that is not an Eclipse
> plug-in but it does have a build or runtime dependency on Eclipse, then you will need to
> follow suit and make your package also exclude 32 bit architecture. If your package simply
> depends on Eclipse/Equinox for OSGi APIs, then you might be better switching your package
> to build against the OSGi APIs provided by the osgi-core/osgi-compendium packages instead
> to stay available on all architecture. Feel free to ping if you are unsure how to proceed.
On koschei, I'm getting the following issues for the stewardship-sig
packages (there are probably more, but builds don't always hit 32-bit
builders):

avalon-framework:
    Problem: package log4j-2.11.1-3.fc30.noarch requires
mvn(org.eclipse.persistence:javax.persistence), but none of the
providers can be installed
    - conflicting requests
    - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed
by eclipselink-persistence-api-2.1.0-7.fc30.noarch

avalon-logkit:
    Problem: package log4j-2.11.1-3.fc30.noarch requires
mvn(org.eclipse.persistence:javax.persistence), but none of the
providers can be installed
    - conflicting requests
    - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed
by eclipselink-persistence-api-2.1.0-7.fc30.noarch

log4j:
    Problem: conflicting requests
    - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed
by eclipselink-persistence-api-2.1.0-7.fc30.noarch

If I understand correctly, that's a case where we should "switch"
log4j to using the different "OSGi APIs" you mentioned?
For now, I've added an "x86_64" arch override to these three packages
in koschei, so we can see if they can build successfully on at least
one architecture.

Fabio

> I'd like to follow up on this. Right now many Java packages fail to
> install and/or build on 32-bit arches (primary and secondary) in
> Fedora 30 and rawhide to install or build.
>
> For example, for Apache Log4j (one of basic libraries that many other
> packages depend on):
>
>  Problem: package log4j-2.11.1-3.fc30.noarch requires
> mvn(org.eclipse.persistence:javax.persistence), but none of the
> providers can be installed
>   - conflicting requests
>   - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed by
> eclipselink-persistence-api-2.1.0-7.fc30.noarch
>
> Java modules (maven, ant, javapackages-tools) are not affected by this
> issue and they continue to work and build on 32-bit arches.
>
> --
> Mikolaj Izdebski
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]

Java packages FTBFS/FTI on 32-bit arches

[Mikolaj Izdebski]

On Sat, Apr 13, 2019 at 12:17 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  On Fri, Apr 12, 2019 at 5:03 PM Mikolaj Izdebski <mizdebsk(a)redhat.com&gt; wrote:
>  >
>  > On Mon, Mar 18, 2019 at 3:20 PM Mat Booth <fedora(a)matbooth.co.uk&gt; wrote:
>  > > Eclipse in Fedora has dropped support for 32 bit architectures. The newest
> builds of Eclipse 4.11 for F30 and newer reflect this and are built for 64 bit
> architectures only.
>  > >
>  > > By now I have touched most Eclipse plug-in packages to limit their availability
> to the same architectures as Eclipse itself. If you own a package that is not an Eclipse
> plug-in but it does have a build or runtime dependency on Eclipse, then you will need to
> follow suit and make your package also exclude 32 bit architecture. If your package simply
> depends on Eclipse/Equinox for OSGi APIs, then you might be better switching your package
> to build against the OSGi APIs provided by the osgi-core/osgi-compendium packages instead
> to stay available on all architecture. Feel free to ping if you are unsure how to
> proceed.
>
>  On koschei, I'm getting the following issues for the stewardship-sig
>  packages (there are probably more, but builds don't always hit 32-bit
>  builders):
>
>  avalon-framework:
>      Problem: package log4j-2.11.1-3.fc30.noarch requires
>  mvn(org.eclipse.persistence:javax.persistence), but none of the
>  providers can be installed
>      - conflicting requests
>      - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed
>  by eclipselink-persistence-api-2.1.0-7.fc30.noarch
>
>  avalon-logkit:
>      Problem: package log4j-2.11.1-3.fc30.noarch requires
>  mvn(org.eclipse.persistence:javax.persistence), but none of the
>  providers can be installed
>      - conflicting requests
>      - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed
>  by eclipselink-persistence-api-2.1.0-7.fc30.noarch
>
>  log4j:
>      Problem: conflicting requests
>      - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed
>  by eclipselink-persistence-api-2.1.0-7.fc30.noarch
>
>  If I understand correctly, that's a case where we should "switch"
>  log4j to using the different "OSGi APIs" you mentioned?
>  For now, I've added an "x86_64" arch override to these three packages
>  in koschei, so we can see if they can build successfully on at least
>  one architecture. 
First, some cotext:
Apache Log4j is a logging library. Among other possibilities, it can
log to a relational database through JPA [1].
Log4j uses EclipseLink as it is the reference implementations of JPA.
EclipseLink (obviously) depends on Eclipse, which is now unavailable
on 32-bit arches.
But EclipseLink is not the only available implementation of JPA. We
also have other implementations packaged. The ones I am aware of:
Hibernate 5, Hibernate 4, Hibernate 3, Apache OpenJPA.

Possible solutions that I can think of (in order from most to least preferred):
1. make EclipseLink not depend on Eclipse (but I don't how feasible
that would be)
2. switch log4j to use different implementation of JPA (should be easy)
3. disable JPA support in log4j (trivial, but will break users)

[1] https://en.wikipedia.org/wiki/Java_Persistence_API

--
Mikolaj Izdebski

Java packages FTBFS/FTI on 32-bit arches

[Mikolaj Izdebski]

On Sat, Apr 13, 2019 at 12:42 PM Mikolaj Izdebski <mizdebsk(a)redhat.com&gt; wrote:
>  But EclipseLink is not the only available implementation of JPA. We
>  also have other implementations packaged. The ones I am aware of:
>  Hibernate 5, Hibernate 4, Hibernate 3, Apache OpenJPA. 
Searching in Java Deptools [1] revealed that another packaged
implementation is Apache Geronimo.

[1]
https://java-deptools.fedorainfracloud.org/?qtype=classes&collection=...

--
Mikolaj Izdebski

Java packages FTBFS/FTI on 32-bit arches

[Fabio Valentini]

On Sat, Apr 13, 2019 at 12:43 PM Mikolaj Izdebski <mizdebsk(a)redhat.com&gt; wrote:
>  On Sat, Apr 13, 2019 at 12:17 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  >
>  > On Fri, Apr 12, 2019 at 5:03 PM Mikolaj Izdebski <mizdebsk(a)redhat.com&gt; wrote:
>  > >
>  > > On Mon, Mar 18, 2019 at 3:20 PM Mat Booth <fedora(a)matbooth.co.uk&gt; wrote:
>  > > > Eclipse in Fedora has dropped support for 32 bit architectures. The newest
> builds of Eclipse 4.11 for F30 and newer reflect this and are built for 64 bit
> architectures only.
>  > > >
>  > > > By now I have touched most Eclipse plug-in packages to limit their
> availability to the same architectures as Eclipse itself. If you own a package that is not
> an Eclipse plug-in but it does have a build or runtime dependency on Eclipse, then you
> will need to follow suit and make your package also exclude 32 bit architecture. If your
> package simply depends on Eclipse/Equinox for OSGi APIs, then you might be better
> switching your package to build against the OSGi APIs provided by the
> osgi-core/osgi-compendium packages instead to stay available on all architecture. Feel
> free to ping if you are unsure how to proceed.
>  >
>  > On koschei, I'm getting the following issues for the stewardship-sig
>  > packages (there are probably more, but builds don't always hit 32-bit
>  > builders):
>  >
>  > avalon-framework:
>  >     Problem: package log4j-2.11.1-3.fc30.noarch requires
>  > mvn(org.eclipse.persistence:javax.persistence), but none of the
>  > providers can be installed
>  >     - conflicting requests
>  >     - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed
>  > by eclipselink-persistence-api-2.1.0-7.fc30.noarch
>  >
>  > avalon-logkit:
>  >     Problem: package log4j-2.11.1-3.fc30.noarch requires
>  > mvn(org.eclipse.persistence:javax.persistence), but none of the
>  > providers can be installed
>  >     - conflicting requests
>  >     - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed
>  > by eclipselink-persistence-api-2.1.0-7.fc30.noarch
>  >
>  > log4j:
>  >     Problem: conflicting requests
>  >     - nothing provides mvn(org.eclipse.osgi:org.eclipse.osgi) needed
>  > by eclipselink-persistence-api-2.1.0-7.fc30.noarch
>  >
>  > If I understand correctly, that's a case where we should "switch"
>  > log4j to using the different "OSGi APIs" you mentioned?
>  > For now, I've added an "x86_64" arch override to these three packages
>  > in koschei, so we can see if they can build successfully on at least
>  > one architecture.
>
>  First, some cotext:
>  Apache Log4j is a logging library. Among other possibilities, it can
>  log to a relational database through JPA [1].
>  Log4j uses EclipseLink as it is the reference implementations of JPA.
>  EclipseLink (obviously) depends on Eclipse, which is now unavailable
>  on 32-bit arches.
>  But EclipseLink is not the only available implementation of JPA. We
>  also have other implementations packaged. The ones I am aware of:
>  Hibernate 5, Hibernate 4, Hibernate 3, Apache OpenJPA.
>
>  Possible solutions that I can think of (in order from most to least preferred):
>  1. make EclipseLink not depend on Eclipse (but I don't how feasible
>  that would be)
>  2. switch log4j to use different implementation of JPA (should be easy)
>  3. disable JPA support in log4j (trivial, but will break users)
>
>  [1] https://en.wikipedia.org/wiki/Java_Persistence_API 
Ah, I see. Thanks for the clarification. I've worked on a Project
using springframework / JPA / hibernate before, but I didn't know how
all the pieces fit together under the hood.

So Option 1 would require help from the eclipse/EclipseLink
maintainers? So ... Option 2 sounds like the probable outcome.

Fabio

> --
> Mikolaj Izdebski
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]