Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
From: domi <domi@fortysix.ch>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_CC3C989F-14CC-4E56-B334-F897A627D9B1"
Message-Id: <E98EFBA8-3373-46FA-98BF-E3CEDC23F0F4@fortysix.ch>
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
Subject: Re: Inclusion of Maven on SDKMAN
Date: Mon, 14 Dec 2015 08:15:23 +0100
References: 
 <CAC5VgrdGwY26tvWwHNPLuGQsbpF4jHvfnvXVgpHiAX0tgaV=Sw@mail.gmail.com>
 <528A77E9-B277-4726-AA64-5B7AA8EEDED6@fortysix.ch>
 <CAC5VgreZ7gtJOD+-iOGq1b5zczEjJ6xJ=O7L-EoeUBQ9QgY3sA@mail.gmail.com>
 <11789599.f5RFZhXq8K@herve-desktop>
 <CAC5Vgre7QsvM0Ss5JCWyTkCsFQt7-okbRXHyhh-dCpdmd9ij9A@mail.gmail.com>
To: Maven Developers List <dev@maven.apache.org>
In-Reply-To: 
 <CAC5Vgre7QsvM0Ss5JCWyTkCsFQt7-okbRXHyhh-dCpdmd9ij9A@mail.gmail.com>

--Apple-Mail=_CC3C989F-14CC-4E56-B334-F897A627D9B1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Marco,

I think there is a misunderstanding - no-one is proposing that you =
should create another CI-Server (like Jenkins)=E2=80=A6
All we are saying is, that the backend/server site of SDKMAN should have =
a crawler component which does a daily check of a page like this:
http://mirror.switch.ch/mirror/apache/dist/maven/maven-3/ =
<http://mirror.switch.ch/mirror/apache/dist/maven/maven-3/>=20
To check if there is a new version of Maven available, if yes, then it =
updates/adds records in the SDKMAN DB as it=E2=80=99s required - thats =
it.
This is the concept Jenkins uses to allow automatic download of =
different version for the tools it supports

/Domi


