DevHeads.net

Orphaned some Java packages

I've just orphaned 259 packages listed below. Almost all of them are
Java packages which I will continue to maintain as part of modules.
Intent to orphan them was already announced on java-devel [1] and
devel [2] lists, with detailed reasoning.

Originally planned time of orphaning was delayed because I was hoping
that modular packages could be allowed to be used in buildroots of
non-modular packages (ursa-major proposal [3]), which would allow me
to retire these packages and replace them with modular versions
instead, but the proposal was recently rejected.

[1] <a href="https://lists.fedoraproject.org/archives/list/java- ... at lists dot fedoraproject.org/message/MQMRQVENBLDRS67WLNQ7EOCMSDI5WIET/" title="https://lists.fedoraproject.org/archives/list/java- ... at lists dot fedoraproject.org/message/MQMRQVENBLDRS67WLNQ7EOCMSDI5WIET/">https://lists.fedoraproject.org/archives/list/java- ... at lists dot fedorapro...</a>
[2] <a href="https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject.org/message/YFUXS7ZX6UDEMEKJWONKFMVDTSBABZID/" title="https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject.org/message/YFUXS7ZX6UDEMEKJWONKFMVDTSBABZID/">https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject....</a>
[3] <a href="https://pagure.io/fesco/issue/2003" title="https://pagure.io/fesco/issue/2003">https://pagure.io/fesco/issue/2003</a>

The list of orphaned packages follows.

aether-connector-okhttp
ant
ant-antunit
ant-contrib
antlr3
antlr4
aopalliance
apache-commons-beanutils
apache-commons-collections
apache-commons-collections4
apache-commons-compress
apache-commons-configuration
apache-commons-csv
apache-commons-daemon
apache-commons-discovery
apache-commons-el
apache-commons-fileupload
apache-commons-io
apache-commons-jexl
apache-commons-jxpath
apache-commons-lang
apache-commons-lang3
apache-commons-logging
apache-commons-net
apache-ivy
apache-james-project
apache-logging-parent
apache-mime4j
apache-parent
apache-rat
apache-resource-bundles
apiguardian
aqute-bnd
args4j
atinject
avalon-framework
avalon-logkit
base64coder
batik
bcel
bea-stax
beust-jcommander
bsf
bsh
byaccj
cal10n
checkstyle
codemodel
dain-snappy
decentxml
dom4j
easymock
eclipse-m2e-antlr
eclipse-m2e-buildhelper
eclipse-m2e-core
eclipse-m2e-cxf
eclipse-m2e-egit
eclipse-m2e-mavenarchiver
eclipse-m2e-maven-dependency-plugin
eclipse-m2e-mavendev
eclipse-m2e-modello
eclipse-m2e-plexus
eclipse-m2e-sisu
eclipse-m2e-sourcelookup
eclipse-m2e-takari
eclipse-m2e-tycho
eclipse-m2e-workspace
exec-maven-plugin
felix-bundlerepository
felix-osgi-core
felix-osgi-obr
felix-utils
geronimo-jaspic-spec
geronimo-jms
geronimo-jpa
geronimo-jta
geronimo-parent-poms
glassfish-dtd-parser
glassfish-fastinfoset
glassfish-jaxb
glassfish-jsp
glassfish-jsp-api
google-gson
google-guice
gpars
gradle
groovy
guava20
hawtjni
hsqldb
httpcomponents-client
httpcomponents-core
httpcomponents-project
httpunit
icu4j
istack-commons
jackson
jakarta-commons-httpclient
jansi
jansi-native
javacc
javacc-maven-plugin
javamail
java-service-wrapper
javassist
jaxen
jchardet
jdepend
jdependency
jeromq
jettison
jetty
jetty8
jetty-alpn
jetty-alpn-api
jetty-artifact-remote-resources
jetty-assembly-descriptors
jetty-build-support
jetty-distribution-remote-resources
jetty-parent
jetty-schemas
jetty-test-helper
jetty-test-policy
jetty-toolchain
jetty-version-maven-plugin
jflex
jmapviewer
jna
joda-convert
jortho
jsch-agent-proxy
json_simple
jsoup
jsr-311
junit
junit5
jvnet-parent
kohsuke-pom
kxml
log4j
maven
maven-antrun-plugin
maven-archetype
maven-archiver
maven-artifact-resolver
maven-artifact-transfer
maven-assembly-plugin
maven-clean-plugin
maven-compiler-plugin
maven-dependency-analyzer
maven-dependency-plugin
maven-dependency-tree
maven-doxia
maven-doxia-sitetools
maven-enforcer
maven-file-management
maven-filtering
maven-gpg-plugin
maven-idea-plugin
maven-indexer
maven-invoker
maven-jar-plugin
maven-jarsigner-plugin
maven-javadoc-plugin
maven-mapping
maven-osgi
maven-parent
maven-plugin-build-helper
maven-plugin-bundle
maven-plugins-pom
maven-plugin-testing
maven-plugin-tools
maven-reporting-api
maven-reporting-exec
maven-reporting-impl
maven-repository-builder
maven-resolver
maven-script-interpreter
maven-shade-plugin
maven-shared-incremental
maven-shared-io
maven-shared-jar
maven-shared-jarsigner
maven-shared-utils
maven-site-plugin
maven-source-plugin
maven-stapler-plugin
maven-surefire
maven-toolchains-plugin
maven-verifier
maven-wagon
mnemonicsetter
modello
mojo-parent
multiverse
munge-maven-plugin
nasm
nekohtml
netty
objectweb-asm3
objectweb-pom
okio
opentest4j
osgi-compendium
osgi-core
os-maven-plugin
plexus-ant-factory
plexus-archiver
plexus-bsh-factory
plexus-classworlds
plexus-cli
plexus-compiler
plexus-component-factories-pom
plexus-components-pom
plexus-containers
plexus-digest
plexus-i18n
plexus-interactivity
plexus-interpolation
plexus-io
plexus-languages
plexus-resources
plexus-utils
plexus-velocity
qdox
regexp
sdljava
SimplyHTML
sisu
sisu-mojos
slf4j
snakeyaml
sonatype-oss-parent
sonatype-plugins-parent
stax2-api
stringtemplate4
tagsoup
takari-archiver
takari-filemanager
takari-incrementalbuild
takari-lifecycle
takari-plugin-testing
takari-pom
takari-tycho-support
txw2
univocity-parsers
velocity
woodstox-core
xalan-j2
xbean
xml-maven-plugin
xmlrpc
xmvn
xom
xsom
xstream
xz-java
zinc
zopfli

