Hi Lennart,
bintray is about social aspects (rating and reviews of maven artifacts,
etc.).
Artifactory promotion could simplify your release process, but this may
depend on your setup (do you already have artifactory in place or
something else nexus/OSSRH?).
If you do not want to discuss visionary thoughts but simplify your build
and deployment today, have a look at your current continuous
integration. Do you have a dedicated jenkins or so? Simply automate your
deployment there using according jobs. So far this is the way to go.
Cheers
Jörg
Am 14.05.2016 um 17:33 schrieb Lennart Jörelid:
Hello all,
If I read things correctly, JFrog supplies free accounts for OSS projects
(typically Apache- or MojoHaus-based projects) for distribution on Bintray
central. Do you feel that this approach would complicate or simplify
automated release processes, Jörg? I am not certain I interpret your
thoughts in the last entry correctly.
2016-05-14 17:21 GMT+02:00 Hohwiller, Jörg <[email protected]>:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