> On 13 Dec 2015, at 20:35, Marco Vermeulen <vermeulen.mp@gmail.com> =
wrote:
>=20
> Hi Herv=C3=A9,
>=20
> Apologies for the delayed reply.
>=20
> Regarding Jenkins and SDKMAN, they really operate very differently.
> Unfortunately, I currently have no plans to make SDKMAN more like =
Jenkins.
> Jenkins is a CI server, and SDKMAN is a package manager.
>=20
> SDKMAN has a client side tool (bash CLI) that calls to a serverside =
REST
> API. This API tells the client side:
>=20
> a) what versions are available for a given candidate [1]
> b) what the current stable version is for that candidate [2]
>=20
> These are simple API calls that you could use too as part of your =
release.
> Doing these API calls could be done with curl, and you need not =
install
> SDKMAN to get this information. The API is free to use, and open, as =
the
> rest of SDKMAN is.
>=20
> Of course, these API calls are not to be confused with those exposed =
in the
> Vendor API that parties like yourselves will use to perform their =
releases
> on our platform.
>=20
> Regarding API keys for the Vendor API, these are issued on an
> organisational level at the moment, each vendor receiving a key/token =
pair
> to use as part of their release process.
>=20
> Hope this answers most of your questions above.
>=20
> Cheers,
> Marco.
>=20
> [1] http://api.sdkman.io/candidates/maven
> [2] http://api.sdkman.io/candidates/maven/default
>=20
>=20
>=20
>=20
> On Wed, 9 Dec 2015 at 15:37 Herv=C3=A9 BOUTEMY <herve.boutemy@free.fr> =
wrote:
>=20
>> yes, Jenkins and SDKMAN are not the same beasts, but they share some =
common
>> ground: ideas from one may need to be adjusted.
>>=20
>> IIUC, discovery of available Maven versions could work on SDKMAN =
exactly
>> like
>> Jenkins
>> Then there is the choice on default: for Maven, we publish the =
recommended
>> version [1], and it is done with "currentStableVersion" property in =
maven-
>> site's pom [2]
>> Then extraction of this piece of information would be automatable =
also (and
>> AFAIK, Jenkins does not take this "default" info into account =
currently)
>>=20
>> WDYT?
>>=20
>> Regards,
>>=20
>> Herv=C3=A9
>>=20
>>=20
>> [1] http://maven.apache.org/download.cgi
>>=20
>> [2]
>>=20
>> =
https://svn.apache.org/viewvc/maven/site/trunk/pom.xml?revision=3DHEAD&vie=
w=3Dmarkup
>>=20
>> Le lundi 7 d=C3=A9cembre 2015 09:01:43 Marco Vermeulen a =C3=A9crit :
>>> Most of the big projects want to do this. It puts them in control of
>>> releasing and announcing their artifacts. FWIW, this is the model =
that
>>> Gradle, Groovy, Grails, Ceylon and many others are following.
>>>=20
>>> Also, comparing sdkman to Jenkins is like comparing apples to =
oranges.
>>>=20
>>> Cheers,
>>> Marco.
>>>=20
>>> On Mon, 7 Dec 2015 at 08:57, domi <domi@fortysix.ch> wrote:
>>>> FWIW: I would try to free projects from having to do this - e.g. =
SDKMAN
>>>> could crawl for new versions like Jenkins and Hudson are doing it =
[1].
>>>> This way you don=E2=80=99t rely on anyone doing this and you get =
all versions
>>>> integrated for free.
>>>> /Domi
>>>>=20
>>>> [1]
>> =
https://wiki.jenkins-ci.org/display/JENKINS/Adding+tool+auto-installer
>>>>=20
>>>>> On 07 Dec 2015, at 08:23, Marco Vermeulen <vermeulen.mp@gmail.com>
>>>>=20
>>>> wrote:
>>>>> Hi all,
>>>>>=20
>>>>> Do you have any feedback on the above?
>>>>>=20
>>>>> Regards,
>>>>> Marco.
>>>>> On Sun, 29 Nov 2015 at 22:01, Marco Vermeulen <
>> vermeulen.mp@gmail.com>
>>>>>=20
>>>>> wrote:
>>>>>> Hi Herv=C3=A9,
>>>>>>=20
>>>>>> You needn't worry about Maven integration into sdkman, as it's
>> built in
>>>>=20
>>>> a
>>>>=20
>>>>>> completely SDK agnostic way. Adding a new install candidate (like
>>>>>> Maven)
>>>>>> was a single row in our database. All subsequent interactions for
>> you
>>>>>> (like releasing new versions) happen through the Vendor API.
>>>>>>=20
>>>>>> In total, you would need to make 3 API calls to our Vendor API:
>>>>>> 1) Release your new version on the sdkman platform
>>>>>> 2) Set the new version as the default/stable version
>>>>>> 3) Announce the release on the sdkman platform (and hence our
>> twitter
>>>>=20
>>>> feed)
>>>>=20
>>>>>> In order to make these calls, you will need a key/token pair that =
I
>>>>>> will
>>>>>> issue the person who agrees to taking this on. I will send the
>>>>>> key/token
>>>>>> pair in a pgp encrypted email, preferably using a service such as
>>>>>> keybase.io
>>>>>>=20
>>>>>> As mentioned before, we have a maven plugin that performs all =
these
>> api
>>>>>> calls on your behalf, making it easy to tie into your release =
build:
>>>>>> https://github.com/sdkman/sdkman-maven-plugin
>>>>>>=20
>>>>>> Hope this all makes sense now,
>>>>>> Cheers,
>>>>>> Marco.
>>>>>>=20
>>>>>>=20
>>>>>> On Sun, 29 Nov 2015 at 15:21 Herv=C3=A9 BOUTEMY =
<herve.boutemy@free.fr>
>>>>=20
>>>> wrote:
>>>>>>> Hi Marco,
>>>>>>>=20
>>>>>>> IIUC, you'll provide a key for the Maven PMC to announce new
>> versions
>>>>=20
>>>> of
>>>>=20
>>>>>>> Maven
>>>>>>> through Vendors API [1]
>>>>>>>=20
>>>>>>> I still don't see what is currently in the db for Maven
>>>>>>>=20
>>>>>>> And I don't see how Maven is integrated.
>>>>>>>=20
>>>>>>> Regards,
>>>>>>>=20
>>>>>>> Herv=C3=A9
>>>>>>>=20
>>>>>>> [1] http://sdkman.io/vendors.html
>>>>>>>=20
>>>>>>> Le dimanche 29 novembre 2015 09:37:41 Marco Vermeulen a =C3=A9crit=
 :
