June 2012 - openSUSE Java - openSUSE Mailing Lists

New naming scheme for openjdk
by Michal Vyskocil 27 Jun '12

27 Jun '12

Hallo all, we are thinking about a new naming scheme for openjdk package. The old jpackage.org compatible way makes a sense in a past, where there was so sloooow release schedule, that you'd have to use more than one major version of java at the same time. With a new Oracle's approach, this will change and a major version will be increased much faster. We switched to jdk7 recently, but the EOL ends on July 2014 [1] and jdk8 is in pre-release phase atm. Thus there won't be so big need or a possibility to have more than one major version maintained in openSUSE. So the current jpackage.org compatible scheme is pointless and only complicate things. I see a need to drop it and create a new naming scheme for us (the compatibility can be maintain on a level of capabilities). 1.) have one $NAME for current version (openjdk7 in in 12.2) and if we will need add a newest major release, but don't want to switch, we can have $NAME-next with such major release. 2.) adapt gcc approach and have $NAME package, which will require the proper packages with a versions. The next question is what will be in a name? I've looked on what other distros are doing ... # RPM distributions Most rpm distribution adapt the jpackage.org naming, so java-1.$MAJOR_VERSION.0-$VENDOR (we used underscores instead of dots) java-1.7.0-openjdk - the JRE java-1.7.0-openjdk-devel - the JDK (java et all) java-1.7.0-openjdk-src, demo, ... the rest # Debian Debian use quite complex scheme, there are virtual packages default-jre, default-jdk points to proper version. Source package is named openjdk-$MAJOR_VERSION (openjdk-7) and number of binary packages is quite big openjdk-7-jre - JRE using Hotspot VM (the standard one) openjdk-7-jdk - JDK openjdk-7-jre-zero - JRE using Zero assembler VM (extremly slow, but extremly portable) openjdk-7-jre-headless - the headless version, which don't require X11, pulseaudio et all, but contains JIT openjdk-7-jre-lib - noarch package contains some jar files for JRE openjdk-7-demo, openjdk-7-doc, openjdk-7-source - unimportant files icedtea-7-jre-cacao, icedtea-7-jre-jamvm are alternative virtual machines (provides own jre/lib/amd64/cacao/libjvm.so files) # Arch Linux openjdk7-src - source package jre7-openjdk-headless - headless version of runtime jre7-openjdk - rest of the runtime jdk7-openjdk - JDK # Rest * FreeBSD uses openjdk6 name for their port * Gentoo have icedtea6/icedtea7 as a name I'm looking forward on your hints BTW: note that OpenJDK is trademark [3] of Oracle, so there is a reason why Debian calls their packages with alternative VM icedtea instead. [1] http://www.oracle.com/technetwork/java/eol-135779.html [2] http://wiki.debian.org/Java/ [3] http://openjdk.java.net/legal/openjdk-trademark-notice.html Regards Michal Vyskocil

2 6

Build cycles versus rebuild="local"
by Michal Vyskocil 27 Jun '12

27 Jun '12

Hallo all, as a Java package maintainer I did a lot of work to avoid bootstrapping issues (aka build cycles) in openSUSE. That ends in a situation we have been never able to submit maven into build service, because it creates a **huge** list of dependencies, so with rebuild="transitive" it will kill any cluster we will find a budget for ;-) However with a newly introduced Scheduling Strategies feature, collo have used rebuild="local" for Factory, so now we have the cycles in Factory [2]. But probably because of the changed scheduling strategy, coolo did not blame me as in a past for cycles I've introduced in a past. But maybe both are tiny comparing to acl->zlib. Did we changed the approach here? Especially Java packages, where cycles exists in upstream and no one other takes a care it will be a huge step forward. And in this case it even do not block the bootstrapping to an another architecture, as packages are mostly noarch, so can be used everywhere. BTW: for Java packages we can be even more relaxed and use rebuild="manual" and did it only on major jdk change as we did yet jdk6->jdk7. [1] http://enstage.opensuse.org/openSUSE:Build_Service_Concept_build_scheduling… [2] https://build.opensuse.org/project/repository_state?project=openSUSE%3AFact… Regards Michal Vyskocil

1 0

New naming scheme for Apache tomcat
by Michal Vyskocil 13 Jun '12

13 Jun '12

Hallo all, I've decided to drop jpackage.org naming scheme of our Apache Tomcat package and follow Fedora style, so starting 12.2 you will find it under name tomcat. This change makes a perfect sense because we do maintain only one major version of it on (open)SUSE release, so there is no need to have version in package name and complicate updates for users. Regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-java+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-java+owner(a)opensuse.org

1 0

led display Suppliers shared photos with you
by led display Suppliers 10 Jun '12

10 Jun '12

Dear Mr/Miss, Still be puzzling about looking for best led display supplier? Now it will be miles easier working with KEROSA! Here you can find competitive price and excellent quality with a best mix. We"ve been in led display career for many years. We know your market and your country well. Our business is flexible which something is more likely to be a friend chat. We never waste your time. Our conversation will be very efficient base on our good communication. Please reply as soon as possible .if you are working on some led display project. We are ready to make you a satisfied offer! Samuel Shezhen Krosa Techology Co.,Ltd. Address: Building 3,Park,Guanguang road,Bao"an District,Shenzhen,China. post 518000

1 0