The first list of all modules is ordered but should not. Next lists are unordered :)
Blueprint relies on proxy and many other modules have sth.blueprint artifact e.g. jmx, jpa, transaction :) pt., 7 mar 2025 o 14:27 Jean-Baptiste Onofré <j...@nanthrax.net> napisał(a): > 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 > -- Regards, Dominik Przybysz
