Extract integrations module into separate repository?

[odrotbohm]

In the last couple of days, I've played with the ByteBuddy based integration modules and made significant progress. The fundamental idea is that you can use jMolecules annotations and interfaces in your application and a build plugin would derive technology specific default annotations that might be needed to make the expressed concept work in that environment.

That said, while there is valuable code in those, I feel that we should free that code from the release cycle of jMolecules itself. The latter works almost like a specification and we have to be conservative about changes we introduce. Technology integration however is likely to iterate a lot faster and it's quite reasonable and expected to ship feature updates for those, even if the "spec" hasn't changed at all. In the reverse direction we probably don't want to ship "spec upgrades" for each bugfix in a technology specific integration.

I am wondering: shall we give this thing a dedicate name in the realm of our molecules domain or shall we just go with jmolecules-integration as repository name for now? I don't have an idea for the former yet but it might be the better option to avoid the confusion about jmolecules' artifacts' version numbers. A third option would be to move the code completely outside of the jmolecules realm and. That however creates friction and people have to look elsewhere to find the modules. The "canonical name but in the xMolecules umbrella / jmolecules domain space" sounds like the best compromise.

WDYT?

[odrotbohm]

Paging @StephanPirnbaum, @hschwentner for input.

[StephanPirnbaum]

Good points. The release cycle of jmolecules and the integrations should be indeed decoupled. Two remarks for that:

1. I would go for having independent release cycles even between the single integrations since they may evolve differently.
2. Maybe we should skip the integrations part in the naming and rather go for jmolecules-spring, jmolecules-jpa, ...

As for placing the project, I'd be completely fine to keep it in the organization and the jmolecules namespace. Decoupling this will in the end only confuse the users.

[odrotbohm]

Looks like we're largely on the same page. A few additional observations:

• Regarding point 2. I currently deliberately merged them together as the functionality they provide is very close, there is room for quite a bit of code sharing (as they all need to interact with the ByteBuddy API) and – most important of all – the plugins can be written in a way that they can accommodate the classpath arrangement of the target project. This allows to declare the jMolecules ByteBuddy plugin and the applied transformations reflect the technical arrangement of you project. This avoids having to adapt that configuration if you change the latter.
• It looks like the jmolecules-samples module would have to move out of the original repository as well as it refers to the integrations and we'd create a project cycle here. I'd move them to the integrations repository for now but would be happy to even separate them from that at a later stage if we decided that we need a place for samples that showcase potentially external integrations (jQassistant? 🙃 ) as well.

[odrotbohm]

I've filed and fixed #45 and xmolecules/jmolecules-integrations#1.