Hello,
I've split the slf4j package into subpackages. The api, simple and nop submodules were left in the main package, in order not to break many packages that depend on slf4j.
Submodules that were moved into subpackages: jdk14 log4j12 jcl ext jcl-over-slf4j log4j-over-slf4j jul-to-slf4j
If some of your packages require one of those, please change your BuildRequires accordingly. Most of the packages shouldn't be affected. If your package needs just api, nop or simple submodules or you use mvn() style BuildRequires, no changes should be necessary.
Regards, Michael Simacek
On 03/07/2014 03:01 PM, Michael Simacek wrote:
I've split the slf4j package into subpackages. The api, simple and nop submodules were left in the main package, in order not to break many packages that depend on slf4j.
[...]
If some of your packages require one of those, please change your BuildRequires accordingly. Most of the packages shouldn't be affected. If your package needs just api, nop or simple submodules or you use mvn() style BuildRequires, no changes should be necessary.
Packages that require or build-require slf4j and therefore are possibly affected by this change:
activemq aether aether-ant-tasks aether-connector-okhttp amplab-tachyon apacheds apacheds-shared apache-mina aries-proxy aries-quiesce arquillian-core async-http-client avro bookkeeper btm bval cas-client curator cxf eclipse-m2e-core eclipse-m2e-egit eclipse-m2e-modello eclipse-m2e-plexus ehcache-core freemarker gemini-blueprint glusterfs-hadoop gmetrics gooddata-cl google-guice guacamole-client h2 hadoop ha-jdbc hbase hibernate hibernate-commons-annotations hibernate-search jacorb jboss-logging jericho-html jetty jetty8 jhdf5 jul-to-slf4j-stub littleproxy logback maven maven-indexer maven-wagon metrics mule mybatis mysql-connector-java narayana netty netty3 oat olfs openjpa opensaml-java opensaml-java-openws opensaml-java-xmltooling openshift-java-client ops4j-base plexus-cdc quartz resteasy restlet-jse seam-solder sisu-mojos slf4j-jboss-logmanager solr3 sonatype-gossip springframework springframework-batch spymemcached sshj subethasmtp tesla-filelock thredds thrift tiles truecommons wildfly wss4j xbean zanata-api zanata-client zanata-common zanata-parent zookeeper
On 03/07/2014 09:01 AM, Michael Simacek wrote:
I've split the slf4j package into subpackages. The api, simple and nop submodules were left in the main package, in order not to break many packages
In my opinion, the best way to do that is to have the slf4j package be empty and then have Requires on the subpackages that you think you need. One advantage of this method is that it allows a full package split.
Even though I think that the current split is a step in the right direction, it still shows the arbitrary way in which Fedora Java packaging has always been done, where, instead of splitting all artifacts according to upstream, the packager just chooses either a full monolithic package with everything (usually with incorrect Requires), or whimsically splits out some arbitrary subset of jars.
Please note that this is not meant to be a criticism of this packager or any packager generally, but an expression of my opinion in general.
On Fri, Mar 7, 2014 at 1:02 PM, David Walluck david@zarb.org wrote:
On 03/07/2014 09:01 AM, Michael Simacek wrote:
I've split the slf4j package into subpackages. The api, simple and nop submodules were left in the main package, in order not to break many packages
In my opinion, the best way to do that is to have the slf4j package be empty and then have Requires on the subpackages that you think you need. One advantage of this method is that it allows a full package split.
Even though I think that the current split is a step in the right direction, it still shows the arbitrary way in which Fedora Java packaging has always been done, where, instead of splitting all artifacts according to upstream, the packager just chooses either a full monolithic package with everything (usually with incorrect Requires), or whimsically splits out some arbitrary subset of jars.
Please note that this is not meant to be a criticism of this packager or any packager generally, but an expression of my opinion in general.
I agree with this. As a long-time Fedora user, hoping to start contributing some java packages (which will likely depend on slf4j), I think this would be a good precedent to set.
-- Christopher L Tubbs II http://gravatar.com/ctubbsii
Hi all, I'm not familiar with packaging, but I'm very familiar with several java projects on this list, I maintain some of them.
For the projects I'm involved with we moved away from SLF4J a couple of years ago, so either Fedora is packaging very old versions or the dependency descriptions are outdated.
I'd be happy to help reviewing these builds if you could spare some pointers to where these things are maintained? Just please don't assume I can patch them myself, this kind of distribution for java dependencies got my attention but is an entirely new concept to me.
My primary goal is to make sure users: - get the latest stable versions - keep their dependency tree lean
Sanne
On 7 March 2014 21:23, Christopher ctubbsii@apache.org wrote:
On Fri, Mar 7, 2014 at 1:02 PM, David Walluck david@zarb.org wrote:
On 03/07/2014 09:01 AM, Michael Simacek wrote:
I've split the slf4j package into subpackages. The api, simple and nop submodules were left in the main package, in order not to break many packages
In my opinion, the best way to do that is to have the slf4j package be empty and then have Requires on the subpackages that you think you need. One advantage of this method is that it allows a full package split.
Even though I think that the current split is a step in the right direction, it still shows the arbitrary way in which Fedora Java packaging has always been done, where, instead of splitting all artifacts according to upstream, the packager just chooses either a full monolithic package with everything (usually with incorrect Requires), or whimsically splits out some arbitrary subset of jars.
Please note that this is not meant to be a criticism of this packager or any packager generally, but an expression of my opinion in general.
I agree with this. As a long-time Fedora user, hoping to start contributing some java packages (which will likely depend on slf4j), I think this would be a good precedent to set.
-- Christopher L Tubbs II http://gravatar.com/ctubbsii -- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
java-devel@lists.fedoraproject.org
-
Christopher -
David Walluck -
Michael Šimáček -
Mikolaj Izdebski -
Sanne Grinovero