[ https://issues.apache.org/jira/browse/LOG4J2-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13903289#comment-13903289 ]
Remko Popma edited comment on LOG4J2-346 at 2/17/14 2:52 PM: ------------------------------------------------------------- Matt, I've committed your patch in revision 1569015, can you check? Before we mark this issue as resolved, what are your thoughts on naming things for OSGi? I noticed that in this patch, the two submodules have artifactIds {{log4j-to-slf4j-bundle}} and {{log4j-slf4j-impl-bundle}}, ending in "bundle". I actually kind of liked the convention(?) we had before where the word "osgi" was in the artifactId. What about using this as the naming rule for OSGi sub-modules and artifactIds? ||submodule||artifact Id|| |log4j-osgi/moduleName<-optionalBundleName>|log4j-osgi-moduleName<-optionalBundleName>| So for the core bundles we have a bunch of sub-bundles, if there is only one osgi bundle per module we just use the module name. From the current osgi submodule names I would like to remove the word "osgi" (as they are all already submodules of the log4j-osgi module), and for the artifactIds I would like to prefix all of them with {{log4j-osgi}}. By giving them a common prefix, all resulting jar files are automatically grouped more clearly than when their names end in the {{bundle}} suffix. So I propose the following changes: ||current submodule||proposed submodule||current artifact Id||proposed artifact Id|| |log4j-osgi/core-{color:blue}osgi{color}-legacy-api|log4j-osgi/1.2-api|log4j-{color:blue}1.2-osgi{color}-api|log4j-osgi-1.2-api| |log4j-osgi/core-{color:blue}osgi{color}-async|log4j-osgi/core-async|log4j-{color:blue}core-osgi{color}-async|log4j-osgi-core-async| |log4j-osgi/core-{color:blue}osgi{color}-jpa|log4j-osgi/core-jpa|log4j-{color:blue}core-osgi{color}-jpa|log4j-osgi-core-jpa| |log4j-osgi/core-{color:blue}osgi{color}-net|log4j-osgi/core-net|log4j-{color:blue}core-osgi{color}-net|log4j-osgi-core-net| |log4j-osgi/core-{color:blue}osgi{color}-nosql-couchdb|log4j-osgi/core-nosql-couchdb|log4j-{color:blue}core-osgi{color}-nosql-couchdb|log4j-osgi-core-nosql-couchdb| |log4j-osgi/core-{color:blue}osgi{color}-nosql-mongodb|log4j-osgi/core-nosql-mongodb|log4j-{color:blue}core-osgi{color}-nosql-mongodb|log4j-osgi-core-nosql-mongodb| |log4j-osgi/core-{color:blue}osgi{color}-reduced|log4j-osgi/core-reduced|log4j-{color:blue}core-osgi{color}-reduced|log4j-osgi-core-reduced| |log4j-osgi/log4j-to-slf4j|log4j-osgi/log4j-to-slf4j|log4j-to-slf4j{color:blue}-bundle{color}|log4j-osgi-to-slf4j| |log4j-osgi/slf4j-{color:blue}to-log4j{color}|log4j-osgi/slf4j-impl|log4j-slf4j-impl{color:blue}-bundle{color}|log4j-osgi-slf4j-impl| Thoughts? was (Author: rem...@yahoo.com): Matt, I've committed your patch in revision , can you check? Before we mark this issue as resolved, what are your thoughts on naming things for OSGi? I noticed that in this patch, the two submodules have artifactIds {{log4j-to-slf4j-bundle}} and {{log4j-slf4j-impl-bundle}}, ending in "bundle". I actually kind of liked the convention(?) we had before where the word "osgi" was in the artifactId. What about using this as the naming rule for OSGi sub-modules and artifactIds? ||submodule||artifact Id|| |log4j-osgi/moduleName<-optionalBundleName>|log4j-osgi-moduleName<-optionalBundleName>| So for the core bundles we have a bunch of sub-bundles, if there is only one osgi bundle per module we just use the module name. From the current osgi submodule names I would like to remove the word "osgi" (as they are all already submodules of the log4j-osgi module), and for the artifactIds I would like to prefix all of them with {{log4j-osgi}}. By giving them a common prefix, all resulting jar files are automatically grouped more clearly than when their names end in the {{bundle}} suffix. So I propose the following changes: ||current submodule||proposed submodule||current artifact Id||proposed artifact Id|| |log4j-osgi/core-{color:blue}osgi{color}-legacy-api|log4j-osgi/1.2-api|log4j-{color:blue}1.2-osgi{color}-api|log4j-osgi-1.2-api| |log4j-osgi/core-{color:blue}osgi{color}-async|log4j-osgi/core-async|log4j-{color:blue}core-osgi{color}-async|log4j-osgi-core-async| |log4j-osgi/core-{color:blue}osgi{color}-jpa|log4j-osgi/core-jpa|log4j-{color:blue}core-osgi{color}-jpa|log4j-osgi-core-jpa| |log4j-osgi/core-{color:blue}osgi{color}-net|log4j-osgi/core-net|log4j-{color:blue}core-osgi{color}-net|log4j-osgi-core-net| |log4j-osgi/core-{color:blue}osgi{color}-nosql-couchdb|log4j-osgi/core-nosql-couchdb|log4j-{color:blue}core-osgi{color}-nosql-couchdb|log4j-osgi-core-nosql-couchdb| |log4j-osgi/core-{color:blue}osgi{color}-nosql-mongodb|log4j-osgi/core-nosql-mongodb|log4j-{color:blue}core-osgi{color}-nosql-mongodb|log4j-osgi-core-nosql-mongodb| |log4j-osgi/core-{color:blue}osgi{color}-reduced|log4j-osgi/core-reduced|log4j-{color:blue}core-osgi{color}-reduced|log4j-osgi-core-reduced| |log4j-osgi/log4j-to-slf4j|log4j-osgi/log4j-to-slf4j|log4j-to-slf4j{color:blue}-bundle{color}|log4j-osgi-to-slf4j| |log4j-osgi/slf4j-{color:blue}to-log4j{color}|log4j-osgi/slf4j-impl|log4j-slf4j-impl{color:blue}-bundle{color}|log4j-osgi-slf4j-impl| Thoughts? > Cyclic dependency in OSGi-context. Apache Log4j SLF4J Binding <-> slf4j-api > --------------------------------------------------------------------------- > > Key: LOG4J2-346 > URL: https://issues.apache.org/jira/browse/LOG4J2-346 > Project: Log4j 2 > Issue Type: Bug > Components: Core, SLF4J Bridge > Affects Versions: 2.0-beta4, 2.0-beta8, 2.0-beta9 > Environment: OSGi R5 / Apache Felix 4.x > Reporter: Roland Weiglhofer > Priority: Blocker > Labels: Bundle, OSGi, SLF4J > Fix For: 2.0-rc1 > > Attachments: 0001-Add-SLF4J-related-bundles.patch, > log4j2-slf4j-impl.patch > > > The bundle "Apache Log4j SLF4J Binding" (2.0.0.beta8) has an unresolved > dependency to the package org.slf4j which is exported by the slf4j-api > bundle. The Slf4j-api bundle has also an unresolved dependency to the package > org.slf4j.impl which is exported by the bundle "Apache Log4j SLF4J Binding". > Without the slf4j-api everything works. But the Slf4j-api bundle is needed > because of given dependencies of third-party-bundles. The "Apache Log4j SLF4J > Binding" bundle should also export the package org.slf4j. > ---------------------------------------------------------------- > ID|State |Level|Name > 0|Active | 0|System Bundle (4.2.1) > 4|Active | 2|Apache Felix Bundle Repository (1.6.6) > 5|Active | 2|Apache Felix Configuration Admin Service (1.6.0) > 6|Active | 2|Apache Felix Gogo Command (0.12.0) > 7|Active | 2|Apache Felix Gogo Runtime (0.10.0) > 8|Active | 2|Apache Felix Gogo Shell (0.10.0) > 9|Resolved | 2|Apache Felix Security Provider (2.2.0) > 10|Active | 2|Apache Felix Shell Service (1.4.3) > 11|Installed | 2|Apache Log4j 1.x Compatibility API (2.0.0.beta8) > 12|Active | 2|Apache Log4j API (2.0.0.beta8) > 13|Installed | 2|Apache Log4j Commons Logging Bridge (2.0.0.beta8) > 14|Installed | 2|Apache Log4j Core (2.0.0.beta8) > 15|Installed | 2|Apache Log4j SLF4J Binding (2.0.0.beta8) > 16|Active | 2|cal10n-api (0.7.4) > 17|Active | 2|Commons IO (2.4.0) > 18|Active | 2|Commons Lang (2.6.0) > 19|Active | 2|Data mapper for Jackson JSON processor (1.9.13) > 20|Active | 2|Jackson JSON processor (1.9.13) > 21|Active | 2|JSON.simple (1.1.1) > 22|Installed | 2|slf4j-api (1.5.11) > 23|Installed | 2|slf4j-ext (1.5.11) > Unresolved constraint in bundle org.apache.logging.log4j-slf4j-impl [15]: > Unable to resolve 15.0: missing requirement [15.0] osgi.wiring.package; > (osgi.wiring.package=org.slf4j) [caused by: Unable to resolve 22.0: missing > requirement [22.0] osgi.wiring.package; > (&(osgi.wiring.package=org.slf4j.impl)(version>=1.5.5))] > Unresolved constraint in bundle slf4j.api [22]: Unable to resolve 22.0: > missing requirement [22.0] osgi.wiring.package; > (&(osgi.wiring.package=org.slf4j.impl)(version>=1.5.5)) -- This message was sent by Atlassian JIRA (v6.1.5#6160) --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org