At work someone has committed a lot of changes into a project that are JDK 1.5 specific. Unfortunately, some of the production environment is still at Java 1.4, and so they have resorted to creating a dual branch consisting of a jdk1.4 version of /trunk.
This 1.4-branch is likely to have at least a one year lifetime, during which changes in trunk are merged into the jdk1.4 branch.
The question I was asked is if there was any best practices on dealing with Maven artifact ids in this situation? Obviously best practices would probably avoided getting us in this situation to begin with, but now that we are ... what to do?
We thought about giving the other branch a unique artifact id, such as "myapp-jdk14", while keeping every other identifier field (groupId, version) in sync. Any obvious downsides to doing this?
You could use a classifier for this:
classifier:
The classifier allows to distinguish artifacts that were built from the same POM but differ in their content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number.
As a motivation for this element, consider for example a project that offers an artifact targeting JRE 1.5 but at the same time also an artifact that still supports JRE 1.4. The first artifact could be equipped with the classifier jdk15 and the second one with jdk14 such that
clients can choose which one to use.
Source: http://maven.apache.org/pom.html
In fact, there are 2 commonly used solutions for this:
Adding some special, custom suffix to artifacts' names, like jdk14. For example, Bouncy Castle or SLF4j use this strategy.
Using classifiers, that are in fact designed for such tasks like distinguishing variations about same artifact (exactly your case).
What is interesting from my experience, first solution is really more often used despite the fact that the second one is officially suggested for such stuff.
Personally, I use first solution, but - to be honest - I don't see any strong advantage (or disadvantage) of one solution against the other one.
You can use your solution but I would suggest to have different version numbers.
For example:
1.0.X for JDK 1.4
1.1.X for JDK 1.5
That doesn't mean my suggestion is better than yours. Your solution has the advantage to see based on the artifactId which jdk it is for very obviously.
Related
I am setting up a versioning scheme for a greenfield project and read a lot about semver and the Maven convention. I'm using the Nexus OSS repo manager (v3.13.0).
It's hard to settle on an authoritative scheme when in comes to versioning but I believe in the power of convention. While the semver document (link above) seems well written I notice clashes with how Maven seems to treat version numbers. The goal is to settle on a scheme that gives good ordering. Semver mentions that the pre-release label (the part that follows Major.Minor.Patch-) may have dot-separated segments, some of which are numeric and are to be compared as such, so one should not have zero padding such as RC.09. In practice, however, Maven (oracle link above, but is that authoritative?) treats everything after the first dash as one alphanumeric field, hence, one should use RC09 and RC10.
My question is, use zero-padding or not? I would love to adhere to semver, but I also need something that works.
The added complexity is I'm not using Maven, but Gradle! But does that even matter? --> where is version ordering computed, in the build system or in the repo manager (Nexus in my case). See what Nexus says on the topic - BUT, it references Maven, so I'm not sure if that applies to Gradle clients (or rather, to the maven-publish plug-in). Then again, Gradle tries to mimic Maven when it comes to publishing standards. It's a mess!
I have a maven multi-module project with more than 6 children modules in it. If a team of 3 is working in parallel taking 2 sub-modules each as their task, then how to increase the version number.
whereas I am following Major.minor.patch-meta format for version numbering in release cycles.
Project A
-- sub-module-assembler
pom.xml
-- sub-module-1
-sub-sub-module-1 pom.xml
-sub-sub-module-2 pom.xml
pom.xml
-- sub-module-2
-sub-sub-module-1 pom.xml
-sub-sub-module-2 pom.xml
pom.xml
-- sub-module-3
-sub-sub-module-1 pom.xml
-sub-sub-module-2 pom.xml
pom.xml
-- sub-module-4
-sub-sub-module-1 pom.xml
-sub-sub-module-2 pom.xml
pom.xml
-- sub-module-5
-sub-sub-module-1 pom.xml
-sub-sub-module-2 pom.xml
pom.xml
-- sub-module-6
-sub-sub-module-1 pom.xml
-sub-sub-module-2 pom.xml
pom.xml
--pom.xml
Exact usage of incrementing and decrementing version numbers in parallel programming, Whereas the key thing to be notified in this is some sub-modules in that project totally depends upon some other sub-module, if that is the case then how to version number exactly while the development goes parallel as well in certain order ?
I am not clear about the below but is this right way of version numbering
Should i need to do meta release in case of bug fix e.g alpha, beta , gamma etc.,
Should i need to do a patch release in the case of completion of a feature[sub-sub-module-x] in a sub-module whereas i am using second level+ sub-modules e.g 0.1.1-alpha, 0.1.2-alpha etc.,
Should i need to do a minor release in the case of completion of a sub-module e.g 0.2.0-alpha , 0.2.0-RC etc.,.
So after integrating all the RC's 0.2.0-RC + 0.3.0-RC + 0.4.0-RC etc should i need to do a major release as 1.0.0-RTM etc.,
So understanding the above flow is bit cofusing ..
Is there any way to automate the build numbering in a project so as to maintain clear build release numbers. Please provide a solution.
Thanks
I suspect there will be no answer for all versioning strategies. But let me try some hints that may help you choosing a strategy that is appropriate for your situation.
The project looks rather big. The first grouping I would do is by responsibility. Are there modules that are restricted to a certain development team? Or is the whole thing maintained "all-in-one"? Hopefully you are able to split it up a bit.
Once you know about module(s) responsibilities you need to define some life-cycle. How and how often is a release (or bugfix, patch) created and by whom? If everyone follows the same rhythm you can share one version and release the whole tree. But usually this is not the case in larger projects. It also introduces side effects during development if a lot of people share one version.
If you do not plan to release the complete tree all at once you may split it more consequently. You can still use a common parent pom.xml (but one with a released version).
I would define one version for modules in a parent pom.xml and inherit it. So no individual version in submodules. Furthermore every team that depends on other modules should not use SNAPSHOT dependencies to work of other teams. They may only use a released version (be it BETA or RC1). It is important to keep builds reproducible. E.g.: "no snapshot dependencies to artifacts you are not in charge of (you control what changes and when)"
As for the versioning itself: in doubt the simpler option may be better. All the meta information may only confuse about the actual state?
What may also be of some use is to draw a deployment pipeline: what module comes first, which ones depend on it and so forth. The amount of changes in one module define how the version changes (major, minor, patch change). If those changes do not propagate across modules (the API stays stable, which is your goal) the next module may only do patch releases.
If you have not yet released anything, plan ahead. Every iteration is usually an API change (therefore it actually would be a major release). That would lead to version 18.0.0 to be released (after 18 iterations). So usually the minor version is used to indicate iterations and patch versions indicate some fixes to stabilize that release. So major versions are chosen more from a marketing aspect than from a technical one.
It also depends somewhat on the type of software you build (a product, an in house-solution, some additional service for your landscape). Products have a much clearer versioning, they usually use the META part to indicate iterations and the major.minor.patch numbers to indicate what is going on. That strategy ("indicate what changes to expect") may help for what you are doing as well?
So hopefully this did not raise more questions than you had at the beginning :)
What is the best place to put platform/architecture info?
My temptation is to use the version field by prefixing the architecture designator to the version, since that would appear to be the simplest to wildcard and also will prevent accidentally mixing and matching of different platforms:
version = <architecture>-<version>[-<branch>]
Alternatively, one could append the architecture to the artifact id:
artifactId = <name>-<architecture>
Both ways lead to the same artifact name.
What do other people do, and why?
If you are developing for different architectures independently, any of these solutions may be good. You may have a situation, though, where the version number would be the same across architectures. This may typically be the case if you're building for the different architectures off of the same code base, e.g. either you have an artifact that is built into different distributables, or you have different artifacts that depend on the same common core. In that case, you would not want to pollute the version number with the architecture or branch information, as it renders Maven unable to treat it as the same version. The proposed solution for this is the use of classifiers. As per the Maven POM Reference:
classifier:
The classifier allows to distinguish artifacts that were
built from the same POM but differ in their content. It is some
optional and arbitrary string that - if present - is appended to the
artifact name just after the version number.
As a motivation for this element, consider for example a project that
offers an artifact targeting JRE 1.5 but at the same time also an
artifact that still supports JRE 1.4. The first artifact could be
equipped with the classifier jdk15 and the second one with jdk14 such
that clients can choose which one to use.
A problem that relates to basic maven concepts:
Once released I would like to have a guarantee that the project build is fully reproducible. So all project and plugin dependencies, including transitive one, should be always resolved the same way.
Unfortunately it is not the case, if dependencies are expressed in terms of version ranges. It can happen that even though direct dependencies of a project are set (using versions:use-releases), the transitive dependencies can still be resolved in some other way in the future.
How to address the problem? Is there a known solution?
I was thinking (just an idea), about creating a plugin, which on release time would dump all dependencies of the project to a separate file, and then once building in the future, the dependencies read from the file would take precedence over the standard way maven uses to resolve dependencies. But I'm afraid that there is no plugin api for that. So it would require some hacking, which I would like to avoid. Is there another way?
Thanks,
Lukasz
Freeze artifacts versions using <dependencyManagement>. Even if you don't use version ranges (as you said), but rather 3rd party libs (your dependencies) do, your <dependencyManagement> will have higher priority in specifying version of any artifacts.
The simple solution is: Do not use version-ranges. This is bad practice cause it will result in the described problems.
For a project with a large number of Maven artifacts (both internally generated as well as external ones), how does one go about automating the releasing of the internally controlled artifacts as part of an overall product release.
Things to be aware of about this question, we use Jenkins and the Maven release plugin. So the operation of releasing a single artifact is automated (albeit the operation to kick-start the process is manual). However the process of releasing all the changed artefacts over the course of a release is not automated (i.e. one has to manually kick-start the release of each artifact). Part of the problem is that almost nothing is released until the end of the release, prior to that everything remains in SHAPSHOT. We have a huge number of components as well as numerous applications/services (over 30) which rely on the plethora of components. So it is not just the case of picking a component and releasing, there are release dependency hierarchies that must be followed (i.e. start at the bottom releasing components that do not use other components and then work your way up until all the applications/services are released).
It is also worth noting that we use two common parent poms which, for the most part, control the versions of the external artifact dependencies and the internal component dependencies. Some pom files for components and applications may override this, but this is (or should be) an exception and should be for a good, but temporary, reason. So when an internal artifact is released, the version in the corresponding parent dependency pom should also be updated.
The product has a release number (of course), however the various pom files technically do not share this version number. While this is not strictly true, the idea as that when parts of the software are set to end-of-life, they will not be updated in the future, thus while a limited number of artifact versions match the product's version at present, this will eventually not be the case.
Any thoughts on ways to get this process automated would be greatly appreciated. Also if you feel what I have described seems to be a crazy way to manage the software, then please provide a comment. Thank you.
You might be able to make use of the Maven Versions plugin which can help formalise versions for projects.
For example, the use-next-releases goal may allow you to release the lowest level of project and then more rapidly bring those released versions into their dependencies.
There may also be scope to use the use-next-versions goal if you fancy releasing components as necessary and simply bring your projects to the "latest" version thats been formally released.