Hi Jörg,
On 5/1/16 10:18 PM, Hohwiller, Jörg 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.
Hm..Apache accepts pull request as well as MojoHaus
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).
Sorry to say that, but you haven't had the opportunity to see over
complex processes...
Simply make a release and open the VOTE for 3 Days (with lazy
census)..what is so complex about that? Yes you need to do some things:
make a release:
mvn -B release:prepare release:perform (gpg signing)
go to target/checkout
mvn site site:stage scm-publish:publish-scm
and send an email for VOTE and wait the result and than click on the
release button for publishing the artifacts to Central...
Hm..?
Furthermore if you don't like it than simply start a VOTE to change
that...What exactly is the problem herer?
I think that those three days are a good trade off between speed and the
options for developers to react cause not all developers are sitting in
front of the keyboards and just waiting someone will start a VOTE (they
are doing other things as well)...
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.
Because the community which means the Devs of MojoHaus have decided to
do so...(I'm a member of this as well)...
BTW: Clearly saying to discuss things here on Apache Maven Dev list
which belong to MojoHaus is not a good idea...
For apache the situation is a little bit different, cause there are some
other aspects important...(Like legals etc.)...but no one prevents you
from starting a release....
And yes sometimes mojohaus/apache maven devs are busy...so those are
open source projects ? I don't understand the remarks ?
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).
Using PGP etc. is very important in particular related to discussions
about trust and security...(of course only two aspects of that)...
You can remember a feew weeks ago as a single NPM developer could remove
artifacts from NPM which broke thousands of builds? This showed me that
the NPM people don't want to learn from the experiences of Maven central
already had....
Apart from that this would produces a release per commit which usually
not a good idea...CI/CD is the opportunity to make every state a release
...So furthermore you can use staging in repository managers like Nexus
to handle such things?
* 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.
This contradicts to the previous suggestions...
The thing you mentioned...the community is important and must give
feedback which is not always the case or not in the number we wished it
should be....
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...
This is more or less already done via the staging before going to Maven
Central...this is what the 72 hours VOTE times is for...
Why should they put that on central...the projects are responsible...
Yes you could imagine this ...but in real life i don't see it...cause
someone needs to maintain the platform Central in this way...who should
do that?
I have large doubts that a users will vote on Central for a release
...cause they are blaming things which do not work (see for example
StackOverFlow) but not filling a JIRA or at least mail on the mailing
list etc.
* Still the project releasing the artifacts could label releases and
associate minor/major release numbers to branches.
Why should we/others associate minor/major release numbers to branches?
Which advantages should that give ?
SemVer.org shows better ideas from the point of view what the artifacts
are doing for users......
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.
Why should i use something weird like 20160401-232211/20160401-232212
instead of 1.0.0/1.0.1 ? Where is the difference ? What does this mean?
I don't see advantages in comparsion to 1.0.0 / 1.0.1 more the contrary...
See also
https://dzone.com/articles/continuous-releasing-maven
If we are talking about CI/Cd than using release plugin might not be the
best choice...than using versions-maven-plugin etc. are better
alternatives..Furthermore automatic merging in Jenkins etc. can be done
as well...and creating a release can be done within a pipeline without
any problems...
https://devopsnet.com/2012/02/21/continuous-delivery-using-maven/
If you have taken a deeper look during the last months...there are
several activities to make the life cycle more flexible in different
ways...or to be more accurate to make the way open to change things...
For example:
https://issues.apache.org/jira/browse/MNG-5697
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.
Than you are using a wrong Maven version...starting from Maven 3.2.1 you
can use things like this in your version:
from the release notes:
http://maven.apache.org/docs/3.2.1/release-notes.html
<quote>
A simple change to prevent Maven from emitting warnings about versions
with property expressions. Allowed property expressions in versions
include ${revision}, ${changelist}, and ${sha1}. These properties can be
set externally, but eventually a mechanism will be created in Maven
where these properties can be injected in a standard way. For example
you may want to glean the current Git revision and inject that value
into ${sha1}. This is by no means a complete solution for continuous
delivery but is a step in the right direction.
</quote>
So you can simply set the version like:
<version>${revision}</version>
and than you do:
mvn -Drevision=1.0 deploy
or
mvn -Drevision=1.0-SNAPSHOT deploy
So where is the problem here?
Still I see no clear picture how maven will adress these needs that
obviously many developer seem to have.
What needs have many developers..?
We could start a discussions about that...and see if we get a clear
picture where the journey could go...
Issues like MNG-4161, MNG-624 and others were simply closed and not
fixed.
MNG-624 would lead to using a version range like JavaScript (NPM) does
etc. and based on the experience we had on version ranges....Furthermore
in the meantime you could use version ranges in parent with next Maven
Release (3.4.0) see
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
MNG-4161: This can more or less being solved by using
dependencyManagement in parent of the multi module build...Yes not the
optimal solution...but others would need changing the fundamentals of
Maven...and somethings needed to be changed in the pom modell..
Apart from that Benson Margulies has something via Extension: (User
Mailing list):
https://github.com/basis-technology-corp/auto-version-maven-extension
Kind regards
Karl Heinz
> 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]
