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] > > -- -- +==============================+ | Bästa hälsningar, | [sw. "Best regards"] | | Lennart Jörelid | EAI Architect & Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: [email protected] | URL: www.jguru.se | Phone | (skype): jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==============================+