Comments

Re: Orphaned some Java packages

By =?UTF-8?B?TWlyb... at 03/27/2019 - 19:48

On 05. 02. 19 11:07, Mikolaj Izdebski wrote:
Hi Mikolaj,

do you have some kind out outline about what packages are in what modules?

I took over google-gson, but I see no stream branch.

junit has javapackages branch
<a href="https://src.fedoraproject.org/rpms/junit/commits/javapackages" title="https://src.fedoraproject.org/rpms/junit/commits/javapackages">https://src.fedoraproject.org/rpms/junit/commits/javapackages</a>

Is this the branch you use to build a module?

A friend sent me a list of package they were able to find in a module by some
dark magic. BTW what is the supported way to query this kind of information?

You say almost all of the 259 Java packages will be maintained as part of
modules, yet it's hard for me to find the rest.

Thanks.

ant-antlr: ant
ant-apache-bcel: ant
ant-apache-bsf: ant
ant-apache-log4j: ant
ant-apache-oro: ant
ant-apache-regexp: ant
ant-apache-resolver: ant
ant-apache-xalan2: ant
ant-commons-logging: ant
ant-commons-net: ant
ant-javamail: ant
ant-jdepend: ant
ant-jmf: ant
ant-jsch: ant
ant-junit5: ant
ant-junit: ant
ant-lib: ant
ant-swing: ant
ant-testutil: ant
ant-xz: ant
ant: ant
antlr-C++-doc: ant
antlr-tool: ant
aopalliance: maven
apache-commons-cli: maven
apache-commons-codec: maven
apache-commons-io: maven
apache-commons-lang3: maven
apache-commons-logging: ant
apache-commons-logging: maven
apache-commons-net: ant
atinject: maven
bcel: ant
bsf: ant
cdi-api: maven
geronimo-annotation: maven
glassfish-el-api: maven
google-guice: maven
guava20: maven
hamcrest-core: ant
hawtjni-runtime: maven
hawtjni-runtime: scala
httpcomponents-client: maven
httpcomponents-core: maven
jakarta-oro: ant
jansi-native: maven
jansi-native: scala
jansi: maven
jansi: scala
javamail: ant
jboss-interceptors-1.2-api: maven
jcl-over-slf4j: maven
jdepend: ant
jline: scala
jsch: ant
jsoup: maven
junit5: ant
junit: ant
jzlib: ant
log4j12: ant
maven-lib: maven
maven-resolver-api: maven
maven-resolver-connector-basic: maven
maven-resolver-impl: maven
maven-resolver-spi: maven
maven-resolver-transport-wagon: maven
maven-resolver-util: maven
maven-shared-utils: maven
maven-wagon-file: maven
maven-wagon-http-shared: maven
maven-wagon-http: maven
maven-wagon-provider-api: maven
maven: maven
opentest4j: ant
plexus-cipher: maven
plexus-classworlds: maven
plexus-containers-component-annotations: maven
plexus-interpolation: maven
plexus-sec-dispatcher: maven
plexus-utils: maven
python2-antlr: ant
regexp: ant
scala-apidoc: scala
scala-swing: scala
scala: scala
sisu-inject: maven
sisu-plexus: maven
slf4j: maven
univocity-parsers: ant
xalan-j2: ant
xerces-j2: ant
xml-commons-apis: ant
xml-commons-resolver: ant
xz-java: ant

