[hibernate-dev] Hibernate Commons project

[Yoann Rodiere]

On 30 January 2017 at 13:58, Guillaume Smet <guillaume.smet at gmail.com>
 wrote:

> Note that the current version of hibernate-commons-annotations is
> org.hibernate.common (without the s at the end, not org.hibernate as Yoann
> stated it).
>
You're right. Wouldn't the simplest solution be to use the same groupId
(without a "s") in our new repo?



> Moving hibernate-commons-annotations is not such a good idea IMHO:
> - it's licensed under the LGPL so it would force us to use this license (or
> relicense it or having different licenses for the submodules but they are
> all bad ideas)
>

It sure seems complicated. But relicensing from LGPL to ASL2 may not be
such a big deal, since LGPL seems stricter than ASL2.
Couldn't we simply dual-license the whole repository under ASL2/LGPL? That
way, previous users wouldn't need to be aware of the change, and new users
could choose to comply with whichever suits them best.
Or does it require to release two packages for each submodule (one for each
license)?

Anyway... there are other reasons for not wanting to move the code to
another repo, so maybe we could just focus on having consistent group IDs
and let the code live in different places and have different maven parents.



> - we would release a new version of this module each time we want to
> upgrade the theme and I don't think it would be readable for consumers of
> this preexisting artifact.
>
> The latter point is what worries me about centralizing all the utils in the
> same repo with the same lifecycle.
>

We already got through this discussion, but let's sum it up:

   - With a common versioning, consuming projects will only have to take
   care to use the latest version available and use it for every common
   project they depend on.
   - With a common versioning, consuming projects will retain the ability
   to punctually use an older version for some subproject.

Sure, on the day we decide to break something, we'll have to bump the minor
or major for every "common" project, and it will give the false impression
that every such project has breaking changes. But we don't wan't to do that
often, and we'll probably won't have so many common projects anyway.

Having separate lifecycles/repos is probably cleaner, but it has its own
downsides:

   - Consuming poms will be less readable and less easily updated (one
   version per consumed common project).
   - Releasing the common projects will be more work.
   - Maintenance will be a bit harder (having multiple scattered repos to
   work on).
   - We'll run the risk of some common projects not being updated, in
   particular the version of their dependencies. Which could be avoided, or at
   least be less likely, if we centralize the dependency management in the
   parent pom of the common projects.

We can leave hibernate-common-annotations where it is, since it's
pre-existing and already critical in several of our projects, so its
maintenance is pretty much guaranteed.
But that kind of splitting seems dangerous for the new common projects,
because it makes it harder to maintain them, and there will be no full-time
maintainers. So we'd better not split these common projects any further,
and give these projects a chance to get regular maintenance...
Yoann Rodière <yoann at hibernate.org>
Hibernate NoORM Team