SingingBush commented on PR #202: URL: https://github.com/apache/commons-beanutils/pull/202#issuecomment-1899008711
potentially. It would make sense if the module name and the OSGI bundle match up. I suspect the cause of the [BEANUTILS-523](https://issues.apache.org/jira/browse/BEANUTILS-523) bug may have been down to the maven-bundle-plugin defaulting to: ```xml <Bundle-SymbolicName> ${pom.groupId}.${pom.artifactId} </Bundle-SymbolicName> ``` perhaps there was a change in plugin version or something in parent pom that differed between the 19.3 and 1.9.4 release. After making the change I checked the manifest to make sure that the symbolic name was as expected but I didn't go as far as to check anything else about the OSGI info. It's perhaps worth comparing MANIFEST.MF files in the last few releases and current builds of master. Due to the fact that the incorrect symbolic name broke osgi for the 1.9.4 release, it's worth branching off that tag, applying any required changes for OSGI (make sure to use **org.apache.commons.beanutils**) and releasing as 1.9.5. Someone with more OSGI experience than me should help with that (I'm more interested in JPMS than OSGI). Since the 1.9.4 release the codebase, it seems that *org.apache.commons.beanutils2* is the way to go. At least that's what's been set for the module name. If that's correct it probably means the symbolic name should be the same and new versions released as 2.*. tbh, I never liked this thing Apache does of adding numbers to the end of artifactId's. The maven releases have numbers anyway, just use semver. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
