The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired.
Grep the list for your FAS name, follow the transitive deps: https://churchyard.fedorapeople.org/orphans-2019-03-11.txt
Request package ownership via releng ticket: https://pagure.io/releng/issues
Package (co)maintainers Status Change ================================================================================ OSGi-bundle-ant-task orphan 5 weeks ago SimplyHTML mizdebsk, orphan 4 weeks ago aether-connector-okhttp galileo, mizdebsk, orphan 4 weeks ago ant-contrib davidcl, mizdebsk, orphan 4 weeks ago antlr3 dchen, lef, mizdebsk, 4 weeks ago mjakubicek, orphan, walters aopalliance mizdebsk, orphan 4 weeks ago apache-commons-beanutils fnasser, mizdebsk, orphan, 4 weeks ago spike apache-commons-collections jcapik, mizdebsk, orphan 4 weeks ago apache-commons-collections4 mizdebsk, orphan 4 weeks ago apache-commons-compress mizdebsk, mkoncek, orphan, 4 weeks ago spike apache-commons-configuration fnasser, mizdebsk, orphan, 4 weeks ago spike apache-commons-csv lef, mizdebsk, orphan, spike 4 weeks ago apache-commons-discovery lkundrak, mizdebsk, orphan, 4 weeks ago spike apache-commons-el fnasser, mizdebsk, orphan, 4 weeks ago spike apache-commons-fileupload jerboaa, mizdebsk, mmraka, 4 weeks ago orphan, spike apache-commons-jexl mizdebsk, orphan 4 weeks ago apache-commons-jxpath fnasser, mizdebsk, orphan, 4 weeks ago spike apache-commons-net mizdebsk, orphan, spike 4 weeks ago apache-ivy mizdebsk, orphan 4 weeks ago apache-james-project lef, mizdebsk, orphan 4 weeks ago apache-logging-parent mizdebsk, orphan 4 weeks ago apache-mime4j lef, mizdebsk, orphan 4 weeks ago apache-parent mizdebsk, orphan 4 weeks ago apache-rat mizdebsk, orphan 4 weeks ago apache-resource-bundles mizdebsk, orphan 4 weeks ago apiguardian mizdebsk, orphan 4 weeks ago aqute-bnd jcapik, mizdebsk, orphan 4 weeks ago args4j jcapik, mizdebsk, orphan 4 weeks ago atinject kdaniel, mizdebsk, orphan 4 weeks ago avalon-framework jerboaa, mizdebsk, orphan 4 weeks ago avalon-logkit jerboaa, mizdebsk, orphan 4 weeks ago base64coder jcapik, mizdebsk, orphan 4 weeks ago batik jvanek, mizdebsk, orphan 4 weeks ago bcel mizdebsk, orphan 4 weeks ago bea-stax jcapik, mizdebsk, orphan 4 weeks ago beust-jcommander jcapik, jvanek, mizdebsk, 4 weeks ago orphan blobby orphan 5 weeks ago bsf choeger, mizdebsk, orphan 4 weeks ago bsh mizdebsk, orphan 4 weeks ago c3p0 dchen, lef, orphan 4 weeks ago cal10n mizdebsk, orphan 4 weeks ago catkin orphan, rmattes, robotics-sig, 7 weeks ago thofmann checkstyle dbhole, greghellings, lef, 4 weeks ago mizdebsk, nsantos, orphan, rmyers clang5.0 orphan, tstellar 5 weeks ago clang6.0 orphan, tstellar 5 weeks ago cmusphinx3 jjames, orphan 1 weeks ago codemodel gil, mizdebsk, orphan 4 weeks ago compat-rust-serde_derive orphan 0 weeks ago dain-snappy mizdebsk, orphan 4 weeks ago dcm4che-test orphan 5 weeks ago decentxml mizdebsk, orphan 4 weeks ago devilspie orphan 3 weeks ago easymock akurtakov, ctubbsii, dbhole, 4 weeks ago fnasser, mizdebsk, orphan eclipse-m2e-antlr eclipse-sig, mizdebsk, orphan 4 weeks ago eclipse-m2e-buildhelper eclipse-sig, mizdebsk, orphan 4 weeks ago eclipse-m2e-core eclipse-sig, galileo, 4 weeks ago mizdebsk, orphan eclipse-m2e-cxf eclipse-sig, mizdebsk, orphan 4 weeks ago eclipse-m2e-egit eclipse-sig, mizdebsk, orphan 4 weeks ago eclipse-m2e-maven-dependency- mizdebsk, orphan 4 weeks ago plugin eclipse-m2e-mavenarchiver eclipse-sig, mizdebsk, orphan 4 weeks ago eclipse-m2e-mavendev eclipse-sig, mizdebsk, orphan 4 weeks ago eclipse-m2e-modello eclipse-sig, mizdebsk, orphan 4 weeks ago eclipse-m2e-plexus eclipse-sig, mizdebsk, orphan 4 weeks ago eclipse-m2e-sisu eclipse-sig, mizdebsk, orphan 4 weeks ago eclipse-m2e-sourcelookup eclipse-sig, mizdebsk, orphan 4 weeks ago eclipse-m2e-takari mizdebsk, orphan 4 weeks ago eclipse-m2e-tycho eclipse-sig, mizdebsk, orphan 4 weeks ago eclipse-m2e-workspace eclipse-sig, mizdebsk, orphan 4 weeks ago exec-maven-plugin mizdebsk, orphan 4 weeks ago felix-bundlerepository mizdebsk, orphan 4 weeks ago felix-osgi-obr jcapik, mizdebsk, orphan 4 weeks ago felix-utils jcapik, mizdebsk, orphan 4 weeks ago geronimo-jaspic-spec mizdebsk, orphan 4 weeks ago geronimo-jms mizdebsk, orphan 4 weeks ago geronimo-jpa lef, mizdebsk, orphan 4 weeks ago geronimo-jta mizdebsk, orphan 4 weeks ago geronimo-parent-poms mizdebsk, orphan 4 weeks ago glacier-cli orphan 5 weeks ago glassfish-dtd-parser gil, mizdebsk, orphan 4 weeks ago glassfish-fastinfoset gil, mizdebsk, orphan 4 weeks ago glassfish-jaxb mizdebsk, orphan 4 weeks ago glassfish-jsp mizdebsk, orphan 4 weeks ago glassfish-jsp-api kdaniel, mizdebsk, orphan 4 weeks ago gnumed orphan 5 weeks ago google-gson dchen, jcapik, jerboaa, 4 weeks ago kdaniel, lef, mizdebsk, orphan google-guice mizdebsk, orphan 4 weeks ago gpars gil, mizdebsk, orphan 4 weeks ago gradle mizdebsk, orphan 4 weeks ago groovy mizdebsk, msrb, orphan 4 weeks ago guava20 mizdebsk, orphan 4 weeks ago hamster-time-tracker orphan 5 weeks ago hawtjni gil, goldmann, mizdebsk, 4 weeks ago orphan hoard orphan 35 weeks ago hsqldb fnasser, jjohnstn, mizdebsk, 4 weeks ago orphan httpcomponents-project mizdebsk, orphan 4 weeks ago httpunit fnasser, mizdebsk, orphan 4 weeks ago icu4j akurtakov, fnasser, kdaniel, 4 weeks ago lef, mizdebsk, orphan iris kde-sig, orphan, rdieter, 3 weeks ago slankes istack-commons mizdebsk, orphan 4 weeks ago jackson gil, mizdebsk, orphan 4 weeks ago jakarta-commons-httpclient dbhole, ke4qqq, mizdebsk, 4 weeks ago orphan jansi goldmann, mizdebsk, orphan 4 weeks ago jansi-native goldmann, mizdebsk, orphan 4 weeks ago java-service-wrapper arg, gil, lef, mizdebsk, 4 weeks ago orphan javacc jcapik, mizdebsk, orphan 4 weeks ago javacc-maven-plugin jcapik, mizdebsk, orphan 4 weeks ago jaxen mizdebsk, orphan 4 weeks ago jchardet mizdebsk, orion, orphan 4 weeks ago jdepend goldmann, jcapik, mizdebsk, 4 weeks ago orphan jdependency mizdebsk, orphan 4 weeks ago jeromq mizdebsk, orphan 4 weeks ago jettison davidx, mizdebsk, orphan 4 weeks ago jetty eclipse-sig, kdaniel, 4 weeks ago mizdebsk, orphan jetty-alpn mizdebsk, orphan 4 weeks ago jetty-alpn-api lef, mizdebsk, orphan 4 weeks ago jetty-artifact-remote-resources mizdebsk, orphan 4 weeks ago jetty-assembly-descriptors mizdebsk, orphan 4 weeks ago jetty-build-support mizdebsk, orphan 4 weeks ago jetty-distribution-remote- mizdebsk, orphan 4 weeks ago resources jetty-parent mizdebsk, orphan 4 weeks ago jetty-schemas mizdebsk, orphan 4 weeks ago jetty-test-helper mizdebsk, orphan 4 weeks ago jetty-test-policy mizdebsk, orphan 4 weeks ago jetty-toolchain mizdebsk, orphan 4 weeks ago jetty-version-maven-plugin mizdebsk, orphan 4 weeks ago jetty8 eclipse-sig, mizdebsk, orphan, 4 weeks ago pmackinn jflex jcapik, mizdebsk, orphan 4 weeks ago jigdo jsteffan, orphan 5 weeks ago jmapviewer mizdebsk, orphan 4 weeks ago jna dbhole, lfarkas, mizdebsk, 4 weeks ago orphan joda-convert mizdebsk, orphan, spike 4 weeks ago jortho mizdebsk, orphan 4 weeks ago jsch-agent-proxy mizdebsk, orphan 4 weeks ago json_simple mizdebsk, orphan, pmackinn, 4 weeks ago stevetraylen jsoup jcapik, mizdebsk, orphan 4 weeks ago jsr-311 gil, mizdebsk, orphan 4 weeks ago junit kdaniel, mizdebsk, orphan 4 weeks ago junit5 mizdebsk, orphan 4 weeks ago jvnet-parent mizdebsk, orphan 4 weeks ago kapow orphan 5 weeks ago keybinder ohaessler, orphan 3 weeks ago kohsuke-pom lef, mizdebsk, msrb, orphan 4 weeks ago kxml mizdebsk, orphan 4 weeks ago labyrinth orphan 6 weeks ago libkexif orphan, rdieter 3 weeks ago log4j devrim, mizdebsk, orphan 4 weeks ago maven akurtakov, jamielinux, 4 weeks ago mizdebsk, msrb, orphan maven-antrun-plugin mizdebsk, orphan 4 weeks ago maven-archetype mizdebsk, orphan 4 weeks ago maven-archiver akurtakov, mizdebsk, orphan 4 weeks ago maven-artifact-resolver mizdebsk, orphan 4 weeks ago maven-artifact-transfer mizdebsk, orphan 4 weeks ago maven-assembly-plugin gil, huwang, jcapik, mizdebsk, 4 weeks ago orphan maven-clean-plugin mizdebsk, orphan 4 weeks ago maven-compiler-plugin mizdebsk, orphan 4 weeks ago maven-dependency-analyzer mizdebsk, orphan 4 weeks ago maven-dependency-plugin mizdebsk, orphan 4 weeks ago maven-dependency-tree mizdebsk, orphan 4 weeks ago maven-doxia akurtakov, mef, mizdebsk, 4 weeks ago orphan maven-doxia-sitetools akurtakov, dbhole, mizdebsk, 4 weeks ago orphan maven-enforcer jcapik, mizdebsk, orphan 4 weeks ago maven-file-management mizdebsk, orphan 4 weeks ago maven-filtering mizdebsk, orphan 4 weeks ago maven-gpg-plugin mizdebsk, orphan 4 weeks ago maven-idea-plugin mizdebsk, orphan 4 weeks ago maven-indexer galileo, mizdebsk, orphan 4 weeks ago maven-invoker mizdebsk, orphan 4 weeks ago maven-jar-plugin mizdebsk, orphan 4 weeks ago maven-jarsigner-plugin jcapik, mizdebsk, orphan 4 weeks ago maven-javadoc-plugin mizdebsk, orphan 4 weeks ago maven-mapping mizdebsk, orphan 4 weeks ago maven-osgi mizdebsk, orphan 4 weeks ago maven-parent mizdebsk, orphan 4 weeks ago maven-plugin-build-helper mizdebsk, orphan 4 weeks ago maven-plugin-bundle jcapik, mizdebsk, orphan 4 weeks ago maven-plugin-testing jcapik, mizdebsk, orphan, 4 weeks ago yyang maven-plugin-tools jcapik, mizdebsk, orphan, 4 weeks ago yyang maven-plugins-pom mizdebsk, orphan 4 weeks ago maven-reporting-api mizdebsk, orphan 4 weeks ago maven-reporting-exec mizdebsk, orphan 4 weeks ago maven-reporting-impl mizdebsk, orphan 4 weeks ago maven-repository-builder mizdebsk, orphan 4 weeks ago maven-resolver mizdebsk, orphan 4 weeks ago maven-script-interpreter mizdebsk, orphan 4 weeks ago maven-shade-plugin jcapik, mizdebsk, orphan, 4 weeks ago pingou maven-shared-incremental mizdebsk, orphan 4 weeks ago maven-shared-io mizdebsk, orphan 4 weeks ago maven-shared-jar mizdebsk, orphan 4 weeks ago maven-shared-jarsigner mizdebsk, orphan 4 weeks ago maven-shared-utils mizdebsk, orphan 4 weeks ago maven-site-plugin mizdebsk, orphan 4 weeks ago maven-source-plugin mizdebsk, orphan 4 weeks ago maven-stapler-plugin mizdebsk, orphan 4 weeks ago maven-surefire akurtakov, jcapik, mizdebsk, 4 weeks ago orphan maven-toolchains-plugin mizdebsk, orphan 4 weeks ago maven-verifier mizdebsk, orphan 4 weeks ago maven-wagon akurtakov, dbhole, fnasser, 4 weeks ago jcapik, mizdebsk, orphan, yyang mchange-commons mmraka, orphan 4 weeks ago memaker orphan 6 weeks ago mingw-webkitgtk epienbro, orphan, pfor 3 weeks ago mingw-webkitgtk3 epienbro, orphan, pfor 3 weeks ago mnemonicsetter mizdebsk, orphan 4 weeks ago modello fnasser, mizdebsk, orphan, 4 weeks ago yyang mojo-parent mizdebsk, orphan 4 weeks ago multiverse mizdebsk, orphan 4 weeks ago munge-maven-plugin mizdebsk, orphan 4 weeks ago nautilus-pastebin orphan 5 weeks ago nekohtml fnasser, jjohnstn, mizdebsk, 4 weeks ago orphan netty ctubbsii, lef, mizdebsk, 4 weeks ago orphan nut-nutrition orphan 5 weeks ago objectweb-asm3 dwalluck, fnasser, mizdebsk, 4 weeks ago orphan objectweb-pom mizdebsk, orphan 4 weeks ago okio galileo, mizdebsk, orphan 4 weeks ago opentest4j mizdebsk, orphan 4 weeks ago os-maven-plugin ctubbsii, mizdebsk, orphan 4 weeks ago osgi-compendium mizdebsk, orphan 4 weeks ago osgi-core mizdebsk, orphan 4 weeks ago pl bagnara, mef, orphan 4 weeks ago plexus-ant-factory mizdebsk, orphan 4 weeks ago plexus-archiver dbhole, jcapik, mizdebsk, 4 weeks ago orphan plexus-bsh-factory mizdebsk, orphan 4 weeks ago plexus-classworlds dbhole, fnasser, mizdebsk, 4 weeks ago orphan plexus-cli mizdebsk, orphan 4 weeks ago plexus-compiler mizdebsk, orphan 4 weeks ago plexus-component-factories-pom mizdebsk, orphan 4 weeks ago plexus-components-pom mizdebsk, orphan 4 weeks ago plexus-containers dbhole, fnasser, mizdebsk, 4 weeks ago orphan, yyang plexus-digest jcapik, mizdebsk, orphan 4 weeks ago plexus-i18n dbhole, jcapik, mizdebsk, 4 weeks ago orphan plexus-interactivity mizdebsk, orphan 4 weeks ago plexus-interpolation gil, jcapik, mizdebsk, orphan 4 weeks ago plexus-io jcapik, mizdebsk, orphan 4 weeks ago plexus-languages mizdebsk, orphan 4 weeks ago plexus-resources jcapik, mizdebsk, orphan 4 weeks ago plexus-utils fnasser, mizdebsk, orphan 4 weeks ago plexus-velocity jcapik, mizdebsk, orphan 4 weeks ago python-ceilometermiddleware orphan 74 weeks ago python-cookies adamwill, orphan 10 weeks ago python-django-post_office orphan 5 weeks ago python-django-stopforumspam orphan 5 weeks ago python-gencpp orphan, rmattes, robotics-sig, 7 weeks ago thofmann python-genlisp orphan, rmattes, robotics-sig, 7 weeks ago thofmann python-genmsg orphan, rmattes, robotics-sig, 7 weeks ago thofmann python-genpy orphan, rmattes, robotics-sig, 7 weeks ago thofmann python-kafka orphan 83 weeks ago python-pankoclient orphan 83 weeks ago python-ripe-atlas-cousteau orphan 10 weeks ago python-ripe-atlas-sagan orphan 10 weeks ago python-socketIO-client orphan 10 weeks ago python-urwid fabiand, lmacken, orphan 3 weeks ago qblade orphan 1 weeks ago qcodeedit orphan 3 weeks ago qdox mizdebsk, orphan 4 weeks ago regexp mizdebsk, orphan 4 weeks ago ripe-atlas-tools orphan 10 weeks ago ros-release orphan, rmattes, robotics-sig, 7 weeks ago thofmann rospack orphan, rmattes, robotics-sig, 7 weeks ago thofmann rssdler orphan 5 weeks ago rubygem-capybara_minitest_spec orphan 4 weeks ago rubygem-fakeweb orphan 3 weeks ago rubygem-fog orphan 0 weeks ago rubygem-fog-atmos orphan 0 weeks ago rubygem-fog-aws orphan 0 weeks ago rubygem-fog-brightbox orphan 0 weeks ago rubygem-fog-ecloud orphan 0 weeks ago rubygem-fog-profitbricks orphan 0 weeks ago rubygem-fog-radosgw orphan 0 weeks ago rubygem-fog-riakcs orphan 0 weeks ago rubygem-fog-sakuracloud orphan 0 weeks ago rubygem-fog-serverlove orphan 0 weeks ago rubygem-fog-softlayer orphan 0 weeks ago rubygem-fog-storm_on_demand orphan 0 weeks ago rubygem-fog-terremark orphan 0 weeks ago rubygem-fog-vmfusion orphan 0 weeks ago rubygem-fog-voxel orphan 0 weeks ago rubygem-multipart orphan 0 weeks ago rubygem-rabl orphan 1 weeks ago rubygem-rails-observers orphan 4 weeks ago rubygem-riot orphan 1 weeks ago rust-futures-macro-async orphan 0 weeks ago rust-futures-macro-await orphan 0 weeks ago rust-syn0.13 orphan 0 weeks ago rust-syn0.14 orphan 0 weeks ago scout orphan 6 weeks ago sisu eclipse-sig, mizdebsk, orphan 4 weeks ago sisu-mojos eclipse-sig, mizdebsk, orphan 4 weeks ago sketch orphan 83 weeks ago snakeyaml jcapik, mizdebsk, mmorsi, 4 weeks ago orphan sonatype-oss-parent mizdebsk, orphan 4 weeks ago sonatype-plugins-parent mizdebsk, orphan 4 weeks ago sphinxbase jjames, orphan 1 weeks ago sphinxtrain jjames, orphan 1 weeks ago stax2-api jcapik, mizdebsk, orphan 4 weeks ago stringtemplate4 lef, mizdebsk, mjakubicek, 4 weeks ago orphan superkaramba jreznik, kde-sig, orphan, 3 weeks ago rdieter, than synaptic moceap, orphan 1 weeks ago tagsoup gil, mizdebsk, orphan 4 weeks ago takari-archiver dchen, mizdebsk, orphan 4 weeks ago takari-filemanager dchen, galileo, mizdebsk, 4 weeks ago orphan takari-incrementalbuild dchen, mizdebsk, orphan 4 weeks ago takari-lifecycle dchen, mizdebsk, orphan 4 weeks ago takari-plugin-testing mizdebsk, orphan 4 weeks ago takari-pom mizdebsk, orphan 4 weeks ago takari-tycho-support mizdebsk, orphan 4 weeks ago toothchart orphan 6 weeks ago txw2 mizdebsk, orphan 4 weeks ago univocity-parsers mizdebsk, orphan 4 weeks ago velocity devrim, mizdebsk, orphan 4 weeks ago wicd orphan 3 weeks ago woodstox-core jcapik, mizdebsk, orphan 4 weeks ago xalan-j2 kdaniel, mizdebsk, orphan 4 weeks ago xbean kdaniel, mizdebsk, orphan 4 weeks ago xcdroast orphan 2 weeks ago xml-maven-plugin ke4qqq, mizdebsk, orphan 4 weeks ago xmlrpc gil, kdaniel, mizdebsk, orphan 4 weeks ago xmvn mizdebsk, msrb, orphan 4 weeks ago xom dbhole, dchen, mizdebsk, 4 weeks ago orphan xsom mizdebsk, orphan 4 weeks ago xstream mizdebsk, msimacek, orphan 4 weeks ago xword orphan 6 weeks ago xz-java kdaniel, mizdebsk, orphan 4 weeks ago zinc mizdebsk, orphan 4 weeks ago
The following packages require above mentioned packages: https://churchyard.fedorapeople.org/orphans-2019-03-11.txt
Affected (co)maintainers abbot: guava20, easymock, google-gson abo: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn acaringi: maven-jar-plugin, maven-javadoc-plugin, glassfish-jaxb, maven-compiler-plugin, httpcomponents-project, snakeyaml, jackson, geronimo-parent-poms, aqute-bnd, bcel, maven-antrun-plugin, jakarta-commons-httpclient, geronimo-jta, guava20, exec-maven-plugin, netty, gradle, apache-rat, antlr3, log4j, xmvn, xstream, apache-commons-discovery, google-guice, c3p0, maven-assembly-plugin, apache-ivy, json_simple, easymock, jna achernya: google-gson adamwill: python-cookies aeperezt: rubygem-fakeweb akurtakov: maven-archiver, apache-commons-jxpath, xz-java, maven-jar-plugin, maven-javadoc-plugin, apache-parent, maven-doxia-sitetools, objectweb-asm3, avalon-framework, plexus-utils, regexp, junit, geronimo-parent-poms, kxml, apache-commons-net, batik, bcel, jetty, args4j, maven-surefire, apache-commons-el, apache-resource-bundles, apache-mime4j, atinject, jakarta-commons-httpclient, glassfish-jsp-api, maven-antrun-plugin, nekohtml, opentest4j, xalan-j2, maven-reporting-api, guava20, apache-commons-fileupload, apache-commons-collections, maven-doxia, beust-jcommander, exec-maven-plugin, tagsoup, google-gson, apache-commons-csv, glassfish-jsp, gradle, maven, maven-file-management, maven-enforcer, apiguardian, jsoup, apache-commons-collections4, xmvn, maven-wagon, maven-assembly-plugin, osgi-core, junit5, apache-ivy, bsf, maven-parent, apache-commons-compress, jdepend, plexus-containers, ant-contrib, apache-commons-beanutils, bsh, xmlrpc, icu4j, maven-reporting-impl, json_simple, easymock, jvnet-parent, maven-plugin-bundle, javacc-maven-plugin, maven-source-plugin alcapcom: regexp alexlan: apache-ivy, apache-commons-net, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn am1g0: google-gson amdunn: pl amitshah: plexus-utils andreamanzi: google-gson apevec: python-kafka arg: apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, java-service-wrapper, xmvn, geronimo-jms arobinso: apache-commons-jxpath, xz-java, maven-jar-plugin, maven-javadoc-plugin, objectweb-asm3, avalon-framework, regexp, junit, kxml, apache-commons-net, batik, bcel, jetty, args4j, apache-commons-el, apache-resource-bundles, opentest4j, apache-mime4j, atinject, jakarta-commons-httpclient, glassfish-jsp-api, nekohtml, xalan-j2, guava20, apache-commons-fileupload, apache-commons-collections, beust-jcommander, tagsoup, jvnet-parent, google-gson, apache-commons-csv, glassfish-jsp, gradle, maven, apiguardian, jsoup, apache-commons-collections4, xmvn, maven-assembly-plugin, osgi-core, junit5, apache-ivy, bsf, plexus-containers, apache-commons-compress, jdepend, xmlrpc, icu4j, json_simple, easymock, jaxen, javacc-maven-plugin astokes: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn, apache-commons-discovery astro-sig: apache-ivy, apache-commons-net, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn athoscr: python-cookies avsej: google-gson awood: aopalliance, maven bagnara: pl bashton: apache-commons-net bcotton: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn beekhof: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn, apache-commons-discovery berrange: plexus-utils besser82: apache-ivy, google-gson, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, xmvn bizdelnick: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn bkearney: apache-ivy, apache-commons-net, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn blackfile: apache-commons-net bonzini: plexus-utils branto: junit braoru: bsh brolley: plexus-utils, junit, aopalliance, apache-ivy brouhaha: apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, antlr3, xmvn bruno: apache-ivy, apache-commons-net, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn bsjones: apache-ivy, apache-commons-net, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn bubeck: apache-commons-net cagney: junit caniszczyk: google-gson, jetty, apache-commons-compress, args4j, osgi-core caolanm: apache-ivy, apache-commons-net, maven-jar-plugin, bcel, gradle, maven-javadoc-plugin, ant-contrib, bsh, xmvn carlwgeorge: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn cdamian: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn cerberus: apache-ivy, apache-commons-net, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn, maven-plugin-bundle cfeist: bsf cfu: apache-ivy, apache-commons-net chitlesh: apache-ivy, apache-commons-net, apache-commons-compress choeger: bsf churchyard: google-gson cicku: apache-ivy cipherboy: apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, jakarta-commons-httpclient, xalan-j2, xmvn, avalon-framework, jvnet-parent, velocity, maven-assembly-plugin clalance: bsf comzeradd: google-gson coolsvap: apache-ivy, maven-jar-plugin, gradle, maven-javadoc-plugin, apache-parent, xmvn, apache-commons-collections cottsay: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn cquad: apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, bsh, maven-compiler-plugin, xmvn, avalon-framework, apache-commons-collections4 crobinso: plexus-utils csutherl: apache-ivy, maven-jar-plugin, gradle, maven-javadoc-plugin, xmvn, apache-commons-collections ctubbsii: qdox, maven-jar-plugin, maven-javadoc-plugin, maven-source-plugin, sonatype-oss-parent, apache-parent, jetty8, glassfish-jaxb, checkstyle, maven-compiler-plugin, httpcomponents-project, avalon-framework, jackson, avalon-logkit, junit, geronimo-parent-poms, apache-commons-net, maven-enforcer, jetty, jsr-311, maven-antrun-plugin, apache-resource-bundles, maven-surefire, atinject, jakarta-commons-httpclient, glassfish-jsp-api, aopalliance, geronimo-jta, guava20, apache-commons-collections, beust-jcommander, netty, google-gson, glassfish-jsp, gradle, apache-rat, istack-commons, apache-commons-configuration, maven, maven-file-management, xmvn, xstream, apache-commons-collections4, apache-commons-discovery, geronimo-jms, google-guice, c3p0, txw2, maven-assembly-plugin, apache-ivy, hsqldb, apache-commons-compress, jdepend, ant-contrib, apache-commons-beanutils, bsh, jettison, hawtjni, json_simple, velocity, easymock, jvnet-parent, log4j, os-maven-plugin cwickert: keybinder dachary: junit daveisfera: clang5.0 davidcl: apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, ant-contrib, xmvn davidx: jvnet-parent, jettison, javacc-maven-plugin dbhole: apache-commons-jxpath, xz-java, maven-jar-plugin, maven-javadoc-plugin, plexus-i18n, sonatype-oss-parent, checkstyle, maven-doxia-sitetools, objectweb-asm3, avalon-framework, plexus-utils, regexp, plexus-archiver, junit, kxml, apache-commons-net, batik, bcel, jetty, apache-commons-el, apache-resource-bundles, opentest4j, jakarta-commons-httpclient, apache-mime4j, atinject, glassfish-jsp-api, nekohtml, xalan-j2, plexus-classworlds, apache-commons-fileupload, beust-jcommander, tagsoup, jvnet-parent, apache-commons-csv, glassfish-jsp, gradle, maven, apiguardian, jsoup, xmvn, xom, maven-wagon, maven-assembly-plugin, junit5, plexus-containers, apache-ivy, bsf, apache-commons-compress, jdepend, xmlrpc, icu4j, plexus-interpolation, json_simple, easymock, jaxen, jna, javacc-maven-plugin dcallagh: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn dchen: glassfish-fastinfoset, maven-jar-plugin, maven-javadoc-plugin, plexus-compiler, apache-parent, stax2-api, glassfish-jaxb, avalon-framework, jackson, plexus-utils, junit, regexp, snakeyaml, geronimo-parent-poms, apache-commons-net, takari-archiver, jetty, maven-antrun-plugin, args4j, apache-resource-bundles, maven-enforcer, apache-mime4j, atinject, jakarta-commons-httpclient, jansi, nekohtml, xalan-j2, aopalliance, geronimo-jta, eclipse-m2e-workspace, guava20, takari-lifecycle, beust-jcommander, exec-maven-plugin, woodstox-core, google-gson, netty, apache-commons-csv, gradle, apache-rat, maven-dependency-plugin, antlr3, apache-commons-configuration, maven, xmvn, takari-incrementalbuild, xstream, google-guice, c3p0, takari-filemanager, xom, maven-assembly-plugin, apache-ivy, plexus-containers, codemodel, apache-commons-compress, jdepend, apache-commons-beanutils, jettison, jetty-alpn-api, icu4j, maven-plugin-tools, easymock, jvnet-parent, maven-plugin-bundle, log4j, javacc-maven-plugin deamn: apache-ivy deji: google-gson denisarnaud: qdox, maven-jar-plugin, maven-javadoc-plugin, jetty8, glassfish-jaxb, checkstyle, httpcomponents-project, avalon-framework, jackson, avalon-logkit, junit, geronimo-parent-poms, apache-commons-net, jetty, jsr-311, apache-resource-bundles, atinject, jakarta-commons-httpclient, glassfish-jsp-api, aopalliance, geronimo-jta, guava20, apache-commons-collections, google-gson, netty, glassfish-jsp, gradle, apache-rat, istack-commons, apache-commons-configuration, maven, maven-file-management, xmvn, xstream, geronimo-jms, apache-commons-discovery, google-guice, c3p0, txw2, maven-assembly-plugin, apache-ivy, hsqldb, apache-commons-compress, apache-commons-beanutils, jettison, hawtjni, json_simple, velocity, jvnet-parent, log4j devos: apache-ivy, apache-commons-net, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn devrim: apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, log4j, xmvn, velocity dgoodwin: aopalliance, maven dignan: apache-ivy, apache-commons-net, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn djuran: apache-commons-net dmalcolm: apache-commons-compress dmick: junit dmoluguw: xz-java, maven-jar-plugin, maven-javadoc-plugin, regexp, avalon-framework, junit, apache-commons-net, bcel, maven-surefire, jakarta-commons-httpclient, xalan-j2, gradle, xmvn, maven-assembly-plugin, junit5, bsf, apache-ivy, jdepend, jvnet-parent, velocity domcleal: bsf dominik: jackson, apache-ivy, jakarta-commons-httpclient drago01: jna drsmith2: plexus-utils, apache-ivy dtardon: bsh, apache-commons-net, bcel dwalluck: apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, objectweb-asm3, xmvn, apache-commons-discovery, junit dwmw2: plexus-utils dwrobel: apache-ivy ebaron: apache-commons-jxpath, xz-java, maven-jar-plugin, maven-javadoc-plugin, objectweb-asm3, avalon-framework, regexp, junit, kxml, apache-commons-net, batik, bcel, jetty, apache-commons-el, apache-resource-bundles, opentest4j, apache-mime4j, atinject, xalan-j2, glassfish-jsp-api, nekohtml, apache-commons-fileupload, beust-jcommander, tagsoup, apache-commons-csv, glassfish-jsp, gradle, apiguardian, jsoup, xmvn, maven-assembly-plugin, junit5, apache-ivy, bsf, plexus-containers, apache-commons-compress, jdepend, xmlrpc, icu4j, json_simple, easymock, jvnet-parent, javacc-maven-plugin eclipse-sig: eclipse-m2e-plexus, maven-jar-plugin, maven-javadoc-plugin, junit, geronimo-parent-poms, eclipse-m2e-tycho, apache-commons-el, eclipse-m2e-mavenarchiver, eclipse-m2e-workspace, eclipse-m2e-sourcelookup, apache-commons-collections, maven-plugin-build-helper, apache-commons-collections4, maven-assembly-plugin, jdepend, ant-contrib, icu4j, javacc-maven-plugin, eclipse-m2e-egit, jetty8, objectweb-asm3, avalon-framework, apache-mime4j, atinject, xalan-j2, glassfish-jsp-api, tagsoup, apache-commons-csv, apiguardian, bsf, eclipse-m2e-antlr, eclipse-m2e-buildhelper, json_simple, easymock, velocity, osgi-core, apache-commons-jxpath, sisu, kxml, apache-commons-net, batik, jetty, bcel, apache-resource-bundles, opentest4j, eclipse-m2e-modello, beust-jcommander, glassfish-jsp, maven, xmvn, eclipse-m2e-sisu, eclipse-m2e-cxf, junit5, plexus-containers, apache-commons-compress, eclipse-m2e-mavendev, jvnet-parent, sisu-mojos, xz-java, apache-parent, eclipse-m2e-core, regexp, plexus-utils, maven-enforcer, args4j, jakarta-commons-httpclient, nekohtml, guava20, apache-commons-fileupload, google-gson, gradle, jsoup, apache-commons-discovery, apache-ivy, apache-commons-beanutils, xmlrpc, maven-plugin-bundle eclipseo: google-gson edewata: glassfish-fastinfoset, maven-jar-plugin, maven-javadoc-plugin, glassfish-jaxb, snakeyaml, avalon-framework, jackson, junit, apache-commons-net, apache-mime4j, jakarta-commons-httpclient, xalan-j2, gradle, antlr3, xmvn, google-guice, maven-assembly-plugin, apache-ivy, jettison, jvnet-parent, velocity, javacc-maven-plugin ehabkost: plexus-utils ellert: apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, apache-resource-bundles, maven-source-plugin, bsh, maven-surefire, maven-compiler-plugin, xmvn, avalon-framework, junit, maven-assembly-plugin emaldonado: apache-ivy epienbro: mingw-webkitgtk3, mingw-webkitgtk erack: bsh, apache-commons-net, bcel eseyman: apache-ivy, maven-jar-plugin, gradle, maven-javadoc-plugin, antlr3, xmvn fab: apache-ivy fabiand: apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, python-urwid, xmvn fcami: regexp, junit5, bsf, apache-ivy, apache-commons-net, bcel, gradle, jdepend, maven-jar-plugin, maven-javadoc-plugin, xz-java, xalan-j2, xmvn, avalon-framework, junit fche: plexus-utils, apache-ivy fedpop: google-gson filiperosset: apache-ivy, apache-commons-net, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn fnasser: apache-commons-jxpath, maven-jar-plugin, maven-javadoc-plugin, httpunit, objectweb-asm3, plexus-utils, apache-commons-net, apache-commons-el, nekohtml, plexus-classworlds, gradle, modello, apache-commons-configuration, xmvn, apache-commons-discovery, maven-wagon, plexus-containers, apache-ivy, hsqldb, apache-commons-beanutils, icu4j, easymock, log4j fpokorny: google-gson fsimonce: jackson, apache-ivy, jakarta-commons-httpclient fszymanski: python-urwid fujiwara: google-gson galileo: xz-java, maven-jar-plugin, maven-javadoc-plugin, sonatype-oss-parent, junit, maven-indexer, apache-commons-net, jetty, apache-resource-bundles, atinject, xalan-j2, guava20, apache-commons-collections, aether-connector-okhttp, google-gson, gradle, okio, xmvn, apache-commons-discovery, takari-filemanager, apache-ivy, apache-commons-compress, json_simple, eclipse-m2e-core, velocity, maven-source-plugin gchamoul: python-kafka, python-urwid gemi: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn geoff: junit5, bsf, apache-commons-net, xz-java, jdepend, bcel, ant-contrib, xalan-j2, regexp ggillies: bsf giallu: junit, apache-ivy, apache-commons-net, apache-commons-compress gil: maven-jar-plugin, maven-javadoc-plugin, glassfish-jaxb, avalon-logkit, junit, geronimo-parent-poms, stringtemplate4, jansi, apache-commons-collections, maven-plugin-build-helper, antlr3, apache-commons-collections4, geronimo-jms, maven-assembly-plugin, glassfish-dtd-parser, jdepend, ant-contrib, bsh, jettison, hawtjni, felix-bundlerepository, icu4j, log4j, jna, javacc-maven-plugin, glassfish-fastinfoset, sonatype-oss-parent, maven-osgi, jetty8, objectweb-asm3, avalon-framework, jackson, plexus-archiver, groovy, aqute-bnd, maven-surefire, apache-mime4j, atinject, xalan-j2, tagsoup, exec-maven-plugin, netty, apache-commons-csv, xstream, bsf, json_simple, easymock, velocity, osgi-core, plexus-compiler, httpunit, maven-shared-utils, sisu, snakeyaml, apache-commons-net, bcel, jetty, maven-antrun-plugin, apache-resource-bundles, maven-resolver, geronimo-jta, beust-jcommander, woodstox-core, apache-rat, maven, java-service-wrapper, xmvn, google-guice, c3p0, junit5, plexus-containers, apache-commons-compress, plexus-interpolation, bea-stax, maven-plugin-tools, jvnet-parent, jaxen, maven-source-plugin, maven-archiver, qdox, xz-java, apache-parent, stax2-api, maven-compiler-plugin, maven-gpg-plugin, httpcomponents-project, regexp, plexus-utils, maven-enforcer, jsr-311, args4j, jakarta-commons-httpclient, nekohtml, aopalliance, guava20, apache-commons-fileupload, gpars, google-gson, gradle, maven-dependency-plugin, apache-commons-configuration, maven-file-management, jsoup, apache-commons-discovery, maven-wagon, apache-ivy, codemodel, apache-commons-beanutils, xmlrpc, jetty-alpn-api, xbean, maven-plugin-bundle go-sig: google-gson goldmann: qdox, maven-jar-plugin, maven-javadoc-plugin, httpunit, apache-parent, sonatype-oss-parent, stax2-api, glassfish-jaxb, maven-compiler-plugin, httpcomponents-project, regexp, jackson, plexus-utils, junit, geronimo-parent-poms, apache-commons-net, aqute-bnd, bcel, jetty, maven-antrun-plugin, apache-resource-bundles, maven-enforcer, maven-surefire, apache-mime4j, atinject, jansi-native, jansi, jakarta-commons-httpclient, nekohtml, xalan-j2, aopalliance, geronimo-jta, guava20, apache-commons-fileupload, apache-commons-collections, beust-jcommander, exec-maven-plugin, woodstox-core, netty, gradle, apache-rat, maven-dependency-plugin, maven-plugin-build-helper, antlr3, maven, xmvn, xstream, apache-commons-collections4, geronimo-jms, c3p0, maven-assembly-plugin, apache-ivy, plexus-containers, jdepend, apache-commons-compress, ant-contrib, apache-commons-beanutils, bsh, jettison, jetty-alpn-api, hawtjni, icu4j, json_simple, velocity, easymock, jvnet-parent, maven-plugin-bundle, log4j, maven-source-plugin green: junit greghellings: checkstyle, ant-contrib, apache-commons-net grover: python-urwid guidograzioli: apache-ivy, apache-commons-net, maven-jar-plugin, plexus-containers, gradle, maven-invoker, apache-resource-bundles, maven-javadoc-plugin, bsh, maven, plexus-interpolation, plexus-interactivity, xmvn, plexus-utils, junit, jaxen gwei3: guava20, junit, aopalliance, maven-enforcer halfie: python-urwid hguemar: google-gson hhorak: maven-jar-plugin, maven-javadoc-plugin, glassfish-jaxb, httpcomponents-project, snakeyaml, jackson, geronimo-parent-poms, aqute-bnd, bcel, maven-antrun-plugin, jakarta-commons-httpclient, geronimo-jta, guava20, exec-maven-plugin, google-gson, netty, apache-commons-csv, gradle, apache-rat, antlr3, log4j, xmvn, xstream, apache-commons-discovery, google-guice, c3p0, maven-assembly-plugin, apache-ivy, ant-contrib, json_simple, easymock, jna hubbitus: apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, antlr3, xmvn huwang: apache-ivy, apache-commons-net, maven-jar-plugin, plexus-containers, gradle, maven-javadoc-plugin, apache-parent, atinject, maven, xmvn, avalon-framework, junit, maven-assembly-plugin idevat: bsf ignatenkobrain: google-gson, clang6.0, rust-futures-macro-async, guava20, easymock ignotusp: wicd ingvar: apache-ivy irina: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn itamarjp: google-gson ixs: apache-ivy jackorp: bsf jamielinux: apache-commons-net, maven jaruga: bsf java-sig: maven-jar-plugin, maven-javadoc-plugin, sonatype-oss-parent, apache-parent, maven-compiler-plugin, avalon-framework, junit, apache-commons-net, bcel, apache-resource-bundles, maven-surefire, apache-mime4j, aopalliance, apache-commons-collections, netty, gradle, apache-rat, xmvn, apache-commons-collections4, geronimo-jms, google-guice, apache-ivy, ant-contrib, apache-commons-beanutils, bsh jcapik: plexus-resources, xz-java, plexus-i18n, stax2-api, plexus-io, felix-utils, base64coder, plexus-digest, snakeyaml, avalon-framework, plexus-utils, felix-osgi-obr, plexus-archiver, junit, regexp, plexus-velocity, maven-enforcer, aqute-bnd, maven-plugin-testing, apache-commons-net, args4j, maven-jarsigner-plugin, maven-surefire, bcel, atinject, maven-invoker, xalan-j2, maven-shade-plugin, apache-commons-collections, beust-jcommander, woodstox-core, google-gson, maven, plexus-interactivity, jsoup, maven-wagon, maven-assembly-plugin, junit5, apache-ivy, bsf, maven-parent, jdepend, plexus-containers, bsh, plexus-interpolation, bea-stax, jflex, maven-plugin-tools, javacc, jaxen, maven-plugin-bundle, javacc-maven-plugin jchaloup: google-gson jdennis: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn jdornak: google-gson jeckersb: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn jerboaa: apache-commons-jxpath, xz-java, maven-jar-plugin, maven-javadoc-plugin, apache-parent, objectweb-asm3, avalon-framework, plexus-utils, avalon-logkit, junit, regexp, kxml, apache-commons-net, batik, bcel, jetty, args4j, apache-commons-el, apache-resource-bundles, opentest4j, apache-mime4j, atinject, jakarta-commons-httpclient, glassfish-jsp-api, nekohtml, xalan-j2, apache-commons-fileupload, beust-jcommander, exec-maven-plugin, tagsoup, google-gson, netty, apache-commons-csv, glassfish-jsp, gradle, maven, apiguardian, jsoup, apache-commons-collections4, xmvn, maven-assembly-plugin, osgi-core, junit5, apache-ivy, bsf, plexus-containers, apache-commons-compress, jdepend, ant-contrib, xmlrpc, icu4j, json_simple, easymock, jvnet-parent, maven-plugin-bundle, javacc-maven-plugin, maven-source-plugin jfilak: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn, junit jforbes: plexus-utils jgorig: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn jgrulich: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn jgu: apache-ivy jhernand: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, apache-commons-beanutils, xmvn jhrozek: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn jistone: plexus-utils, apache-ivy jjames: exec-maven-plugin, apache-ivy, maven-jar-plugin, sphinxtrain, cmusphinx3, gradle, maven-javadoc-plugin, antlr3, pl, xmvn, sphinxbase jjanco: glassfish-jaxb, maven-compiler-plugin, httpcomponents-project, snakeyaml, jackson, geronimo-parent-poms, bcel, maven-antrun-plugin, jakarta-commons-httpclient, geronimo-jta, guava20, exec-maven-plugin, netty, apache-commons-csv, apache-rat, antlr3, log4j, xstream, apache-commons-discovery, google-guice, c3p0, maven-assembly-plugin, ant-contrib, json_simple, easymock, jna jjelen: apache-ivy, maven-jar-plugin, apache-commons-compress, gradle, maven-javadoc-plugin, xmvn, avalon-framework, apache-commons-collections4 jjg: google-gson jjohnstn: apache-commons-jxpath, xz-java, maven-jar-plugin, maven-javadoc-plugin, objectweb-asm3, avalon-framework, plexus-utils, regexp, junit, kxml, apache-commons-net, batik, bcel, jetty, args4j, apache-commons-el, apache-resource-bundles, opentest4j, apache-mime4j, atinject, jakarta-commons-httpclient, glassfish-jsp-api, nekohtml, xalan-j2, guava20, apache-commons-fileupload, beust-jcommander, tagsoup, google-gson, apache-commons-csv, glassfish-jsp, gradle, maven, apiguardian, jsoup, apache-commons-collections4, xmvn, maven-assembly-plugin, osgi-core, junit5, apache-ivy, bsf, hsqldb, apache-commons-compress, jdepend, plexus-containers, xmlrpc, icu4j, json_simple, easymock, jvnet-parent, javacc-maven-plugin jkang: apache-resource-bundles, junit, kxml, maven-enforcer jkastner: apache-ivy, plexus-containers, maven-jar-plugin, gradle, maven-javadoc-plugin, plexus-compiler, maven, antlr3, xmvn jkucera: google-gson jmatthews: apache-commons-compress jmlich: apache-ivy, google-gson, apache-commons-net, bcel, gradle, maven-jar-plugin, maven-javadoc-plugin, xmvn john5342: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn jokajak: junit jonkni: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn jonny: beust-jcommander, geronimo-parent-poms, apache-ivy, maven-jar-plugin, bcel, gradle, maven-javadoc-plugin, xmvn, jna jorton: junit jouty: apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, keybinder, xmvn jplesnik: pl jpokorny: apache-ivy, apache-commons-net, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn jreznik: superkaramba jridky: google-gson jsafrane: apache-commons-net jskarvad: plexus-utils, apache-ivy, google-gson jstanek: google-gson jsteffan: jigdo jstribny: bsf jussilehtola: apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, ant-contrib, xmvn jvanek: beust-jcommander, apache-ivy, apache-commons-net, batik, maven-jar-plugin, gradle, maven-javadoc-plugin, ant-contrib, apache-resource-bundles, bsh, antlr3, hawtjni, maven, maven-file-management, maven-reporting-impl, xmvn, maven-reporting-api, plexus-utils jwrdegoede: apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, xmvn, jaxen kad: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn karm: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn, maven-source-plugin kasal: junit kashyapc: junit, python-urwid kdaniel: apache-commons-jxpath, xz-java, maven-jar-plugin, maven-javadoc-plugin, apache-parent, objectweb-asm3, avalon-framework, plexus-utils, regexp, junit, geronimo-parent-poms, kxml, apache-commons-net, batik, jetty, bcel, args4j, apache-commons-el, apache-resource-bundles, maven-antrun-plugin, atinject, xalan-j2, apache-mime4j, glassfish-jsp-api, jakarta-commons-httpclient, nekohtml, opentest4j, maven-reporting-api, guava20, apache-commons-fileupload, apache-commons-collections, beust-jcommander, tagsoup, google-gson, apache-commons-csv, glassfish-jsp, gradle, maven, maven-file-management, maven-enforcer, apiguardian, jsoup, apache-commons-collections4, xmvn, maven-assembly-plugin, osgi-core, junit5, apache-ivy, bsf, plexus-containers, apache-commons-compress, jdepend, ant-contrib, apache-commons-beanutils, bsh, easymock, xmlrpc, icu4j, maven-reporting-impl, json_simple, xbean, jvnet-parent, maven-plugin-bundle, javacc-maven-plugin, maven-source-plugin kde-sig: superkaramba, iris ke4qqq: jakarta-commons-httpclient, maven-compiler-plugin, maven-gpg-plugin, junit, xml-maven-plugin kevin: apache-ivy kiilerix: python-urwid kimheino: apache-ivy kkeithle: junit konradm: google-gson ktdreyer: junit kushal: apache-commons-net kwizart: apache-ivy, google-gson, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn kwright: apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, jakarta-commons-httpclient, xalan-j2, xmvn, avalon-framework, jvnet-parent, velocity, maven-assembly-plugin lbazan: apache-commons-net lberk: plexus-utils, junit, aopalliance, apache-ivy lcons: maven-source-plugin leamas: apache-ivy, apache-commons-net, maven-assembly-plugin lef: geronimo-jpa, maven-jar-plugin, maven-javadoc-plugin, glassfish-jaxb, checkstyle, junit, geronimo-parent-poms, stringtemplate4, apache-commons-el, jansi, apache-commons-collections, antlr3, apache-commons-collections4, geronimo-jms, maven-assembly-plugin, glassfish-dtd-parser, jdepend, ant-contrib, bsh, jettison, icu4j, hawtjni, log4j, javacc-maven-plugin, glassfish-fastinfoset, sonatype-oss-parent, objectweb-asm3, avalon-framework, jackson, maven-surefire, apache-mime4j, atinject, xalan-j2, glassfish-jsp-api, maven-reporting-api, exec-maven-plugin, tagsoup, netty, apache-commons-csv, apiguardian, xstream, bsf, json_simple, easymock, velocity, apache-commons-jxpath, plexus-compiler, httpunit, sisu, snakeyaml, kohsuke-pom, kxml, apache-commons-net, batik, apache-james-project, bcel, jetty, apache-resource-bundles, maven-antrun-plugin, opentest4j, maven-resolver, geronimo-jta, beust-jcommander, woodstox-core, glassfish-jsp, apache-rat, maven, java-service-wrapper, xmvn, google-guice, c3p0, junit5, plexus-containers, apache-commons-compress, plexus-interpolation, bea-stax, maven-reporting-impl, maven-plugin-tools, jvnet-parent, jaxen, maven-source-plugin, qdox, xz-java, apache-parent, stax2-api, maven-compiler-plugin, httpcomponents-project, regexp, plexus-utils, maven-enforcer, jsr-311, jakarta-commons-httpclient, nekohtml, aopalliance, guava20, apache-commons-fileupload, google-gson, gradle, maven-dependency-plugin, maven-file-management, jsoup, maven-wagon, apache-ivy, codemodel, apache-commons-beanutils, jetty-alpn-api, xmlrpc, xbean, maven-plugin-bundle lfarkas: apache-commons-net, jna lgao: qdox, glassfish-dtd-parser, apache-commons-net, codemodel, maven-antrun-plugin, maven-enforcer, apache-resource-bundles, maven-javadoc-plugin, maven-surefire, maven, avalon-framework, maven-source-plugin limb: apache-ivy, google-gson, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, xmvn linkdupont: google-gson lkundrak: apache-ivy, apache-commons-net, bsf, apache-commons-compress, gradle, maven-jar-plugin, apache-commons-beanutils, maven-javadoc-plugin, xmvn, plexus-utils, apache-commons-discovery lmacken: python-urwid lorenzodalrio: apache-ivy louizatakk: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn loveshack: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn lupinix: apache-ivy, apache-commons-net, maven-jar-plugin, apache-commons-compress, gradle, maven-javadoc-plugin, xmvn luya: clang6.0 lzap: rubygem-fakeweb marcindulak: apache-commons-net markmc: python-kafka martinkg: sonatype-oss-parent mathstuf: python-urwid maxamillion: google-gson, apache-commons-net, python-urwid mayorga: apache-commons-net mbaldessari: plexus-utils, python-urwid mbooth: apache-commons-jxpath, xz-java, maven-jar-plugin, maven-javadoc-plugin, plexus-compiler, sonatype-oss-parent, apache-parent, maven-plugin-bundle, objectweb-asm3, avalon-framework, regexp, snakeyaml, junit, geronimo-parent-poms, kxml, apache-commons-net, batik, bcel, jetty, args4j, apache-commons-el, apache-resource-bundles, opentest4j, apache-mime4j, atinject, jakarta-commons-httpclient, glassfish-jsp-api, nekohtml, maven-resolver, xalan-j2, apache-commons-fileupload, apache-commons-collections, beust-jcommander, exec-maven-plugin, tagsoup, google-gson, apache-commons-csv, glassfish-jsp, gradle, maven-plugin-build-helper, maven, apiguardian, jsoup, apache-commons-collections4, apache-commons-discovery, xmvn, maven-assembly-plugin, osgi-core, junit5, apache-ivy, bsf, plexus-containers, apache-commons-compress, jdepend, ant-contrib, apache-commons-beanutils, xmlrpc, icu4j, json_simple, easymock, jvnet-parent, eclipse-m2e-core, velocity, javacc-maven-plugin mdbooth: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn mef: pl, junit, maven-doxia melmorabity: sonatype-oss-parent, junit, apache-ivy, antlr3 mgieseki: apache-ivy, apache-commons-net, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn mgoodwin: junit, aopalliance mharmsen: apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, jakarta-commons-httpclient, xalan-j2, xmvn, avalon-framework, jvnet-parent, velocity, maven-assembly-plugin mhlavink: apache-ivy michalvala: apache-ivy mikep: sphinxbase, apache-commons-net mildew: google-gson milleruntime: qdox, maven-jar-plugin, maven-javadoc-plugin, apache-parent, jetty8, glassfish-jaxb, checkstyle, httpcomponents-project, avalon-framework, jackson, avalon-logkit, junit, geronimo-parent-poms, apache-commons-net, jetty, jsr-311, maven-antrun-plugin, apache-resource-bundles, atinject, jakarta-commons-httpclient, glassfish-jsp-api, aopalliance, geronimo-jta, guava20, apache-commons-collections, beust-jcommander, google-gson, netty, glassfish-jsp, gradle, apache-rat, istack-commons, apache-commons-configuration, maven, maven-file-management, xmvn, xstream, apache-commons-collections4, apache-commons-discovery, geronimo-jms, google-guice, c3p0, txw2, maven-assembly-plugin, apache-ivy, hsqldb, apache-commons-compress, apache-commons-beanutils, jettison, hawtjni, json_simple, velocity, easymock, jvnet-parent, log4j minh: wicd mizdebsk: geronimo-jpa, maven-archetype, eclipse-m2e-plexus, maven-artifact-resolver, maven-jar-plugin, maven-javadoc-plugin, plexus-i18n, maven-plugin-bundle, glassfish-jaxb, checkstyle, avalon-logkit, felix-osgi-obr, junit, geronimo-parent-poms, apache-logging-parent, eclipse-m2e-tycho, stringtemplate4, zinc, maven-jarsigner-plugin, apache-commons-el, jansi, takari-pom, eclipse-m2e-mavenarchiver, eclipse-m2e-workspace, jetty-build-support, eclipse-m2e-sourcelookup, apache-commons-collections, takari-lifecycle, aether-connector-okhttp, modello, maven-plugin-build-helper, multiverse, maven-repository-builder, antlr3, mnemonicsetter, apache-commons-collections4, geronimo-jms, takari-filemanager, xom, maven-assembly-plugin, maven-parent, glassfish-dtd-parser, jetty-test-helper, jdepend, ant-contrib, bsh, jettison, hawtjni, felix-bundlerepository, icu4j, maven-dependency-analyzer, maven-mapping, javacc, jna, javacc-maven-plugin, log4j, glassfish-fastinfoset, eclipse-m2e-egit, sonatype-oss-parent, joda-convert, maven-osgi, jetty8, plexus-digest, objectweb-asm3, avalon-framework, jackson, maven-script-interpreter, plexus-archiver, groovy, xml-maven-plugin, maven-toolchains-plugin, jetty-toolchain, plexus-component-factories-pom, takari-plugin-testing, aqute-bnd, maven-clean-plugin, jmapviewer, eclipse-m2e-takari, jetty-version-maven-plugin, maven-surefire, takari-archiver, apache-mime4j, atinject, geronimo-jaspic-spec, glassfish-jsp-api, xalan-j2, maven-reporting-api, maven-shade-plugin, maven-artifact-transfer, plexus-components-pom, exec-maven-plugin, tagsoup, maven-shared-io, netty, apache-commons-csv, univocity-parsers, okio, maven-idea-plugin, apiguardian, xstream, maven-shared-jarsigner, jetty-schemas, plexus-cli, bsf, hsqldb, SimplyHTML, maven-site-plugin, maven-stapler-plugin, eclipse-m2e-antlr, eclipse-m2e-buildhelper, plexus-bsh-factory, jflex, jortho, jetty-artifact-remote-resources, json_simple, easymock, velocity, osgi-core, os-maven-plugin, plexus-velocity, apache-commons-jxpath, plexus-compiler, takari-tycho-support, httpunit, osgi-compendium, plexus-io, felix-utils, maven-shared-utils, base64coder, maven-doxia-sitetools, jdependency, maven-reporting-exec, sisu, snakeyaml, maven-indexer, kohsuke-pom, jetty-assembly-descriptors, kxml, apache-commons-net, batik, apache-james-project, bcel, jetty, apache-resource-bundles, maven-antrun-plugin, opentest4j, xsom, jansi-native, eclipse-m2e-modello, maven-resolver, geronimo-jta, plexus-classworlds, maven-doxia, beust-jcommander, woodstox-core, glassfish-jsp, apache-rat, jetty-alpn, maven, plexus-interactivity, java-service-wrapper, eclipse-m2e-sisu, takari-incrementalbuild, xmvn, google-guice, c3p0, plexus-ant-factory, maven-shared-incremental, objectweb-pom, eclipse-m2e-cxf, junit5, maven-plugins-pom, plexus-containers, apache-commons-compress, eclipse-m2e-mavendev, plexus-interpolation, bea-stax, maven-reporting-impl, maven-plugin-tools, jaxen, jvnet-parent, sisu-mojos, maven-source-plugin, maven-archiver, qdox, plexus-resources, xz-java, apache-parent, stax2-api, jeromq, jetty-test-policy, maven-compiler-plugin, maven-gpg-plugin, httpcomponents-project, regexp, plexus-utils, jetty-distribution-remote-resources, eclipse-m2e-maven-dependency-plugin, cal10n, maven-enforcer, maven-plugin-testing, plexus-languages, jsr-311, args4j, jetty-parent, jsch-agent-proxy, maven-filtering, jakarta-commons-httpclient, maven-dependency-tree, maven-invoker, nekohtml, mojo-parent, aopalliance, guava20, apache-commons-fileupload, gpars, google-gson, maven-shared-jar, gradle, maven-dependency-plugin, istack-commons, apache-commons-configuration, maven-file-management, jsoup, apache-commons-discovery, dain-snappy, sonatype-plugins-parent, txw2, maven-wagon, apache-ivy, maven-verifier, codemodel, apache-commons-beanutils, jchardet, jetty-alpn-api, xmlrpc, apache-commons-jexl, decentxml, munge-maven-plugin, xbean, eclipse-m2e-core mjakubicek: apache-ivy, stringtemplate4, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, ant-contrib, antlr3, maven, xmvn mjg: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn mjw: plexus-utils, apache-ivy mkoncek: apache-commons-compress mlichvar: bcel mlombard: python-urwid mluscon: apache-commons-net mmahut: apache-ivy, apache-commons-net, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn mmorsi: bsf, apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, sonatype-oss-parent, xmvn, snakeyaml, junit, maven-source-plugin mmraka: apache-commons-beanutils, apache-resource-bundles, apache-parent, atinject, easymock, mchange-commons, apache-commons-fileupload, maven-plugin-bundle moceap: apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, maven-surefire, sonatype-oss-parent, bsh, apache-parent, maven-compiler-plugin, geronimo-jta, xmvn, junit, synaptic mohammedisam: apache-ivy mpaladin: maven-source-plugin mreynolds: apache-commons-net mrunge: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn mschorm: ant-contrib, google-gson, jna, apache-commons-csv msimacek: beust-jcommander, regexp, plexus-containers, maven-jar-plugin, apache-commons-compress, jetty, apache-parent, bsh, icu4j, nekohtml, junit, xstream, avalon-framework, plexus-utils, easymock, maven-plugin-bundle, maven-assembly-plugin mskalick: apache-ivy, netty, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn msrb: maven-archiver, xz-java, maven-jar-plugin, maven-javadoc-plugin, apache-parent, stax2-api, jetty8, glassfish-jaxb, maven-compiler-plugin, objectweb-asm3, avalon-framework, plexus-utils, regexp, junit, groovy, kohsuke-pom, geronimo-parent-poms, apache-commons-net, aqute-bnd, bcel, maven-antrun-plugin, args4j, maven-surefire, atinject, jakarta-commons-httpclient, xalan-j2, jansi, aopalliance, geronimo-jta, guava20, apache-commons-fileupload, apache-commons-collections, woodstox-core, jvnet-parent, gradle, apache-rat, maven, xmvn, xstream, apache-commons-discovery, google-guice, c3p0, txw2, maven-assembly-plugin, junit5, apache-ivy, bsf, codemodel, apache-commons-compress, jdepend, maven-stapler-plugin, apache-commons-beanutils, bsh, bea-stax, jaxen, jna mstevens: google-gson mtasaka: junit, apache-ivy mycae: apache-commons-net nathans: junit, aopalliance ndim: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn ndipanov: python-kafka neugens: apache-ivy, maven-jar-plugin, gradle, maven-javadoc-plugin, apache-resource-bundles, xmvn, junit neuro-sig: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn ngompa: junit, python-urwid nguzman: beust-jcommander, tagsoup, plexus-containers, google-gson, xz-java, apache-commons-csv, jetty, apache-resource-bundles, apache-mime4j, jakarta-commons-httpclient, xmlrpc, icu4j, nekohtml, json_simple, jsoup, regexp, apache-commons-collections4 nhosoi: apache-commons-net nkinder: apache-commons-net nmarques: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn noa: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn nodejs-sig: apache-commons-net nsantos: checkstyle oget: maven-antrun-plugin ohaessler: keybinder okeeble: google-gson oliver: apache-commons-jxpath, xz-java, maven-jar-plugin, maven-javadoc-plugin, objectweb-asm3, avalon-framework, regexp, junit, kxml, apache-commons-net, batik, bcel, jetty, apache-commons-el, apache-resource-bundles, opentest4j, apache-mime4j, atinject, xalan-j2, glassfish-jsp-api, nekohtml, apache-commons-fileupload, beust-jcommander, tagsoup, apache-commons-csv, glassfish-jsp, gradle, apiguardian, jsoup, xmvn, maven-assembly-plugin, junit5, apache-ivy, bsf, plexus-containers, apache-commons-compress, jdepend, xmlrpc, icu4j, json_simple, easymock, jvnet-parent, javacc-maven-plugin olysonek: plexus-utils, apache-ivy omajid: apache-ivy, apache-commons-net, maven-jar-plugin, netty, gradle, maven-javadoc-plugin, apache-resource-bundles, xmvn omular: bsf openstack-sig: python-kafka orion: apache-ivy, apache-commons-net, google-gson, apache-commons-csv, gradle, maven-jar-plugin, ant-contrib, maven-javadoc-plugin, jchardet, xmvn pahuang: apache-rat, eclipse-m2e-workspace pali: apache-ivy, apache-commons-net, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn patches: apache-commons-net, apache-commons-compress pbrobinson: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn pcpa: pl, apache-commons-jexl, apache-ivy peter: apache-ivy, google-gson, maven-jar-plugin, gradle, maven-javadoc-plugin, xmvn, guava20, easymock pfor: mingw-webkitgtk3, mingw-webkitgtk pingou: maven-shade-plugin, keybinder, maven pkajaba: apache-ivy, google-gson, apache-commons-net, bcel, gradle, maven-jar-plugin, maven-javadoc-plugin, xmvn pkfed: apache-ivy pknirsch: plexus-utils pkubat: apache-commons-net pmackinn: apache-commons-net, apache-commons-compress, maven-clean-plugin, jetty8, antlr3, geronimo-jta, json_simple, apache-commons-discovery, junit, apache-commons-collections pmikova: apache-ivy pmuldoon: junit ppisar: pl praiskup: junit5, apache-ivy, apache-commons-net, bsf, bcel, gradle, maven-jar-plugin, maven-javadoc-plugin, xz-java, xalan-j2, maven-compiler-plugin, xmvn, regexp ptoscano: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn puiterwijk: python-urwid pvalena: bsf python-sig: google-gson quintela: plexus-utils radekmanak: apache-ivy raphgro: apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, apache-resource-bundles, sonatype-oss-parent, keybinder, xmvn, regexp, junit rathann: apache-ivy, apache-commons-net, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn rcritten: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn rdieter: apache-ivy, libkexif, superkaramba, pl, sphinxbase, iris rebus: apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, xmvn, jna ret2libc: jna rfenkhuber: apache-ivy, apache-commons-net, maven-jar-plugin, jetty, gradle, maven-javadoc-plugin, apache-resource-bundles, apache-commons-configuration, maven-compiler-plugin, xmvn, easymock, maven-plugin-bundle, log4j rgrunber: apache-commons-jxpath, xz-java, maven-jar-plugin, maven-javadoc-plugin, apache-parent, objectweb-asm3, avalon-framework, plexus-utils, regexp, junit, geronimo-parent-poms, kxml, apache-commons-net, batik, bcel, jetty, args4j, apache-commons-el, apache-resource-bundles, maven-enforcer, apache-mime4j, atinject, jakarta-commons-httpclient, glassfish-jsp-api, nekohtml, opentest4j, xalan-j2, guava20, apache-commons-fileupload, beust-jcommander, tagsoup, google-gson, apache-commons-csv, glassfish-jsp, gradle, maven, apiguardian, jsoup, apache-commons-collections4, xmvn, maven-assembly-plugin, osgi-core, junit5, apache-ivy, bsf, plexus-containers, apache-commons-compress, jdepend, ant-contrib, xmlrpc, icu4j, json_simple, easymock, jvnet-parent, maven-plugin-bundle, javacc-maven-plugin ricardo: maven-jar-plugin, maven-javadoc-plugin, apache-parent, jackson, junit, apache-commons-net, maven-enforcer, jetty, gradle, antlr3, maven, maven-file-management, xmvn, apache-ivy, apache-commons-compress, bsh, maven-plugin-bundle, velocity, maven-source-plugin richardfearn: junit5, apache-ivy, apache-commons-net, bsf, bcel, jdepend, maven-antrun-plugin, apache-resource-bundles, xz-java, xalan-j2, jaxen, regexp, junit, apache-commons-collections, log4j, maven-assembly-plugin rjones: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn, plexus-utils rkennke: apache-ivy, maven-jar-plugin, gradle, maven-javadoc-plugin, apache-resource-bundles, xmvn, junit rlandmann: apache-resource-bundles, apache-commons-net rmarko: apache-ivy rmattes: apache-ivy, google-gson, maven-jar-plugin, gradle, maven-javadoc-plugin, python-genpy, rospack, pl, python-genmsg, python-gencpp, catkin, xmvn, python-genlisp, ros-release rmeggins: apache-commons-net rmyers: xz-java, checkstyle, regexp, junit, jetty, apache-resource-bundles, apache-mime4j, jakarta-commons-httpclient, nekohtml, beust-jcommander, tagsoup, google-gson, apache-commons-csv, jsoup, apache-commons-collections4, plexus-containers, apache-commons-beanutils, xmlrpc, icu4j, json_simple robotics-sig: google-gson, python-genpy, rospack, python-genmsg, python-gencpp, catkin, python-genlisp, ros-release ruben: apache-ivy, google-gson ruby-packagers-sig: bsf russellb: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn, apache-commons-discovery rust-sig: rust-futures-macro-async s4504kr: apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, xmvn, jaxen sagitter: apache-ivy, google-gson, maven-jar-plugin, gradle, maven-javadoc-plugin, apache-commons-jexl, xmvn salimma: google-gson, apache-ivy, apache-commons-net sasiddiq: maven-enforcer sbergmann: bsh, apache-commons-net, bcel sbonazzo: bsh, bsf, apache-commons-net, sonatype-oss-parent scottt: apache-commons-net scox: plexus-utils, apache-ivy sdgathman: plexus-containers, maven-antrun-plugin, plexus-compiler, apache-resource-bundles, antlr3, maven, avalon-framework, junit, jaxen, maven-plugin-bundle sdyroff: python-urwid sdz: apache-ivy, apache-commons-net, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn seanf: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn, junit sergiomb: google-gson simo: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn simonm: google-gson skitt: easymock skottler: apache-ivy, apache-commons-net, maven-jar-plugin, gradle, maven-javadoc-plugin, xmvn, geronimo-jms slaanesh: apache-ivy, apache-commons-net, clang6.0, maven-jar-plugin, gradle, maven-javadoc-plugin, maven, xmvn, easymock slankes: iris smakarov: plexus-utils, apache-ivy smani: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn, junit sopotc: apache-commons-collections4, maven-enforcer spike: apache-commons-jxpath, maven-jar-plugin, maven-javadoc-plugin, joda-convert, apache-parent, avalon-framework, junit, geronimo-parent-poms, apache-commons-net, apache-commons-el, apache-resource-bundles, maven-surefire, geronimo-jta, apache-commons-fileupload, apache-commons-collections, exec-maven-plugin, apache-commons-csv, gradle, apache-commons-configuration, xmvn, apache-commons-discovery, apache-ivy, apache-commons-compress, apache-commons-beanutils, bsh, easymock spot: google-gson, maven steve: junit stevetraylen: bsf, json_simple, maven-source-plugin stingray: junit susmit: gnumed swagiaal: junit tagoh: google-gson tc01: apache-commons-collections tdawson: apache-ivy, google-gson, apache-commons-net, bsf, gradle, maven-jar-plugin, maven-javadoc-plugin, xmvn, geronimo-jms terjeros: apache-commons-net, python-urwid than: superkaramba thofmann: python-genpy, rospack, pl, python-genmsg, python-gencpp, catkin, python-genlisp, ros-release thozza: apache-commons-compress till: apache-ivy timn: ros-release, rospack tjikkun: google-gson tojeline: bsf tomh: apache-commons-net tremble: pl trepik: maven-jar-plugin, maven-javadoc-plugin, sonatype-oss-parent, glassfish-jaxb, httpcomponents-project, snakeyaml, jackson, junit, geronimo-parent-poms, aqute-bnd, bcel, maven-antrun-plugin, jakarta-commons-httpclient, geronimo-jta, guava20, exec-maven-plugin, netty, apache-commons-csv, gradle, apache-rat, antlr3, log4j, xmvn, xstream, apache-commons-discovery, google-guice, c3p0, maven-assembly-plugin, apache-ivy, json_simple, easymock, jna tstclair: apache-commons-net, jsr-311, apache-parent, jackson, guava20 tstellar: clang5.0, clang6.0 ttomecek: python-urwid twaugh: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn vakwetu: glassfish-fastinfoset, maven-jar-plugin, maven-javadoc-plugin, glassfish-jaxb, avalon-framework, jackson, snakeyaml, junit, apache-commons-net, apache-mime4j, jakarta-commons-httpclient, xalan-j2, gradle, antlr3, xmvn, google-guice, maven-assembly-plugin, apache-ivy, jettison, jvnet-parent, maven-plugin-bundle, velocity, javacc-maven-plugin valtri: bsf, apache-commons-net van: apache-ivy, maven-jar-plugin, gradle, maven-javadoc-plugin, xmvn, apache-commons-collections vbatts: google-gson vcrhonek: apache-ivy, apache-commons-net, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn veillard: apache-ivy, apache-commons-net, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn verdurin: apache-commons-net virtmaint-sig: plexus-utils vjancik: sphinxbase, google-gson vladimirk: apache-commons-csv volter: apache-ivy, apache-commons-net, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn vondruch: rubygem-fog-aws, junit, bsf vtrefny: apache-commons-net wakko666: bsf walters: apache-commons-net, maven, antlr3 wcohen: plexus-utils, apache-ivy weli: apache-ivy, aqute-bnd, maven-jar-plugin, gradle, maven-javadoc-plugin, apache-resource-bundles, bsh, maven, xmvn willb: junit5, apache-ivy, apache-commons-net, aqute-bnd, bcel, bsf, gradle, ant-contrib, jdepend, maven-jar-plugin, maven-javadoc-plugin, sonatype-oss-parent, xalan-j2, xz-java, xmvn, regexp, maven-plugin-bundle williamjmorenor: hamster-time-tracker wilqu: apache-ivy, apache-commons-net, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn xaeth: apache-ivy xavierb: apache-ivy, apache-commons-net, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn yyang: maven-parent, plexus-containers, apache-commons-net, maven-plugin-testing, apache-ivy, gradle, maven-jar-plugin, maven-javadoc-plugin, modello, maven, plexus-interpolation, maven-plugin-tools, xmvn, plexus-utils, junit, plexus-components-pom, maven-wagon, maven-assembly-plugin zaneb: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn, apache-commons-discovery zbyszek: apache-ivy, apache-commons-net, maven-jar-plugin, apache-commons-compress, gradle, maven-javadoc-plugin, antlr3, xmvn zzambers: ant-contrib, apache-ivy
Is there already a way to package the java application as a module or we will really remove all these package from Fedora?
I am really not interested in maintaining a whole java frameworks stack, but some guidance (not these weekly emails) from java maintainers team that took this decision would be appreciated.
Regards, Jakub
On Tue, 2019-03-12 at 11:38 +0100, Miro Hrončok wrote:
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired.
Grep the list for your FAS name, follow the transitive deps: https://churchyard.fedorapeople.org/orphans-2019-03-11.txt
Request package ownership via releng ticket: https://pagure.io/releng/issues
...
On 12. 03. 19 11:48, Jakub Jelen wrote:
Is there already a way to package the java application as a module or we will really remove all these package from Fedora?
You can build Java apps as modules, yes. If we remove the mentioned packages from rawhide, it will be the only way to build Java packages. No, there is not yet supported way to build "normal" packages with modular buildrequires. Yes, I'm really going to retire those packages on rawhide if nobody picks them or if we don't agree on an exception (such as, wait X extra weeks before the problem is solved).
I am really not interested in maintaining a whole java frameworks stack, but some guidance (not these weekly emails) from java maintainers team that took this decision would be appreciated.
I'd appreciate it as well.
On Tue, 12 Mar 2019 at 06:53, Miro Hrončok wrote:
You can build Java apps as modules, yes. If we remove the mentioned packages from rawhide, it will be the only way to build Java packages.
How are the Java applications that come with C (JNI) extensions handled in the modules model? How do they get the mass rebuilds due to compiler/build flags/C library updates etc?
Thank you, Orcan
On Tue, Mar 12, 2019 at 11:49 AM Jakub Jelen jjelen@redhat.com wrote:
Is there already a way to package the java application as a module or we will really remove all these package from Fedora?
Most of Java packages listed in this thread are already packaged as modules. Their retirement in rawhide won't directly cause their removal from distribution.
I am really not interested in maintaining a whole java frameworks stack, but some guidance (not these weekly emails) from java maintainers team that took this decision would be appreciated.
Can you elaborate on what kind of guidance do you expect?
There is no "Java maintainers team" in Fedora. Java packages are maintained by individual packagers. Theoretically there exists a Java SIG, but its activity is limited to a couple of emails per year, with significant part of them talking about orphaning or retiring packages.
-- Mikolaj Izdebski
On Tuesday, 12 March 2019 at 12:02, Mikolaj Izdebski wrote:
On Tue, Mar 12, 2019 at 11:49 AM Jakub Jelen jjelen@redhat.com wrote:
Is there already a way to package the java application as a module or we will really remove all these package from Fedora?
Most of Java packages listed in this thread are already packaged as modules. Their retirement in rawhide won't directly cause their removal from distribution.
Maybe, but it will cause the removal of other packages that depend on their regular (non-modular) builds. You are forcing the hands of their maintainers before the infrastructure to make modular packages available as build dependencies to regular packages is in place to remake their packages into modules, let them be retired or pick up your orphans. If it were ready, your moving these packages to modules would be a non-event for everyone concerned except you. Instead of helping with that (or just waiting), you are about to cause the retirement of quite a few packages whose maintainers want nothing to do with Modularity. That's not excellent.
Regards, Dominik
On Tue, Mar 12, 2019 at 1:17 PM Dominik 'Rathann' Mierzejewski < dominik@greysector.net> wrote:
On Tuesday, 12 March 2019 at 12:02, Mikolaj Izdebski wrote:
On Tue, Mar 12, 2019 at 11:49 AM Jakub Jelen jjelen@redhat.com wrote:
Is there already a way to package the java application as a module or we will really remove all these package from Fedora?
Most of Java packages listed in this thread are already packaged as modules. Their retirement in rawhide won't directly cause their removal from distribution.
Maybe, but it will cause the removal of other packages that depend on their regular (non-modular) builds. You are forcing the hands of their maintainers before the infrastructure to make modular packages available as build dependencies to regular packages is in place to remake their packages into modules, let them be retired or pick up your orphans. If it were ready, your moving these packages to modules would be a non-event for everyone concerned except you. Instead of helping with that (or just waiting), you are about to cause the retirement of quite a few packages whose maintainers want nothing to do with Modularity. That's not excellent.
Dominik, that is totally ugly reply to Mikolaj! Whole Java RPM community (note not only Fedora but Mageia and etc. too) relied on his work to keep hundreds (or maybe even thousands) of packages rpm installable. And he has done that for years without ever complaining! Even more he is one of the most helpful maintainers whenever someone faces an issue. Respect should be shown when deserved, blaming like that causes nothing but ill feelings. Everyone should remember that this is *COMMUNITY* project and if/when someone needs something they should be ready to jump in and do the work - whether taking packages or helping infra guys or whatever but no one owes others anything.
P.S. As Eclipse stack maintainers we are directly hit by this and already working towards turning it into module as we don't have the manpower to take over the maintainership of pristine rpms that Mikolaj maintains. Whoever things that's easy job is welcome to try it out!
Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Tue, Mar 12, 2019 at 7:29 AM Aleksandar Kurtakov akurtako@redhat.com wrote:
On Tue, Mar 12, 2019 at 1:17 PM Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Tuesday, 12 March 2019 at 12:02, Mikolaj Izdebski wrote:
On Tue, Mar 12, 2019 at 11:49 AM Jakub Jelen jjelen@redhat.com wrote:
Is there already a way to package the java application as a module or we will really remove all these package from Fedora?
Most of Java packages listed in this thread are already packaged as modules. Their retirement in rawhide won't directly cause their removal from distribution.
Maybe, but it will cause the removal of other packages that depend on their regular (non-modular) builds. You are forcing the hands of their maintainers before the infrastructure to make modular packages available as build dependencies to regular packages is in place to remake their packages into modules, let them be retired or pick up your orphans. If it were ready, your moving these packages to modules would be a non-event for everyone concerned except you. Instead of helping with that (or just waiting), you are about to cause the retirement of quite a few packages whose maintainers want nothing to do with Modularity. That's not excellent.
Dominik, that is totally ugly reply to Mikolaj! Whole Java RPM community (note not only Fedora but Mageia and etc. too) relied on his work to keep hundreds (or maybe even thousands) of packages rpm installable. And he has done that for years without ever complaining! Even more he is one of the most helpful maintainers whenever someone faces an issue. Respect should be shown when deserved, blaming like that causes nothing but ill feelings. Everyone should remember that this is *COMMUNITY* project and if/when someone needs something they should be ready to jump in and do the work - whether taking packages or helping infra guys or whatever but no one owes others anything.
P.S. As Eclipse stack maintainers we are directly hit by this and already working towards turning it into module as we don't have the manpower to take over the maintainership of pristine rpms that Mikolaj maintains. Whoever things that's easy job is welcome to try it out!
This whole process was handled in the worst possible way. To sum up: * No one knew Java SIG was having manpower issues because Mikolaj didn't know how to ask for help * Now it's too late because he orphaned nearly 1700 packages to force modularization * This caused everyone dependent on those packages to freak * And here we are in the bad ending...
We could have avoided the bad ending if at any point there was an official call for help to increase Java SIG manpower. There wasn't. We could have avoided this if there was a discussion before the orphaning. There wasn't.
We could have avoided the bad ending if people dependent on Java packages were given the opportunity to help. As you say, this is a community distro. That goes both ways. But that didn't happen.
So here we are, in the bad ending.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Tue, Mar 12, 2019 at 1:36 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Mar 12, 2019 at 7:29 AM Aleksandar Kurtakov akurtako@redhat.com wrote:
On Tue, Mar 12, 2019 at 1:17 PM Dominik 'Rathann' Mierzejewski <
dominik@greysector.net> wrote:
On Tuesday, 12 March 2019 at 12:02, Mikolaj Izdebski wrote:
On Tue, Mar 12, 2019 at 11:49 AM Jakub Jelen jjelen@redhat.com
wrote:
Is there already a way to package the java application as a module
or
we will really remove all these package from Fedora?
Most of Java packages listed in this thread are already packaged as modules. Their retirement in rawhide won't directly cause their removal from distribution.
Maybe, but it will cause the removal of other packages that depend on their regular (non-modular) builds. You are forcing the hands of their maintainers before the infrastructure to make modular packages available as build dependencies to regular packages is in place to remake their packages into modules, let them be retired or pick up your orphans. If it were ready, your moving these packages to modules would be a non-event for everyone concerned except you. Instead of helping with that (or just waiting), you are about to cause the retirement of quite a few packages whose maintainers want nothing to do with Modularity. That's not excellent.
Dominik, that is totally ugly reply to Mikolaj! Whole Java RPM community
(note not only Fedora but Mageia and etc. too) relied on his work to keep hundreds (or maybe even thousands) of packages rpm installable. And he has done that for years without ever complaining! Even more he is one of the most helpful maintainers whenever someone faces an issue. Respect should be shown when deserved, blaming like that causes nothing but ill feelings.
Everyone should remember that this is *COMMUNITY* project and if/when
someone needs something they should be ready to jump in and do the work - whether taking packages or helping infra guys or whatever but no one owes others anything.
P.S. As Eclipse stack maintainers we are directly hit by this and
already working towards turning it into module as we don't have the manpower to take over the maintainership of pristine rpms that Mikolaj maintains. Whoever things that's easy job is welcome to try it out!
This whole process was handled in the worst possible way. To sum up:
- No one knew Java SIG was having manpower issues because Mikolaj
didn't know how to ask for help
- Now it's too late because he orphaned nearly 1700 packages to force
modularization
- This caused everyone dependent on those packages to freak
- And here we are in the bad ending...
We could have avoided the bad ending if at any point there was an official call for help to increase Java SIG manpower. There wasn't. We could have avoided this if there was a discussion before the orphaning. There wasn't.
We could have avoided the bad ending if people dependent on Java packages were given the opportunity to help. As you say, this is a community distro. That goes both ways. But that didn't happen.
Hmm, https://lists.fedoraproject.org/archives/list/java-devel@lists.fedoraproject... seems that people had a lot of time to act and get involved.
So here we are, in the bad ending.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Tue, 2019-03-12 at 13:43 +0200, Aleksandar Kurtakov wrote:
On Tue, Mar 12, 2019 at 1:36 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Mar 12, 2019 at 7:29 AM Aleksandar Kurtakov < akurtako@redhat.com> wrote:
On Tue, Mar 12, 2019 at 1:17 PM Dominik 'Rathann' Mierzejewski <
dominik@greysector.net> wrote:
On Tuesday, 12 March 2019 at 12:02, Mikolaj Izdebski wrote:
On Tue, Mar 12, 2019 at 11:49 AM Jakub Jelen < jjelen@redhat.com>
wrote:
Is there already a way to package the java application as a module
or
we will really remove all these package from Fedora?
Most of Java packages listed in this thread are already packaged as modules. Their retirement in rawhide won't directly cause their removal from distribution.
Maybe, but it will cause the removal of other packages that depend on their regular (non-modular) builds. You are forcing the hands of their maintainers before the infrastructure to make modular packages available as build dependencies to regular packages is in place to remake their packages into modules, let them be retired or pick up your orphans. If it were ready, your moving these packages to modules would be a non-event for everyone concerned except you. Instead of helping with that (or just waiting), you are about to cause the retirement of quite a few packages whose maintainers want nothing to do with Modularity. That's not excellent.
Dominik, that is totally ugly reply to Mikolaj! Whole Java RPM community
(note not only Fedora but Mageia and etc. too) relied on his work to keep hundreds (or maybe even thousands) of packages rpm installable. And he has done that for years without ever complaining! Even more he is one of the most helpful maintainers whenever someone faces an issue. Respect should be shown when deserved, blaming like that causes nothing but ill feelings.
Everyone should remember that this is *COMMUNITY* project and if/when
someone needs something they should be ready to jump in and do the work - whether taking packages or helping infra guys or whatever but no one owes others anything.
P.S. As Eclipse stack maintainers we are directly hit by this and
already working towards turning it into module as we don't have the manpower to take over the maintainership of pristine rpms that Mikolaj maintains. Whoever things that's easy job is welcome to try it out!
This whole process was handled in the worst possible way. To sum up:
- No one knew Java SIG was having manpower issues because Mikolaj
didn't know how to ask for help
- Now it's too late because he orphaned nearly 1700 packages to
force modularization
- This caused everyone dependent on those packages to freak
- And here we are in the bad ending...
We could have avoided the bad ending if at any point there was an official call for help to increase Java SIG manpower. There wasn't. We could have avoided this if there was a discussion before the orphaning. There wasn't.
We could have avoided the bad ending if people dependent on Java packages were given the opportunity to help. As you say, this is a community distro. That goes both ways. But that didn't happen.
Hmm, https://lists.fedoraproject.org/archives/list/java-devel@lists.fedoraproject... seems that people had a lot of time to act and get involved.
Unfortunately not everyone who happens to maintain a java package is in the java SIG and reading the mails there so I think this mail should have been sent at least to fedora-devel too, maybe even announce since it is touching so many packages (dependencies).
I used to have one java package inherited from inactive maintainer then one more and now comes third. I have them because I want to be able to use and update my application in Fedora. I really do not care if they will be built in Fedora or Arbitrary branching.
I see that Mikolaj already did a lot of work of moving his packages to the modules, so a mail with simple instructions "this is a list of things that I did for my packages and if you depend on them, do it also", would save many maintainers as me hours of searching the sparse modularity documentation.
If there are no such steps, I will jump for the packages that I need, but if the Java in Fedora future should be modular, lets do that. But remember: We do not know how.
Regards,
On Tue, Mar 12, 2019 at 3:11 PM Jakub Jelen jjelen@redhat.com wrote:
On Tue, 2019-03-12 at 13:43 +0200, Aleksandar Kurtakov wrote:
Hmm, https://lists.fedoraproject.org/archives/list/java-devel@lists.fedoraproject... seems that people had a lot of time to act and get involved.
Unfortunately not everyone who happens to maintain a java package is in the java SIG and reading the mails there so I think this mail should have been sent at least to fedora-devel too, maybe even announce since it is touching so many packages (dependencies).
I did send an announcement to devel list several months before to orphaning packages. The above message from java-devel was linked on devel list. See: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
I see that Mikolaj already did a lot of work of moving his packages to the modules, so a mail with simple instructions "this is a list of things that I did for my packages and if you depend on them, do it also", would save many maintainers as me hours of searching the sparse modularity documentation.
The approach I used to build my modules should be described in "MBI (playground 2.0)" on this list. I don't want to spend too much time on describing the process in very detail - I am actively working on an improved process that will require less resources.
-- Mikolaj Izdebski
On Tue, 2019-03-12 at 21:24 +0100, Mikolaj Izdebski wrote:
On Tue, Mar 12, 2019 at 3:11 PM Jakub Jelen jjelen@redhat.com wrote:
On Tue, 2019-03-12 at 13:43 +0200, Aleksandar Kurtakov wrote:
Hmm, https://lists.fedoraproject.org/archives/list/java-devel@lists.fedoraproject... seems that people had a lot of time to act and get involved.
Unfortunately not everyone who happens to maintain a java package is in the java SIG and reading the mails there so I think this mail should have been sent at least to fedora-devel too, maybe even announce since it is touching so many packages (dependencies).
I did send an announcement to devel list several months before to orphaning packages. The above message from java-devel was linked on devel list. See: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
Thank you for pointing to the thread. Really, but saying "some" is not what was is happening now. If it would say "most of", I could have stopped to read it half a year ago.
I see that Mikolaj already did a lot of work of moving his packages to the modules, so a mail with simple instructions "this is a list of things that I did for my packages and if you depend on them, do it also", would save many maintainers as me hours of searching the sparse modularity documentation.
The approach I used to build my modules should be described in "MBI (playground 2.0)" on this list. I don't want to spend too much time on describing the process in very detail - I am actively working on an improved process that will require less resources.
This is very appreciated. I read through that email thread and the document, but I was not really more clever from that.
Just out of curiosity I started reading through the list of packaged that I would have to take to build my package and that is more than I am really able to handle. And especially when you are working on better way to package it in modules, it feels like waste of resources and time.
I would appreciate if there would be a way to build normal packages against modules (somehow?), but if using modules has only advantages, I would be very interested to do that too with my Java package. But as already said by more people around, we really do not know how and we do not have so much spare time to figure all of the details.
Regards,
On Tue, Mar 12, 2019 at 12:36 PM Neal Gompa ngompa13@gmail.com wrote:
This whole process was handled in the worst possible way. To sum up:
- No one knew Java SIG was having manpower issues because Mikolaj
didn't know how to ask for help
You did not know that, but the situation in Java SIG is well known to Java SIG members. Statistics speak for themselves.
For example, the packager who owns the most of Java packages (point of contacts for 480 Java packages) made his last commit in February 2017. The second maintainer (PoC for 94 Java packages) had last commit in 2015. The fourth (PoC of 55 packages) - last commit in March 2017. And so on.
Situation on mailing list is not much better. Less than 20 mail threads in each of years 2018 and 2017. Compare with more than 150 threads in year 2013.
The last Java SIG IRC meeting took place in February 2013.
- Now it's too late because he orphaned nearly 1700 packages to force
modularization
I did not orphan that many packages. I orphaned about 250 packages only.
It is not too late for anything. Orphaned packages can still be adopted. That's the whole point of this thread.
We could have avoided the bad ending if at any point there was an official call for help to increase Java SIG manpower. There wasn't. We could have avoided this if there was a discussion before the orphaning. There wasn't.
We don't have any official process for calling for help. Other distros (at least Debian) have it, but not Fedora.
Discussion requires more than one participating party. I started a thread on java-devel list where I explained the situation and my plans in detail. There was no reply on the list, not a single message. I only had one or two private conversations about this problem.
We could have avoided the bad ending if people dependent on Java packages were given the opportunity to help. As you say, this is a community distro. That goes both ways. But that didn't happen.
IMHO I've been very patient. I've given the community a lot of opportunity to help. I never refused any help. I was and I am still working with new contributors that want to become packagers.
-- Mikolaj
On Tue, Mar 12, 2019 at 8:35 AM Mikolaj Izdebski mizdebsk@redhat.com wrote:
On Tue, Mar 12, 2019 at 12:36 PM Neal Gompa ngompa13@gmail.com wrote:
This whole process was handled in the worst possible way. To sum up:
- No one knew Java SIG was having manpower issues because Mikolaj
didn't know how to ask for help
You did not know that, but the situation in Java SIG is well known to Java SIG members. Statistics speak for themselves.
I'm not a Java SIG member, so how would I know?
For example, the packager who owns the most of Java packages (point of contacts for 480 Java packages) made his last commit in February 2017. The second maintainer (PoC for 94 Java packages) had last commit in 2015. The fourth (PoC of 55 packages) - last commit in March 2017. And so on.
Situation on mailing list is not much better. Less than 20 mail threads in each of years 2018 and 2017. Compare with more than 150 threads in year 2013.
The last Java SIG IRC meeting took place in February 2013.
- Now it's too late because he orphaned nearly 1700 packages to force
modularization
I did not orphan that many packages. I orphaned about 250 packages only.
Sorry, you're right, it affects nearly that many though.
It is not too late for anything. Orphaned packages can still be adopted. That's the whole point of this thread.
We could have avoided the bad ending if at any point there was an official call for help to increase Java SIG manpower. There wasn't. We could have avoided this if there was a discussion before the orphaning. There wasn't.
We don't have any official process for calling for help. Other distros (at least Debian) have it, but not Fedora.
The reason Debian has one is because people generally don't know how to work with each other there. That said, if we need a process for this for some people to be more comfortable, then that probably should be requested from FESCo.
Discussion requires more than one participating party. I started a thread on java-devel list where I explained the situation and my plans in detail. There was no reply on the list, not a single message. I only had one or two private conversations about this problem.
We could have avoided the bad ending if people dependent on Java packages were given the opportunity to help. As you say, this is a community distro. That goes both ways. But that didn't happen.
IMHO I've been very patient. I've given the community a lot of opportunity to help. I never refused any help. I was and I am still working with new contributors that want to become packagers.
At the risk of overwhelming myself with yet another SIG (I'm in Python, Go, and Rust already!), I'm willing to help as a SIG member if that's what it takes to prevent this. I don't know much about Java packaging (I have only a single Java based package), though.
Dne 12. 03. 19 v 12:34 Neal Gompa napsal(a):
This whole process was handled in the worst possible way. To sum up:
- No one knew Java SIG was having manpower issues because Mikolaj
didn't know how to ask for help
- Now it's too late because he orphaned nearly 1700 packages to force
modularization
- This caused everyone dependent on those packages to freak
- And here we are in the bad ending...
Alternative sum up: * People (not just Mikolaj) started using modules, while Koji cannot use modular repos.
Miroslav
On Tue, Mar 12, 2019 at 11:43 AM Miroslav Suchý msuchy@redhat.com wrote:
Dne 12. 03. 19 v 12:34 Neal Gompa napsal(a):
This whole process was handled in the worst possible way. To sum up:
- No one knew Java SIG was having manpower issues because Mikolaj
didn't know how to ask for help
- Now it's too late because he orphaned nearly 1700 packages to force
modularization
- This caused everyone dependent on those packages to freak
- And here we are in the bad ending...
Alternative sum up:
- People (not just Mikolaj) started using modules, while Koji cannot use modular repos.
Addendum: some of us part-time packagers, which depended on these packages to build our own Java packages don't know how to convert to modular packaging. I'm still trying to learn in my spare time, but I don't know where to look and have limited time. It was nearly all the spare cycles I had just to learn RPM, Fedora RPM packaging policies, and how to use fedpkg, koji, and bodhi. Now... I'm kinda lost again and feel like I'm starting over from scratch. I can't be the only one. I still think a lot of this is being driven by experienced Fedora packagers, and those involved in composes, but without a lot of regard to the casual or relatively inexperienced packager. pkgdb was a highly usable tool for inexperienced packagers, as it was a "one stop shop" for everything related to your package... but now... it's hard to find all the tools you need to do packaging.
I have several Java packages that depend on one another, as well as dependencies now in modular repos. I have no idea where to get started. Which ones should be in the same module? Should each RPM be put in separate modules? How do I create convert my packages to modules? What is the workflow for builds? For updates? Do I still use fedpkg to submit to koji and bodhi? How will users install my RPMs now? I feel a bit overwhelmed by all of this... and I'm sure I should be spending more time trying to figure all this out on my own... but I really don't know where to start.
On Tue, Mar 12, 2019 at 6:20 PM Christopher ctubbsii@fedoraproject.org wrote:
Addendum: some of us part-time packagers, which depended on these packages to build our own Java packages don't know how to convert to modular packaging. I'm still trying to learn in my spare time, but I don't know where to look and have limited time. It was nearly all the spare cycles I had just to learn RPM, Fedora RPM packaging policies, and how to use fedpkg, koji, and bodhi. Now... I'm kinda lost again and feel like I'm starting over from scratch. I can't be the only one. I still think a lot of this is being driven by experienced Fedora packagers, and those involved in composes, but without a lot of regard to the casual or relatively inexperienced packager. pkgdb was a highly usable tool for inexperienced packagers, as it was a "one stop shop" for everything related to your package... but now... it's hard to find all the tools you need to do packaging.
I have several Java packages that depend on one another, as well as dependencies now in modular repos. I have no idea where to get started. Which ones should be in the same module? Should each RPM be put in separate modules? How do I create convert my packages to modules? What is the workflow for builds? For updates? Do I still use fedpkg to submit to koji and bodhi? How will users install my RPMs now? I feel a bit overwhelmed by all of this... and I'm sure I should be spending more time trying to figure all this out on my own... but I really don't know where to start.
With "addon modularity" approach we currently use people shouldn't be required to convert anything to modules. The idea is that parts of Fedora can be modularized upon maintainer discretion. This change should be transparent to users that are not aware of modularity. Likewise, other Fedora developers should be able to maintain their packages, even if their dependencies move to modules. That is not possible without ordinary (non-modular, "ursine") packages being able to be built against modular content. Unfortunately Fedora developers (represented by FESCo) decided to forbid use of modules for building non-modular packages. This was a sad and very disappointing decision to read about and it was the direct cause that made me make the final decision to orphan all packages I used to maintain for years.
Personally I think modularity is a great tool that will allow *me* to reduce the effort needed to maintain packages and at the same time improve user experience. But your mileage may vary. The effort that packagers need to make in order to learn the new technology and change their workflow may greatly outweight any possible gain from modularity, especially for packagers that maintain fewer packages. Therefore I discourage developers from moving their packages to modules if they don't see the benefit for them and their users. Instead I encourage people to talk about the problem. I hope FESCo will finally realize how important it is to allow building any package against modules and change the policy, allowing modules to be used as build dependencies for non-modular packages.
-- Mikolaj Izdebski
On 12. 03. 19 22:11, Mikolaj Izdebski wrote:
I hope FESCo will finally realize how important it is to allow building any package against modules and change the policy, allowing modules to be used as build dependencies for non-modular packages.
Oh we do realize. Especially since everything will break if we don't do this. This was not rejected because we don't want to allow this, but because we were not satisfied with the technical solution.
On Tue, Mar 12, 2019 at 4:42 PM Miroslav Suchý msuchy@redhat.com wrote:
Alternative sum up:
- People (not just Mikolaj) started using modules, while Koji cannot use modular repos.
Incorrect. Koji (the software) *can* use modular repos. I know of more than one installation of Koji that successfully builds non-modular contents against modules. It's Fedora developers (represented by elected body of FESCo) that don't want to use modules in Fedoras' Koji installation.
-- Mikolaj Izdebski
On Tue, 2019-03-12 at 22:18 +0100, Mikolaj Izdebski wrote:
It's Fedora developers (represented by elected body of FESCo) that don't want to use modules in Fedoras' Koji installation.
As Miro said in another post, it's not that FESCo doesn't want to use modules in Koji, it's that we want to make sure that the packager experience is as good as it was pre-modularity, and in particular that packagers can build locally as they can today. IIRC, there were specific concerns about the details of the proposal to use Ursa Major that were raised at the time.
I do think most of FESCo does want to see the problem solved.
On Tue, Mar 12, 2019 at 6:03 PM Randy Barlow bowlofeggs@fedoraproject.org wrote:
As Miro said in another post, it's not that FESCo doesn't want to use modules in Koji, it's that we want to make sure that the packager experience is as good as it was pre-modularity, and in particular that packagers can build locally as they can today. IIRC, there were specific concerns about the details of the proposal to use Ursa Major that were raised at the time.
Well, the packager experience I'm expecting in 3 weeks is: "almost all of my dependencies and BuildRequires are gone; I can't build anything". How much worse could it get than that?
On Tue, 2019-03-12 at 18:39 -0400, Christopher wrote:
Well, the packager experience I'm expecting in 3 weeks is: "almost all of my dependencies and BuildRequires are gone; I can't build anything". How much worse could it get than that?
Fair. I don't think we anticipated the large migration that happened when we were discussing it, or at least, I personally don't recall anyone bringing this up as a potential issue.
On Wed, Mar 13, 2019 at 10:07 AM Randy Barlow bowlofeggs@fedoraproject.org wrote:
On Tue, 2019-03-12 at 18:39 -0400, Christopher wrote:
Well, the packager experience I'm expecting in 3 weeks is: "almost all of my dependencies and BuildRequires are gone; I can't build anything". How much worse could it get than that?
Fair. I don't think we anticipated the large migration that happened when we were discussing it, or at least, I personally don't recall anyone bringing this up as a potential issue.
One of the threads on this topic included the phrase "everything will most likely burn". So, it was certainly mentioned that it was a serious issue. Mikolaj also stressed the importance of this issue several times. Whether anybody took it seriously or not as an issue is another matter, but it was definitely raised as a "potential issue".
On 13. 03. 19 18:05, Christopher wrote:
On Wed, Mar 13, 2019 at 10:07 AM Randy Barlow bowlofeggs@fedoraproject.org wrote:
On Tue, 2019-03-12 at 18:39 -0400, Christopher wrote:
Well, the packager experience I'm expecting in 3 weeks is: "almost all of my dependencies and BuildRequires are gone; I can't build anything". How much worse could it get than that?
Fair. I don't think we anticipated the large migration that happened when we were discussing it, or at least, I personally don't recall anyone bringing this up as a potential issue.
One of the threads on this topic included the phrase "everything will most likely burn". So, it was certainly mentioned that it was a serious issue. Mikolaj also stressed the importance of this issue several times. Whether anybody took it seriously or not as an issue is another matter, but it was definitely raised as a "potential issue".
That was me (the "everything will most likely burn" subject). I take this seriously. Not seriously enough to allow half baked solution that will break more things, but seriously enough to be concerned and care.
* Mikolaj Izdebski:
On Tue, Mar 12, 2019 at 4:42 PM Miroslav Suchý msuchy@redhat.com wrote:
Alternative sum up:
- People (not just Mikolaj) started using modules, while Koji cannot use modular repos.
Incorrect. Koji (the software) *can* use modular repos. I know of more than one installation of Koji that successfully builds non-modular contents against modules.
Which installation would that be? I would be surprised if there was *any* module-capable version of Koji out there.
For example, is there a Koji version that can handle correctly the case where one module provides Python 2 subpackages of a source RPM, and another module provides Python 3 subpackages from a source RPM of the same name?
As far as I understand it, under the Koji model, one of the tags wins, and which one determines whether you get the Python 2 subpackage or the Python 3 subpackage. You cannot get both. You will need two or more buildroots for that.
Thanks, Florian
On Wed, Mar 13, 2019 at 11:59 AM Florian Weimer fweimer@redhat.com wrote:
- Mikolaj Izdebski:
On Tue, Mar 12, 2019 at 4:42 PM Miroslav Suchý msuchy@redhat.com wrote:
Alternative sum up:
- People (not just Mikolaj) started using modules, while Koji cannot use modular repos.
Incorrect. Koji (the software) *can* use modular repos. I know of more than one installation of Koji that successfully builds non-modular contents against modules.
Which installation would that be? I would be surprised if there was *any* module-capable version of Koji out there.
Private installations that are not accessible publicly. I run one of them myself.
For example, is there a Koji version that can handle correctly the case where one module provides Python 2 subpackages of a source RPM, and another module provides Python 3 subpackages from a source RPM of the same name?
Yes, Koji can do that, since version 1.14.
As far as I understand it, under the Koji model, one of the tags wins, and which one determines whether you get the Python 2 subpackage or the Python 3 subpackage. You cannot get both. You will need two or more buildroots for that.
That used to be the case, but for some time Koji supports "repo_include_all" option [1] that has the exact effect you describe - when set it makes build repos include all tagged RPMs, even if they come from different SRPMs that happen to have the same name.
[1] https://pagure.io/koji/issue/588
-- Mikolaj
* Mikolaj Izdebski:
As far as I understand it, under the Koji model, one of the tags wins, and which one determines whether you get the Python 2 subpackage or the Python 3 subpackage. You cannot get both. You will need two or more buildroots for that.
That used to be the case, but for some time Koji supports "repo_include_all" option [1] that has the exact effect you describe - when set it makes build repos include all tagged RPMs, even if they come from different SRPMs that happen to have the same name.
*Very* interesting.
Could this be used to address this issue, too?
https://pagure.io/koji/issue/273
(Including select i686 packages in the x86_64 buildroot.)
Thanks, Florian
On Wed, Mar 13, 2019 at 12:49 PM Florian Weimer fweimer@redhat.com wrote:
- Mikolaj Izdebski:
As far as I understand it, under the Koji model, one of the tags wins, and which one determines whether you get the Python 2 subpackage or the Python 3 subpackage. You cannot get both. You will need two or more buildroots for that.
That used to be the case, but for some time Koji supports "repo_include_all" option [1] that has the exact effect you describe - when set it makes build repos include all tagged RPMs, even if they come from different SRPMs that happen to have the same name.
*Very* interesting.
Could this be used to address this issue, too?
https://pagure.io/koji/issue/273
(Including select i686 packages in the x86_64 buildroot.)
No, not by itself. repo_include_all won't lead to inclusion of RPMs with non-matching arches.
-- Mikolaj Izdebski
On Tue, 2019-03-12 at 12:16 +0100, Dominik 'Rathann' Mierzejewski wrote:
Maybe, but it will cause the removal of other packages that depend on their regular (non-modular) builds. You are forcing the hands of their maintainers before the infrastructure to make modular packages available as build dependencies to regular packages is in place to remake their packages into modules, let them be retired or pick up your orphans. If it were ready, your moving these packages to modules would be a non-event for everyone concerned except you. Instead of helping with that (or just waiting), you are about to cause the retirement of quite a few packages whose maintainers want nothing to do with Modularity. That's not excellent.
It's important to keep in mind that many of us volunteer to work on Fedora, including those of us who work at Red Hat (and even including those of us who work at Red Hat full time on Fedora!) I do personally wish we had RPM maintainers for these Java packages, but I don't think we should make demands from our volunteers. That's not how a community project works. I think it's OK to express that we wish there were RPMs for these packages, but we shouldn't blame any particular person when that doesn't happen. Things happen in open source when people do the work to make those things happen. As much as I wish we could save these packages, I am not going to choose to use my time that way. So the most I would say about it is "it'd be nice if someone else volunteered to do that work".
I sometimes receive bug reports in Bodhi where the reporter has a demanding attitude. I welcome bug reports, but I also have to be honest that maintaining Bodhi is far more work than the people who show up to do it can handle. Most things in Bodhi will only happen if someone volunteers to write the code, so most of the bugs we get filed aren't going to get worked on. It's not helpful to either party if the reporter has a demanding attitude.
On Tue, Mar 12, 2019 at 12:17 PM Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Tuesday, 12 March 2019 at 12:02, Mikolaj Izdebski wrote:
On Tue, Mar 12, 2019 at 11:49 AM Jakub Jelen jjelen@redhat.com wrote:
Is there already a way to package the java application as a module or we will really remove all these package from Fedora?
Most of Java packages listed in this thread are already packaged as modules. Their retirement in rawhide won't directly cause their removal from distribution.
Maybe, but it will cause the removal of other packages that depend on their regular (non-modular) builds. You are forcing the hands of their maintainers before the infrastructure to make modular packages available as build dependencies to regular packages is in place to remake their packages into modules, let them be retired or pick up your orphans. If it were ready, your moving these packages to modules would be a non-event for everyone concerned except you. Instead of helping with that (or just waiting), you are about to cause the retirement of quite a few packages whose maintainers want nothing to do with Modularity. That's not excellent.
I am not forcing anyone to do anything. If I followed your thinking then I colud say that by not adopting orphaned packages you are forcing others to do the same things you accuse me of forcing people to.
Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Tue, Mar 12, 2019, 22:37 Mikolaj Izdebski mizdebsk@redhat.com wrote:
On Tue, Mar 12, 2019 at 12:17 PM Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Tuesday, 12 March 2019 at 12:02, Mikolaj Izdebski wrote:
On Tue, Mar 12, 2019 at 11:49 AM Jakub Jelen jjelen@redhat.com
wrote:
Is there already a way to package the java application as a module or we will really remove all these package from Fedora?
Most of Java packages listed in this thread are already packaged as modules. Their retirement in rawhide won't directly cause their removal from distribution.
Maybe, but it will cause the removal of other packages that depend on their regular (non-modular) builds. You are forcing the hands of their maintainers before the infrastructure to make modular packages available as build dependencies to regular packages is in place to remake their packages into modules, let them be retired or pick up your orphans. If it were ready, your moving these packages to modules would be a non-event for everyone concerned except you. Instead of helping with that (or just waiting), you are about to cause the retirement of quite a few packages whose maintainers want nothing to do with Modularity. That's not excellent.
I am not forcing anyone to do anything. If I followed your thinking then I colud say that by not adopting orphaned packages you are forcing others to do the same things you accuse me of forcing people to.
Still, by making your life a bit easier (by dropping "normal" packages and moving everything to modules), you make the life of every packager that depends on those packages harder.
Can you give us a minimal set of packages that is required to make sure libreoffice etc. aren't caught up in the mass retirement?
I could try to figure that out from the contents of the linked dependency graph, but you probably already have that information somewhere.
We might want to look for maintainers for that minimal set, at least. (I think my Package Stewardship SIG idea is showing its merits here ...)
Fabio
Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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-leave@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
On ke, 13 maalis 2019, Fabio Valentini wrote:
On Tue, Mar 12, 2019, 22:37 Mikolaj Izdebski mizdebsk@redhat.com wrote:
On Tue, Mar 12, 2019 at 12:17 PM Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Tuesday, 12 March 2019 at 12:02, Mikolaj Izdebski wrote:
On Tue, Mar 12, 2019 at 11:49 AM Jakub Jelen jjelen@redhat.com
wrote:
Is there already a way to package the java application as a module or we will really remove all these package from Fedora?
Most of Java packages listed in this thread are already packaged as modules. Their retirement in rawhide won't directly cause their removal from distribution.
Maybe, but it will cause the removal of other packages that depend on their regular (non-modular) builds. You are forcing the hands of their maintainers before the infrastructure to make modular packages available as build dependencies to regular packages is in place to remake their packages into modules, let them be retired or pick up your orphans. If it were ready, your moving these packages to modules would be a non-event for everyone concerned except you. Instead of helping with that (or just waiting), you are about to cause the retirement of quite a few packages whose maintainers want nothing to do with Modularity. That's not excellent.
I am not forcing anyone to do anything. If I followed your thinking then I colud say that by not adopting orphaned packages you are forcing others to do the same things you accuse me of forcing people to.
Still, by making your life a bit easier (by dropping "normal" packages and moving everything to modules), you make the life of every packager that depends on those packages harder.
Can you give us a minimal set of packages that is required to make sure libreoffice etc. aren't caught up in the mass retirement?
I could try to figure that out from the contents of the linked dependency graph, but you probably already have that information somewhere.
We might want to look for maintainers for that minimal set, at least. (I think my Package Stewardship SIG idea is showing its merits here ...)
Another, pragmatic, approach would be to actually postpone or revert orphaning process for all those packages now that there is understanding that FESCO is not opposed and is merely looking for a satisfying technical solution. I've been told by contyk and others that it is closer to reality now.
On Wed, Mar 13, 2019, 07:42 Alexander Bokovoy abokovoy@redhat.com wrote:
On ke, 13 maalis 2019, Fabio Valentini wrote:
On Tue, Mar 12, 2019, 22:37 Mikolaj Izdebski mizdebsk@redhat.com wrote:
On Tue, Mar 12, 2019 at 12:17 PM Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Tuesday, 12 March 2019 at 12:02, Mikolaj Izdebski wrote:
On Tue, Mar 12, 2019 at 11:49 AM Jakub Jelen jjelen@redhat.com
wrote:
Is there already a way to package the java application as a
module or
we will really remove all these package from Fedora?
Most of Java packages listed in this thread are already packaged as modules. Their retirement in rawhide won't directly cause their removal from distribution.
Maybe, but it will cause the removal of other packages that depend on their regular (non-modular) builds. You are forcing the hands of their maintainers before the infrastructure to make modular packages
available
as build dependencies to regular packages is in place to remake their packages into modules, let them be retired or pick up your orphans. If it were ready, your moving these packages to modules would be a non-event for everyone concerned except you. Instead of helping with that (or just waiting), you are about to cause the retirement of
quite a
few packages whose maintainers want nothing to do with Modularity. That's not excellent.
I am not forcing anyone to do anything. If I followed your thinking then I colud say that by not adopting orphaned packages you are forcing others to do the same things you accuse me of forcing people to.
Still, by making your life a bit easier (by dropping "normal" packages and moving everything to modules), you make the life of every packager that depends on those packages harder.
Can you give us a minimal set of packages that is required to make sure libreoffice etc. aren't caught up in the mass retirement?
I could try to figure that out from the contents of the linked dependency graph, but you probably already have that information somewhere.
We might want to look for maintainers for that minimal set, at least. (I think my Package Stewardship SIG idea is showing its merits here ...)
Another, pragmatic, approach would be to actually postpone or revert orphaning process for all those packages now that there is understanding that FESCO is not opposed and is merely looking for a satisfying technical solution. I've been told by contyk and others that it is closer to reality now.
This might come across as cynical, but a "solution" has been "just around the corner" for months / years, but these they have so far all been scrapped again.
Fabio
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Wed, Mar 13, 2019 at 7:21 AM Fabio Valentini decathorpe@gmail.com wrote:
Can you give us a minimal set of packages that is required to make sure libreoffice etc. aren't caught up in the mass retirement?
The minimal package set is the contents of javapackages-tools module, stream 201801. There are about 185 packages in that module. That set of packages is self-hosting (doesn't depend on any other Java packages except OpenJDK) and gives you two basic build systems (Maven, Ant) with RPM integration.
-- Mikolaj Izdebski
On Wed, Mar 13, 2019 at 6:23 AM Mikolaj Izdebski mizdebsk@redhat.com wrote:
On Wed, Mar 13, 2019 at 7:21 AM Fabio Valentini decathorpe@gmail.com wrote:
Can you give us a minimal set of packages that is required to make sure libreoffice etc. aren't caught up in the mass retirement?
The minimal package set is the contents of javapackages-tools module, stream 201801. There are about 185 packages in that module. That set of packages is self-hosting (doesn't depend on any other Java packages except OpenJDK) and gives you two basic build systems (Maven, Ant) with RPM integration.
Is it possible to use that module in F29? I don't want to move to rawhide, since I'm a Fedora user first, and a packager second. I don't see javapackages-tools in `sudo dnf module list`.
Hi,
On 12-03-19 11:38, Miro Hrončok wrote:
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired.
Grep the list for your FAS name, follow the transitive deps: https://churchyard.fedorapeople.org/orphans-2019-03-11.txt
<snip> I'm sorry but just dropping all the java packages because they have been moved to modules, totally breaking rawhide is simply unacceptable.
A solution for this needs to be found and be in place *before* dropping these packages not the otherway around.
We are working to make rawhide more stable: https://fedoraproject.org/wiki/Changes/GatingRawhideSinglePackageUpdates https://fedoraproject.org/wiki/Infrastructure_2020/Rawhide_Gating
Yet we are going to go ahead with this java package removal and break the world? That is just totally unacceptable. I've filed a FESCo issue requesting FESCo to block this:
https://pagure.io/fesco/issue/2104
Regards,
Hans
p.s.
I must admit that I've been too busy with other things to closely follow the whole modularity process. So far most talk has been about BuildRequires, but what about regular Requires, can a package in the base repo have a Requires on a package only available in a module ?
* Hans de Goede [13/03/2019 08:51] :
A solution for this needs to be found and be in place *before* dropping these packages not the otherway around.
We've known the solution for months, now.
If you (this is the generic you, not you specifically) want these packages to be in the distribution, you need to step up and ask for maintainership of said packages.
It's that simple, folks.
Emmanuel
Hi,
On 3/13/19 9:45 AM, Emmanuel Seyman wrote:
- Hans de Goede [13/03/2019 08:51] :
A solution for this needs to be found and be in place *before* dropping these packages not the otherway around.
We've known the solution for months, now.
If you (this is the generic you, not you specifically) want these packages to be in the distribution, you need to step up and ask for maintainership of said packages.
It's that simple, folks.
Sure I already own 150 pkgs I can take 4-5 more without really noticing it, but I will only be fixing FTBFS errors and other blockers on them, while at the same time they are being actively, probably better, maintained in modules, so now we have a "kept alive as dep only" version in base and an active maintained version in a module, this seems undesirable.
But lets get specific, one of the main issues here is all java packages depending on javapackages-tools, which according to the top-post of this thread is going away. Do we really want someone who maintains a few leave packages which happen to depend on java to take this in base?
Also javapackages-tools does not look orphaned here: https://src.fedoraproject.org/rpms/javapackages-tools
So has the orphaning of that one been undone ?
Regards,
Hans
On Tue, Mar 12, 2019 at 11:38:47AM +0100, Miro Hrončok wrote:
rjones: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn, plexus-utils
I'm unclear what if anything I could do (apart from maintaining loads of Java packages which isn't going to happen). Is the email saying that some package of mine depends on these? And if so which one?
Rich.
Richard W.M. Jones wrote:
On Tue, Mar 12, 2019 at 11:38:47AM +0100, Miro Hrončok wrote:
rjones: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn, plexus-utils
I'm unclear what if anything I could do (apart from maintaining loads of Java packages which isn't going to happen). Is the email saying that some package of mine depends on these? And if so which one?
The list of the expanded deps was quite large, so Miro included a link to it in his message:
Grep the list for your FAS name, follow the transitive deps: https://churchyard.fedorapeople.org/orphans-2019-03-11.txt
$ grep rjones[^:] /tmp/orphans-2019-03-11.txt | sort -u erlang (maintained by: gemi, jeckersb, ndim, peter, rjones, skottler) libguestfs (maintained by: mdbooth, ptoscano, rjones) qemu (maintained by: amitshah, berrange, bonzini, crobinso, dwmw2, ehabkost, jforbes, lkundrak, quintela, rjones, virtmaint-sig)
On Fri, Mar 15, 2019 at 12:40:00PM -0400, Todd Zullinger wrote:
Richard W.M. Jones wrote:
On Tue, Mar 12, 2019 at 11:38:47AM +0100, Miro Hrončok wrote:
rjones: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, xmvn, plexus-utils
I'm unclear what if anything I could do (apart from maintaining loads of Java packages which isn't going to happen). Is the email saying that some package of mine depends on these? And if so which one?
The list of the expanded deps was quite large, so Miro included a link to it in his message:
Grep the list for your FAS name, follow the transitive deps: https://churchyard.fedorapeople.org/orphans-2019-03-11.txt
I couldn't find this by grepping my username, but thanks for the link.
$ grep rjones[^:] /tmp/orphans-2019-03-11.txt | sort -u erlang (maintained by: gemi, jeckersb, ndim, peter, rjones, skottler) libguestfs (maintained by: mdbooth, ptoscano, rjones) qemu (maintained by: amitshah, berrange, bonzini, crobinso, dwmw2, ehabkost, jforbes, lkundrak, quintela, rjones, virtmaint-sig)
These are very important packages. What do we have to do here? Is Java being dropped from the distro?
Rich.
* Richard W.M. Jones [15/03/2019 20:23] :
These are very important packages. What do we have to do here?
I'm going to repeat this until it sinks in...
If you (this is the generic you, not you specifically) want these packages to be in the distribution, you need to step up and ask for maintainership of said packages or incite people who are interested in maintaining Java packages to do so.
Is Java being dropped from the distro?
Yes, that's what we were warned about months ago.
Emmanuel
On Fri, 15 Mar 2019 23:48:49 +0100, you wrote:
- Richard W.M. Jones [15/03/2019 20:23] :
Is Java being dropped from the distro?
Yes, that's what we were warned about months ago.
Don't think so.
Nothing has been said about dropping Java, and if anything the OpenJDK packagers have been more active with having multiple versions of Java now being necessary.
However a bunch of Java packages are being retired, and those packages are required for a bunch of other packages.
On Fri, 2019-03-15 at 19:36 -0400, Gerald Henriksen wrote:
On Fri, 15 Mar 2019 23:48:49 +0100, you wrote:
- Richard W.M. Jones [15/03/2019 20:23] :
Is Java being dropped from the distro?
Yes, that's what we were warned about months ago.
Don't think so.
Nothing has been said about dropping Java, and if anything the OpenJDK packagers have been more active with having multiple versions of Java now being necessary.
However a bunch of Java packages are being retired, and those packages are required for a bunch of other packages.
No. The java is not dropped from distro, but moved from normal release cycle to the modular release for better packaging experience and so on. Yes, the side effect of the moving is that the rawhide branch is orphaned and will be retired unless somebody else will maintain it. And yes, this will bring with it many other packages that depend on that, because there is no way to build them against the java packages in the modules (I did not even managed to find a way how to build my package as a module against this java-packages module so I gave up again after few more tries last week).
For the record, there is a fesco ticket discussing the delay of the retiring, hopefully before we will have a way to build these packages again:
https://pagure.io/fesco/issue/2104
Regards,
On Mon, 18 Mar 2019 at 05:35, Jakub Jelen jjelen@redhat.com wrote:
On Fri, 2019-03-15 at 19:36 -0400, Gerald Henriksen wrote:
On Fri, 15 Mar 2019 23:48:49 +0100, you wrote:
- Richard W.M. Jones [15/03/2019 20:23] :
Is Java being dropped from the distro?
Yes, that's what we were warned about months ago.
Don't think so.
Nothing has been said about dropping Java, and if anything the OpenJDK packagers have been more active with having multiple versions of Java now being necessary.
However a bunch of Java packages are being retired, and those packages are required for a bunch of other packages.
No. The java is not dropped from distro, but moved from normal release cycle to the modular release for better packaging experience and so on. Yes, the side effect of the moving is that the rawhide branch is orphaned and will be retired unless somebody else will maintain it. And yes, this will bring with it many other packages that depend on that, because there is no way to build them against the java packages in the modules (I did not even managed to find a way how to build my package as a module against this java-packages module so I gave up again after few more tries last week).
To me this all looks like a game of Othello where one side of the board is white, but black keeps laying down pieces and changing large areas to their colour. [Or in other board games where strategic moves of packages means everything else has to swap over to remain viable.] Even with 'ursa major' to slow it down, it is still an 'inevitability' that large parts of the distribution will fall into modularity space in the next couple of releases.. if only because people will start making '1 package' modules of whatever they are maintaining so they can keep their dependencies.
For the record, there is a fesco ticket discussing the delay of the retiring, hopefully before we will have a way to build these packages again:
https://pagure.io/fesco/issue/2104
Regards,
Jakub Jelen Software Engineer Security Technologies Red Hat, Inc. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Mon, Mar 18, 2019 at 10:34:23AM +0100, Jakub Jelen wrote:
On Fri, 2019-03-15 at 19:36 -0400, Gerald Henriksen wrote:
On Fri, 15 Mar 2019 23:48:49 +0100, you wrote:
- Richard W.M. Jones [15/03/2019 20:23] :
Is Java being dropped from the distro?
Yes, that's what we were warned about months ago.
Don't think so.
Nothing has been said about dropping Java, and if anything the OpenJDK packagers have been more active with having multiple versions of Java now being necessary.
However a bunch of Java packages are being retired, and those packages are required for a bunch of other packages.
No. The java is not dropped from distro, but moved from normal release cycle to the modular release for better packaging experience and so on. Yes, the side effect of the moving is that the rawhide branch is orphaned and will be retired unless somebody else will maintain it. And yes, this will bring with it many other packages that depend on that, because there is no way to build them against the java packages in the modules (I did not even managed to find a way how to build my package as a module against this java-packages module so I gave up again after few more tries last week).
The actual effect of this is that I'm going to disable Java bindings for all the affected packages. Java loses, Fedora loses.
Rich.
For the record, there is a fesco ticket discussing the delay of the retiring, hopefully before we will have a way to build these packages again:
https://pagure.io/fesco/issue/2104
Regards,
Jakub Jelen Software Engineer Security Technologies Red Hat, Inc. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
-
Aleksandar Kurtakov -
Alexander Bokovoy -
Christopher -
Dominik 'Rathann' Mierzejewski -
Emmanuel Seyman -
Fabio Valentini -
Florian Weimer -
Gerald Henriksen -
Hans de Goede -
Jakub Jelen -
Mikolaj Izdebski -
Miro Hrončok -
Miroslav Suchý -
Neal Gompa -
Orcan Ogetbil -
Randy Barlow -
Richard W.M. Jones -
Stephen John Smoogen -
Todd Zullinger