>>>>>>>> Thanks for the reply Herv=C3=A9.
>>>>>>>>=20
>>>>>>>> This is all explained in the links I posted. sdkman acts as a
>> broker,
>>>>>>>> pointing to wherever the binary is hosted. Installing maven is =
as
>>>>>>>=20
>>>>>>> simple as
>>>>>>>=20
>>>>>>>> entering 'sdk install maven' for latest stable, or 'sdk install
>> maven
>>>>>>>> x.y.z' for a particular version. This will do a curl to our
>> central
>>>>>>>=20
>>>>>>> server
>>>>>>>=20
>>>>>>>> which will do a redirect to your hosted binary.
>>>>>>>>=20
>>>>>>>> Of course, sdkman is backed by a db that needs to be populated,
>>>>>>>=20
>>>>>>> preferably
>>>>>>>=20
>>>>>>>> by the owner of the sdk. In the interim I've added the latest
>>>>>>>> versions
>>>>>>>> myself, but it would be great if this is driven by the maven =
team
>>>>>>>> themselves.
>>>>>>>>=20
>>>>>>>> Hope this clarifies things a bit more.
>>>>>>>>=20
>>>>>>>> On Sun, 29 Nov 2015 at 00:56, Herv=C3=A9 BOUTEMY <
>> herve.boutemy@free.fr>
>>>>>>>=20
>>>>>>> wrote:
>>>>>>>>> IIUC, Maven is now supported by sdkman
>>>>>>>>> But I still don't see how/where
>>>>>>>>>=20
>>>>>>>>> Where is the Maven support for SDKMAN hosted, that we could
>>>>>>>=20
>>>>>>> contribute to?
>>>>>>>=20
>>>>>>>>> Regards,
>>>>>>>>>=20
>>>>>>>>> Herv=C3=A9
>>>>>>>>>=20
>>>>>>>>> Notice: old issue about this is
>>>>>>>>> https://issues.apache.org/jira/browse/MNG-5749
>>>>>>>>>=20
>>>>>>>>> Le vendredi 27 novembre 2015 08:07:33 Marco Vermeulen a =C3=A9cr=
it :
>>>>>>>>>> Hi all,
>>>>>>>>>>=20
>>>>>>>>>> I originally sent this directly to jvanzyl, but he =
recommended I
>>>>>>>=20
>>>>>>> post
>>>>>>>=20
>>>>>>>>> this
>>>>>>>>>=20
>>>>>>>>>> to the dev forum.
>>>>>>>>>>=20
>>>>>>>>>> A word of introduction, I am Marco Vermeulen, the project =
lead
>> of
>>>>>>>>>> SDKMAN,
>>>>>>>>>> the Software Development Kit manager (formerly GVM). We are
>>>>>>>=20
>>>>>>> responsible
>>>>>>>=20
>>>>>>>>> for
>>>>>>>>>=20
>>>>>>>>>> providing a free service that helps in distribution of SDKs, =
and
>>>>>>>=20
>>>>>>> have
>>>>>>>=20
>>>>>>>>>> recently had several requests for Maven as install candidate
>> coming
>>>>>>>>>=20
>>>>>>>>> through.
>>>>>>>>>=20
>>>>>>>>>> I recently added Maven to SDKMAN, but wanted to know if the
>> Maven
>>>>>>>=20
>>>>>>> team
>>>>>>>=20
>>>>>>>>>> would be willing to push their own releases to our platform.
>>>>>>>>>>=20
>>>>>>>>>> A little more information about SDKMAN can be found at
>>>>>>>=20
>>>>>>> http://sdkman.io
>>>>>>>=20
>>>>>>>>> and
>>>>>>>>>=20
>>>>>>>>>> on our github page at https://github.com/sdkman/sdkman-cli.
>>>>>>>>>>=20
>>>>>>>>>> We expose a vendor API that can be called, more details of =
that
>>>>>>>=20
>>>>>>> under
>>>>>>>=20
>>>>>>>>>> the
>>>>>>>>>> Vendors section of our site. Of course we have a maven plugin =
to
>>>>>>>=20
>>>>>>> make
>>>>>>>=20
>>>>>>>>> this
>>>>>>>>>=20
>>>>>>>>>> super easy and a part of your build pipeline.
>>>>>>>>>>=20
>>>>>>>>>> Please let me know your thoughts and if this sounds feasible.
>>>>>>>>>>=20
>>>>>>>>>> Cheers!
>>>>>>>>>>=20
>>>>>>>>>> Marco.
>>>>>>>>>=20
>>>>>>>>>=20
>> --------------------------------------------------------------------
>>>>>>>>> -
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>=20
>>>>>>>=20
>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>=20
>>>> =
---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>=20
>>=20
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>=20
>>=20


--Apple-Mail=_CC3C989F-14CC-4E56-B334-F897A627D9B1--