Re: Orphaned some Java packages

By Mikolaj Izdebski at 03/28/2019 - 09:49

On Thu, Mar 28, 2019 at 12:49 AM Miro Hrončok < ... at redhat dot com> wrote:
Currently I maintain the following 4 modules/streams:

- javapackages-tools, stream 201801 (buildroot-only module, not
intended to be delivered to users)
- maven, stream 3.5
- ant, stream 1.10
- scala, stream 2.10

Below I explained how to get lists of packages in each of the modules.

IIRC google-gson is not part of any modules I am currently maintaining
in Fedora.

Correct.

First you need to find out module NSVC (name, stream version and
context). You can do that in many ways, for example to query Koji for
complete javapackages-tools module builds with highest version you can
run this query:

koji list-builds --type module --package javapackages-tools --state
COMPLETE -k version | head -3

Once you know NSVC you can see component builds corresponding to that
module using the following command:

koji list-tagged module-${NAME}-${STREAM}-${VERSION}-${CONTEXT}

For example:

koji list-tagged module-javapackages-tools-201801-2820190319130429-819b5873

Re: Orphaned some Java packages

By Christopher at 03/28/2019 - 14:44

On Thu, Mar 28, 2019 at 9:50 AM Mikolaj Izdebski < ... at redhat dot com> wrote:
How do I enable/install this module locally? It would be very helpful
for local builds/testing, but is not available in:
sudo dnf --releasever=30 module list

Re: Orphaned some Java packages

By Mikolaj Izdebski at 03/29/2019 - 05:23

On Thu, Mar 28, 2019 at 7:46 PM Christopher < ... at fedoraproject dot org> wrote:
The official, recommended way of building modules locally is "fedpkg
module-build-local". This command should take care of fetching and
installing all required dependencies specified in modulemd being
built. Therefore in this case it is enough to add dependency on
javapackages-tools and it should "just work", for both local and
remote builds.

The module is not included in any compose, therefore dnf won't be able
to find it in default repos. If you really want to install the module
on your system for some reason then you can use ODCS [1] to generate a
compose containing the module. Install ODCS client with "dnf install
odcs-client" and then request compose with "odcs create module
javapackages-tools:201801". ODCS will (usually) quickly create repo
with the module and output repo URL, which you can put in a config
file under /etc/yum.repos.d/, or pass to dnf using --repofrompath
option. Note that contents of javapackages-tools module are not signed
and therefore you need to skip GPG verification in order to be able to
install it.

