Am 11/30/16 um 19:18 schrieb Florian Schätz: >> A library project to be >> shared between multiple applications each having its own release-cycle >> should not be part of a multi-module project used to build such an >> application and should be an independent project with its own >> release-cycle. > > While this is of course a good idea, especially when starting to create > new applications, the library projects will grow with the applications > and not independently of them. We cannot start by first investing months > to create the perfect will-work-for-ten-years library and only then > start coding the application that will, in the first months, only use > 10% of all these features. So, realistically, during a development > cycle, both the application and the library will grow... (which doesn't > mean that we cannot separate them)
That's what I was referring to with "inheritance vs. aggregation". In a multi-module project you get versioning "for free" by using the release:prepare release:perform goals. Maintaining the build is not a one time task. You adjust things over time until you get things structured the way it fits your situation perfectly. To not be trapped later, you need to carefully decide the artifact coordinates in use and the way versions will be assigned. If a shared library has been part of a multi-module project together with an application, extracting it later should not have an impact on the rest of the build. It should carry it's own version from day one. It should carry it's own coordinate namespace from day one. Once in a multi-module project, you will soon start to inherit groupId and version. That can lead to having to update each and every application POM when extracting that library later. Starting some application from scatch today, keep in mind you will re-structure your build over time until things have been sorted out. If you know from day one that a specific module/project will have it's own release-cycle sooner or later, be prepared for that from day one. Regards, -- Christian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
