Hi,
On 04/05/17 19:53, Eric Benzacar wrote:
I've read through Karl's blog (http://blog.soebes.de/blog/
2017/04/02/maven-pom-files-without-a-version-in-it/), and while I
understand the approach, there is still one critical issue that bothers
me. I think this actually reopens an old thread that circulated on this
list a few months ago, but it related to the Idempotence of a pom file.
From my perspective/view a pom file should be idempotent. That is every
single build of a given NON-SNAPSHOT pom file should finish with the same
build. But by moving a release number or version number outside of the
pom, it eliminates this need. Furthermore, from a traceability
perspective, my source control can no longer show me precisely version was
being built/developed at any given time.
By leveraging the mvn.config file, I'm a little further down the path, but
none the less, the value can be overridden at build time with a completely
different value. Consequently, I can still not be 100% confident that a
pom delivered a particular version.
I'm still not 100% sure of the best approach going forward, but I'm
thinking that something like the version-plugin being able to manipulate a
revision property that can then be committed as part of the pom would be
the best of both approaches. In that way, my developers can fix the
version number, but my build system can manipulate the revision property.
Does anyone know if there is a plugin that will allow for that?
Ok let me going into your concerns here.
First we are talking about a NON-SNAPSHOT Build or in other words a
release build.
If you are using this you should be aware of some parts:
First if you make a release your release process must create a tag in
your version control with this state of your source code. Furthermore
you should bake informations like the revision number or sha1 of your
version control system into your resulting artifacts (configuration of
maven-jar, maven-war etc.) and a branch name is also helpful which I
always encourage independent of the usage of this here. This makes
traceability more easier...
The problem with this approach is that if you simply set the version
number via properties to a release version and do a simple `mvn deploy`
which in result produces a release version in my repository.
If I have baked in the above information you can track back from the
resulting artifact to the state in your version control....which from
point of view is the real needed part...
This will lack the tag which has been created in the previously
described release setup.
So based on some Continuous Delivery setups in theses days the created
tag is not that essential. It is only essential to create a new artifact
very fast without some run of versions-plugin or bash/script vodoo to
only change the version number in all pom files and produce one, two or
three (release plugin) checkins which only contain information about the
changed versions in pom file nothing more interesting...So if you are
working with branches the version numbers in pom files are always a pain
cause they produce always conflicts....
Furthermore based on the above described scenario the question comes
into my mind: Is the version control the righ tool/location to answer
this question? In the meantime I tend to say no. The artifact repository
(Nexus for example) is the better tool/location to answer this
question...but this a very controversy thing...
So going to the next point:
> Consequently, I can still not be 100% confident that a
> pom delivered a particular version.
If you make the release setup as I describe you can...The point is you
need to trust your own setups or implementations for such release
scenario...
Furthermore if you think about this statement in consequence this means
you are not allowed to use any version ranges in none of your pom files
cause this will result in more complicated problems than only not
knowing the version number from your version control...
And finally a thing which is important to know:
The separation between the "build pom" and the "consumer pom" which is
implicitly done by this. This means the "build pom" is checked into
version control but not the resulting "consumer pom" which is only
intended for consumers of your artifacts and only being available in the
destination artifact repository which has been built by a technical
process. This is the same as we compile a Java class cause we only have
as a result the compiled class file in our jar file but not the source
files...
You have the pom which contains the properties with the versions parts
like revision,changelist and sha1 and the resulting pom file which is
installed into the repository (see also flatten-maven-plugin)...or just
define the property(ies) via command line...
This is one of the first very small step into the direction to separate
this explicitly cause If the Maven project will go further this is a
necessary step and to make other changes possible (Changing the pom
model etc.) but this is complete different discussions.
What you mentioned about have the versions-maven-plugin is correct and
it needed to be improved to let the plugin only change the properties
like revision,changelist,sha1 to be changed is something which I already
thougt about which would mean only to change a single pom file (usually
the project parent in a multi module build).....
After thinking about the "Idempotence" part I came to the conclusion
that this is given, cause the process of building the pom file will
result in the same artifact. The only difference I can see is that I
might name it differently which means I just put a different "label"
(Version) on it (or better we interpret that part of the filename as a
version)...
Kind regards
Karl Heinz Marbaise
Thanks,
Eric
On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <t.bro...@gmail.com> wrote:
How about everybody read their mail?
(see below)
On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <ctrue...@wisc.edu> wrote:
Hi Dan, Karl & everyone,
See Karl's Blog
Link, please?
[…]
On 03/05/17 20:39, Dan Tran wrote:
Hi
I have been experimenting with suggestion from Karl [1] with small
multi
module maven project.
[…]
[1]
http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
t-a-version-in-it/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
