Re: Java packages FTBFS/FTI on 32-bit arches
On Sat, Apr 13, 2019 at 12:43 PM Mikolaj Izdebski wrote: > > On Sat, Apr 13, 2019 at 12:17 PM Fabio Valentini wrote: > > > > On Fri, Apr 12, 2019 at 5:03 PM Mikolaj Izdebski > > wrote: > > > > > > On Mon, Mar 18, 2019 at 3:20 PM Mat Booth 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Java packages FTBFS/FTI on 32-bit arches
On Sat, Apr 13, 2019 at 12:42 PM Mikolaj Izdebski 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=f31=javax.persistence.EntityManager -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Java packages FTBFS/FTI on 32-bit arches
On Sat, Apr 13, 2019 at 12:17 PM Fabio Valentini wrote: > > On Fri, Apr 12, 2019 at 5:03 PM Mikolaj Izdebski wrote: > > > > On Mon, Mar 18, 2019 at 3:20 PM Mat Booth 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Java packages FTBFS/FTI on 32-bit arches
On Fri, Apr 12, 2019 at 5:03 PM Mikolaj Izdebski wrote: > > On Mon, Mar 18, 2019 at 3:20 PM Mat Booth 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
