Hi, I am really far from deprecating BMP. Maybe I am biased but that's the reason why I started contributing to Aries :) The world around is generating boring XML files (Declarative Services) or removing them at all (Spring). The plugin made building bundles containg more than few beans really easy and maintainable, especially enabling moving classes without mirroring changes in XML.
About application module - I have seen only some mentions about IBM implementation and Aries implementation is the only one open source. But I haven't checked if our implementation follows everything described in https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.application.html - I have never had a chance or need to use it in my projects. If we are able to gather real fetch statistics from the nexus it would be great, but from my observations nexus or maven central repo is only showing the dependencies that are also public. When artifacts are used in private projects or internal nexuses then we don't have such information. BTW 1 - if we trust the statistics: - blueprint annotations for plugin are used 58 times https://mvnrepository.com/artifact/org.apache.aries.blueprint/blueprint-maven-plugin-annotation - the plugin itself is used 0 times https://mvnrepository.com/artifact/org.apache.aries.blueprint/blueprint-maven-plugin and it cannot be true since annotations without the plugin are just useless. BTW 2 - there is a karaf example which declares annotations but does not use it :) - https://github.com/apache/karaf/blob/main/examples/karaf-blueprint-example/karaf-blueprint-example-provider/pom.xml#L41-L45 We can have a list: 1. application 2. async 3. blueprint 4. blueprint-maven-plugin 5. eba-maven-plugin 6. esa-ant-task 7. esa-maven-plugin 8. jmx 9. jndi 10. jpa (separate repo aries-jpa, only marking directory in main repo) 11. parent 12. proxy 13. pushstream 14. quiesce 15. samples 16. sandbox 17. spi-fly 18. subsystem 19. testsupport 20. transaction 21. tutorials 22. tx-control (separate repo aries-tx-control, only marking directory in main repo) 23. util 24. versioning 25. web 26. aries-cdi (separate repo) 27. aries-component-dsl (separate repo) 28. aries-containers (separate repo) 29. aries-jax-rs-whiteboard (separate repo) 30. aries-rsa (separate repo) 31. aries-typedevent (separate repo) @Jean-Baptiste Onofré <j...@nanthrax.net> do you think we are able to gather meaningful statistics for all the modules here? or should we go deeper and thing about each artifact internally? I see the most value (because of usage or haveing recent changes) in keeping - blueprint - blueprint-maven-plugin - jmx - jpa - parent - proxy - samples - spi-fly - transaction - tx-control - aries-jax-rs-whiteboard - aries-rsa - aries-typedevent Some of the artifacts are using the others exmaple we heavily use internally so probably we should keep them too: - testsupport - util - versioning - quiesce (in blueprint) BTW 3 - there is a script to visualize dependencies inside directories - https://github.com/apache/aries?tab=readme-ov-file#submodule-dependencies-visualization I don't know how many people will take a look at this long email - maybe instead I can send an email with voting for each module? WDYT? When we detect that there are some modules that we think we can deprecate then we can also ask our u...@aries.apache.org if there is anyone willing to maintain such modules to gather more possible contributors. If you are reading this email and you are not the aries member but want to help that you can say it here too :) BTW 4 - apache parent pom is going to be released in the upcoming weeks - we can wait for it before starting our releases czw., 6 mar 2025 o 10:53 Jean-Baptiste Onofré <j...@nanthrax.net> napisał(a): > Hi Dominik > > Thanks for starting this discussion ! > > About Blueprint Maven Plugin, do we really need to maintain it still ? > I'm not sure it's heavily used, so maybe makes sense to "deprecate" > it. > I have the same comment for Application, worth to maintain it ? > Imho, we should do a review on the "active/used" modules and clean > this up (we can take a look on the Nexus stats for instance). > > About Java 11,17, 21, yes, I will take a look as it's a blocker for > blueprint. > > Regards > JB > > On Wed, Mar 5, 2025 at 10:15 PM Dominik Przybysz <alien11...@apache.org> > wrote: > > > > Hi team, > > > > I would like to share the next steps I am planning for the modules in the > > Apache Aries main repository. > > > > 1. > > > > *Move Blueprint Maven Plugin (BMP)* to a top-level directory to align > > with our other Maven plugins. BMP is currently inside the Blueprint > > directory, but apart from generating Blueprint bundles, it doesn't > have > > much in common with Blueprint itself. > > 2. > > > > *Remove BMP support for Spring and Pax CDI annotations*, but support > may > > still be enabled by adding dependencies with annotation handlers in > those > > subprojects. I had planned this from the early stages of my work in > the > > plugin, and there are now better annotations available to support > > Blueprint-specific elements like Service, Reference, and > > ReferenceListener. This is a breaking change, so a release of version > > 2.x is necessary. We should do this not only because of this change > but > > also because the minimum Java version is now 8. > > 3. > > > > *Add support for Jakarta Inject and Transaction annotations* in BMP. > > These annotations are now the standard, and we should have built-in > support > > for them. > > 4. > > > > *Use BMP in samples and tutorials* – let's show how easy it can be to > > use the plugin to generate Blueprint XML files. > > > > *Release Plan:* > > > > 5. > > > > I would like to start releasing the changes of our artifacts, with the > > first one being the parent pom. It would be great to do this after the > > Apache parent POM is released, but this is not blocking. I propose > version > > 3.0.0 since Java 8 is now the minimum required Java version. The bump > in > > the minimum Java version will also require a major version bump for > all > > artifacts using this POM. > > 6. > > > > The versioning plugin now works with the LTS Java versions, so I think > > the artifacts from the versioning module may be released next. > > 7. > > > > The next release would be BMP, along with all the satellite artifacts > > (annotations and handlers). > > 8. > > > > The web module could also be released. > > > > *Blockers:* > > > > 9. > > > > I would like to continue working on adding support for Java 11, 17, > and > > 21 in other modules. I am especially waiting for a review of the proxy > > module updates: PR #414 <https://github.com/apache/aries/pull/414> – > > (especially @jbonofre, please take a look). Merging this PR should > unblock > > work in the Blueprint and Subsystem modules. > > 10. > > > > The Application module needs significant attention since its > > implementation uses org.osgi.service.framework from Eclipse Equinox, > > which is available only in versions 3.5 to 3.7 (bug report > > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=345790>). The proper > > replacement should be found, and there will likely be many changes > needed > > to make the Application module Eclipse-independent and ready for the > > current LTS Java versions. > > > > > > -- > > Pozdrawiam / Regards, > > Dominik Przybysz > -- Regards, Dominik Przybysz
