On 30 January 2017 at 13:58, Guillaume Smet <guillaume.s...@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 <yo...@hibernate.org> Hibernate NoORM Team _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
