Hi Stian,
thanks for the hint:
https://www.jfrog.com/blog/search-based-promotion/
I also found bintray when digging there:
https://bintray.com/
That is actually part of the social story I was thinking about. JFrog
should only lower barriers (e.g. OAuth login via Github, Google, etc.
instead of forcing bintray account).
Great that I found this. IMHO all maven artifact consumers should have a
look...
Best regards
Jörg
Am 03.05.2016 um 13:29 schrieb Stian Soiland-Reyes:
What you are describing is basically using "continuous" SNAPSHOT
dependencies.
Semantic Versioning is important for understanding API changes (and to
prevent such changes when not necessary). This could of course be computed
automatically, but there are also non-interface changes that a human needs
to indicate (e.g. change of .equals() javadoc)
It is very easy to set up Jenkins to build SNAPSHOT on any commit (e.g.
merge of Pull Request) and to deploy to the snapshot repository only if the
build and tests succeeded.
Approaches such as Nexus staging repositories and JFrog Artifactory's
release promotion can be used to add quality stamps ("stable versions") to
a separate repository.
On 1 May 2016 9:18 p.m., "Hohwiller, Jörg" <[email protected]> wrote:
Hi there,
I wanted to share some thoughs I had recently. Maven introduced a
revolution to the Java world and made a really big step for dependency and
build management. Open-Source projects are more productive with maven.
However, in the last years DevOps showed up and projects start to
continuously build releases in some cases with a fully automated build
pipeline.
When I look at open-source development around I see that we have great
infrastructure with github and pull-requests, etc.
But as a downside I also see slow and over-complex processes to get
something released (see e.g.
http://www.mojohaus.org/development/performing-a-release.html - wow that
is not really lean).
In order not to fingerpoint someone I will pick myself: I got a
pull-request from someone for servicedocgen-maven-plugin that I maintain at
mojohaus. I reviewed the PR and merged it. Unfortunately, I was very busy
then and did not create a release for two month now. It might not take that
much, but still too much. I want to question why do we need all this stuff
and the votings, etc.
So assume the following future vision for a maven project:
* When a pull request passed (travis, coveralls, etc.) and gets merged a
CI system automatically builds a release (no need to get PGP keys per
developer just one setup once for the project CI). The release simply gets
a timestamp as version-identifier (yyyyMMdd-hhmmss).
* Now besides the project being responsible for quality (by having good
tests and only accepting PRs after reasoable review) the community
(artifact users) could also help and do additional quality assurance.
Assume maven-central would become a collaborative platform where the users
of artifacts could vote and label artifact releases. Add comments, link CVE
or bug reports, etc. Vote +1/-1 on quality or security...
* Still the project releasing the artifacts could label releases and
associate minor/major release numbers to branches.
In such case however dependencies would not point to a version like
(4.2.1.RELEASE) but instead to 20160501-235901. In order to pick the right
technical version you would lookup the collaborative meta data.
I do not expect everybody to shout hurray to this rought idea. But I would
be happy if people can think about it and may combine it with other ideas
so we get even better in the future some day.
See also
https://dzone.com/articles/continuous-releasing-maven
https://devopsnet.com/2012/02/21/continuous-delivery-using-maven/
I would love to see that maven better supports flexible handling of the
version for the development view while it could simply stay as it is for
the consumer view. When I use variables in versions of POMs (and I do that
in every project today e.g. in combination with flatten-maven-plugin) I
always get warnings from Maven saying:
[WARNING] Some problems were encountered while building the effective
model for ...
[WARNING] 'version' contains an expression but should be a constant.
Still I see no clear picture how maven will adress these needs that
obviously many developer seem to have.
Issues like MNG-4161, MNG-624 and others were simply closed and not fixed.
After just seeing that and levaing an angry comment, I was about to cancel
this mail. However, I just decided to still send it but have little
expectation that it will make any sense...
Best regards
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