[1] <a href="https://pagure.io/odcs" title="https://pagure.io/odcs">https://pagure.io/odcs</a>

Re: Orphaned some Java packages

By Christopher at 03/29/2019 - 19:13

On Fri, Mar 29, 2019 at 5:24 AM Mikolaj Izdebski < ... at redhat dot com> wrote:
Hmm. I don't know how to do modules yet. I don't know how to create a
modulemd, or where it lives, or which packages I need to put in which
module, or how to name modules, or anything. I just want to install
all the tools from javapackages-tools, so I can do a plain old `fedpkg
local` build of my regular RPMs. I know this isn't going to work in
Koji for Fedora... but it would help me, as a user of those tools,
have access to them for my own RPM building purposes.

It seems a bit crazy to me that we have packages built for Fedora that
aren't available for users to install. Why wouldn't we make everything
maximally available? I used to love Fedora, because I just play with
all the bits. But now, a lot of those bits are going away... I have
less to play with... and the focus seems more targeted towards
Fedora's internal needs, and not Fedora's users needs. Contributing to
Fedora is so much harder now. Do we have to make it harder by making
certain packages unavailable to regular users (and casual
packager-contributors like me)?

Re: Orphaned some Java packages

By Mikolaj Izdebski at 04/08/2019 - 12:20

On Sat, Mar 30, 2019 at 1:34 AM Christopher < ... at fedoraproject dot org> wrote:
You don't have to use these packages. You can keep using traditional,
"ursine" Java packages that are still available in non-modular repos.
These packages new owners who signed up to maintain them.

In addition to the above set of traditional, "ursine", packages, there
is also javapackages-tools module, that contains Java packages
intended for building certain other modules. Module maintainers can
choose whether they want to build their modules using ursine Java
packages, or using javapackages-tools module. Ursine package
maintainers have no such choice and they are limited to depending on
ursine Java packages only.

The original goal was to have a single set of modular packages that
would be used for both building other modules and for building
non-modular ("ursine") packages. However, in the end this set was
split/forked and now we have two package sets, but with different
maintainers. These packages are similar for now, but I expect them to
diverge more over time. I don't like this situation either, but I've
done everything I could to avoid it.

We already have packages that are built by Fedora and for Fedora, but
are not distributed to users for various reasons. These include
glibc32, some buildroot overrides and even non-distributable-rpms [1],
which are not only not included in Fedora repos, but also users are
also blocked from downloading them from Koji.

[1] <a href="https://fedoraproject.org/wiki/Non-distributable-rpms" title="https://fedoraproject.org/wiki/Non-distributable-rpms">https://fedoraproject.org/wiki/Non-distributable-rpms</a>

Re: Orphaned some Java packages

By Christopher at 04/08/2019 - 13:31

On Mon, Apr 8, 2019 at 12:21 PM Mikolaj Izdebski < ... at redhat dot com> wrote:
I know I don't have to use them, but... I *want* to use them. My
understanding is that those new owners maintaining them is an interim
solution, *minimally* maintained to prevent catastrophe, not the
stable long-term solution. I'd prefer the go to where the fully
maintained packages are going... not stay with the minimally
maintained ones. Besides, the catastrophe can still occur, if we don't
work to migrate while we have the chance.

I'm trying to get on board the modular train, and convert my ursine
packages to modules. I want to learn how to do this correctly locally.
How can I get local builds of my modular packages, using the versions
I want them to use from the javapackages-tools module? I think the
lack of local availability of the packages in this module will make it
harder to transition to the modular versions, and will keep the
requirement for the ursine packages around longer.

I understand, and appreciate what you've done to sound the alarm, and
the effort you've put into these packages to benefit the Java
ecosystem within Fedora. That's why I'm trying to follow the path
you're going, rather than stay on the ursine packages. I'm just
finding it extremely difficult to do so, because I do not understand
how to do modules, and the fact that some of them are less available
than others, makes it hard to "play" to learn on my own.

