If you are using BMP, that's fair ;) It's just a proposal to use the statistics to evaluate what is actually used (using Nexus statistics).
Your list looks reasonable to me and I agree. If the list includes "priority", I would put proxy before blueprint (as proxy is used by blueprint :)). It sounds good for Apache POM. I will do a pass anyway. Thanks! Regards JB On Thu, Mar 6, 2025 at 8:12 PM Dominik Przybysz <alien11...@apache.org> wrote: > > 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é 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