I wasn't aware of the precedent, because the current situation is the
first time it has impacted me. From the linked precedent, it still
seems like that should be a last resort... an exception, not the norm.
Plus, I think there are things valuable to users, not just packagers,
contained in javapackages-tools (build-classpath, for example).

Re: Orphaned some Java packages

By Aleksandra Bookwar at 03/29/2019 - 06:24

Hi, Mikolaj,

On Fri, Mar 29, 2019 at 10:24 AM Mikolaj Izdebski < ... at redhat dot com>
wrote:

if I understand correctly, you say that javapackages-tools module is not
included in any Fedora Modular repositories. But you want it to be included
in Fedora buildroot through Ursa Major.

Can you explain why you don't make it available through a Modular repo?

Re: Orphaned some Java packages

By Mikolaj Izdebski at 04/08/2019 - 11:58

On Fri, Mar 29, 2019 at 11:25 AM Aleksandra Fedorova < ... at bookwar dot info> wrote:
That is correct.

No, not any longer.

Because that requires too much effort from my side. More effort that I
can spend on Fedora package maintenance. Shipping content to users has
serious implications, coming from "Package maintainers responsibility"
and other policies and documents. By limiting "supported" use case of
the module to only building other Fedora package I can reduce the work
required to maintain the module by at least a factor of two.

Re: Orphaned some Java packages

By =?UTF-8?B?TWlyb... at 03/28/2019 - 10:04

On 28. 03. 19 14:49, Mikolaj Izdebski wrote:
So from the 259 orphaned packages, how many are actually in modules?

Thanks.

I will try this. Thank You.

Re: Orphaned some Java packages

By Mikolaj Izdebski at 03/28/2019 - 10:51

On Thu, Mar 28, 2019 at 3:04 PM Miro Hrončok < ... at redhat dot com> wrote:
When you look at source package counts, only 127 out of 259 orphaned
packages are part of javapackages-tools module. This is because the
module is built with lots of non-essential features disabled through
multiple bconds [1]

[1] <a href="https://src.fedoraproject.org/modules/javapackages-tools/blob/201801/f/javapackages-tools.yaml#_32" title="https://src.fedoraproject.org/modules/javapackages-tools/blob/201801/f/javapackages-tools.yaml#_32">https://src.fedoraproject.org/modules/javapackages-tools/blob/201801/f/j...</a>

Re: Orphaned some Java packages

By =?ISO-8859-1?Q?... at 03/28/2019 - 03:43

Dne 28. 03. 19 v 0:48 Miro Hrončok napsal(a):

Trying to take look from the other side, the java.yaml might need some
love [1], because the GH links are broken [2, 3]

Vít

[1] <a href="https://src.fedoraproject.org/modules/java/blob/master/f/java.yaml" title="https://src.fedoraproject.org/modules/java/blob/master/f/java.yaml">https://src.fedoraproject.org/modules/java/blob/master/f/java.yaml</a>

[2] <a href="https://src.fedoraproject.org/modules/java/blob/master/f/java.yaml#_18" title="https://src.fedoraproject.org/modules/java/blob/master/f/java.yaml#_18">https://src.fedoraproject.org/modules/java/blob/master/f/java.yaml#_18</a>

[3] <a href="https://src.fedoraproject.org/modules/java/blob/master/f/java.yaml#_19" title="https://src.fedoraproject.org/modules/java/blob/master/f/java.yaml#_19">https://src.fedoraproject.org/modules/java/blob/master/f/java.yaml#_19</a>

Re: Orphaned some Java packages

By Mikolaj Izdebski at 03/28/2019 - 09:53

On Thu, Mar 28, 2019 at 8:44 AM Vít Ondruch < ... at redhat dot com> wrote:
java module doesn't have any complete builds. It is not actively maintained.

Re: Orphaned some Java packages

By =?ISO-8859-1?Q?... at 03/29/2019 - 06:09

Dne 28. 03. 19 v 14:53 Mikolaj Izdebski napsal(a):

Good to know that we have unmaintained modules in Fedora, nobody notice,
nobody cares, there is no procedure how to get rid of them, etc ...

Vít