You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2011/06/15 10:31:24 UTC
Fwd: [Math] download development snapshot
For components that use Nexus, it's trivial to use mvn deploy on a
SNAPSHOT release.
This can be useful for developers to check that a patch solves their problem.
However, snapshots should not be advertised to the general user
public, so should never be referenced from download pages, nor on the
user list.
But AFAIK it would be OK to mention the snapshot on the JIRA issue.
There are also some projects that use the CI servers to upload
snapshots. Not sure how that is done.
---------- Forwarded message ----------
From: Luc Maisonobe <Lu...@free.fr>
Date: 15 June 2011 08:40
Subject: Re: [Math] download development snapshot
To: Commons Users List <us...@commons.apache.org>
Le 15/06/2011 09:12, Dennis Hendriks a écrit :
>
> Hi all,
Hi Dennis,
>
> Since I'd like to use trunk (version 3.0, in development) of Apache
> Commons Math, I was wondering if there is a way to download an already
> built version of it. I found the build server at
> http://vmbuild.apache.org/continuum/buildResults.action?projectId=97&projectGroupId=16.
> Is there any way to get the jars (binaries, sources, javadoc) that were
> build by the build server, similar to the ones released for version 2.2?
No, as far as I know, the build server is only used for continuous
integration. Once the tests have been run and potential failure have
been reported, I think the built jars are dropped.
There are no official Apache supported builds for unreleased version.
The release process which involve a vote by the community is the
milestone that allow publishing. Before that, there can only be
unsupported, unofficial snapshot build. We don't do them really often
and in fact prefer that people who really want the development version
built it by themselves and rely on the subversion tree directly.
One should be aware that the development version is really that: a
*development* version. Things change quite often. These versions
therefore have some advantages (fixed bugs, new features, performances
improvements ...) but also some drawbacks (things appear, disappear,
change name, change API at a fast pace). So they are not suited to
everyone and publishing pre-built binaries would create a false
feeling of stability to most users.
What would you need a development snapshot for ? Could you use the
subversion repository (or the git mirror) instead ?
Sorry
Luc
>
> Thanks,
> Dennis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] download development snapshot
Posted by Phil Steitz <ph...@gmail.com>.
On 6/15/11 8:02 AM, Matt Benson wrote:
> On Wed, Jun 15, 2011 at 9:57 AM, sebb <se...@gmail.com> wrote:
>> On 15 June 2011 15:34, Matt Benson <gu...@gmail.com> wrote:
>>> On Wed, Jun 15, 2011 at 6:56 AM, Gilles Sadowski
>>> <gi...@harfang.homelinux.org> wrote:
>>>> On Wed, Jun 15, 2011 at 09:31:24AM +0100, sebb wrote:
>>>>> For components that use Nexus, it's trivial to use mvn deploy on a
>>>>> SNAPSHOT release.
>>>>>
>>>>> This can be useful for developers to check that a patch solves their problem.
>>>>>
>>>>> However, snapshots should not be advertised to the general user
>>>>> public, so should never be referenced from download pages, nor on the
>>>>> user list.
>>>>>
>>>>> But AFAIK it would be OK to mention the snapshot on the JIRA issue.
>>>>>
>>>>> There are also some projects that use the CI servers to upload
>>>>> snapshots. Not sure how that is done.
>>>> It would be nice to have a "latest" snapshot together with all snapshots
>>>> that are supposed to solve a given issue. "latest" would be overwritten by
>>>> the last issue snapshot.
>>>> E.g. assuming that issue (MATH-799) is resolved, the following snapshots
>>>> would be available:
>>>>
>>>> math-commons.MATH-774.jar
>>>> math-commons.latest.jar -> math-commons.MATH-774.jar
>>>>
>>>> Then, later, when issue MATH-768 is resolved:
>>>>
>>>> math-commons.MATH-774.jar
>>>> math-commons.MATH-768.jar
>>>> math-commons.latest.jar -> math-commons.MATH-768.jar
>>>>
>>> This snapshot-per-resolved-issue scheme certainly isn't something I'd
>>> care to implement by hand. I don't really think that degree of detail
>>> is necessary.
>> +1, latest should be sufficient for checking if the issues are resolved.
>>
>>> It would be nice to publish our CI builds to the
>>> snapshots repo. These are typically dated in the repo. E.g. Jenkins
>>> will have svn info available per-build, so the only piece potentially
>>> missing from this mixture would be the correlation between a given
>>> snapshot and the Jenkins build.
>> JMeter solves this by including the svn info as part of the version
>> id, which is logged/displayed on startup.
>> It also uses the revision as part of the snapshot build name.
>>
>> This is done with Ant, but it should be easy enough to adapt the code
>> for Maven builds.
>>
>> I don't think it will be possible to rename the snapshot artifacts, as
>> they are auto-generated by Maven, but updating the code should be easy
>> enough, and it might even be possible to add the SVN info to the
>> manifest which is present in all jars.
>>
>>> Not sure how the other available CI
>>> options stack up in this regard. Since AFAIK our CI builds currently
>>> are done in Continuum, I would be shocked to find that publishing a
>>> snapshot isn't part of its repertoire.
>> No idea whether Continuum supports snapshot publication - try asking
>> on the builds@a.o list.
>>
>> However, this will all take some effort to achieve.
>>
>> In the short term, the occasional manual mvn deploy + update of JIRA
>> with the reference should work for many use cases.
> I would amend to say a simple "I have published a SNAPSHOT containing
> this fix" should be enough for JIRA. Usually once fixed, things stay
> fixed, time being something we only know how to move through in a
> forward direction and all.
I don't like the idea of having JIRA refer to snapshots or doing
anything that dignifies specific snaps. Adding a comment referring
to a revision number where the issue is patched is enough, IMO. I
would be OK publishing links to nightlies as we used to do (and I
seem to recall it is still possible to grab them from Continuum);
but I think we should stay away from publishing anything that looks
like a milestone snap. I also think the best JIRA flow is RESOLVE
when fixed in svn and CLOSE when released.
I agree with Luc though that in general people who want to use trunk
should build it themselves. I would personally never rely on an
unreleased OSS snap or provide it to anyone else [1]. If I did use
the code, I would be basically signing up to use and support the
source myself and being set up to build it is essential for that.
So FWIW, my advice to anyone using any of our stuff from trunk is
build it from source. If you need help getting the build to work,
just ask. And of course, when you notice bugs or see opportunities
to improve, patches welcome!
Phil
[1] Some people will point out that unfortunately it is very hard to
never rely on unreleased snaps via transitive dependencies. This is
sadly true.
> Matt
>
>>> Matt
>>>
>>>> [Such a history might be useful to help users spot which change might have
>>>> resulted in breaking something.]
>>>>
>>>>
>>>> Best regards,
>>>> Gilles
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] download development snapshot
Posted by Matt Benson <gu...@gmail.com>.
On Wed, Jun 15, 2011 at 9:57 AM, sebb <se...@gmail.com> wrote:
> On 15 June 2011 15:34, Matt Benson <gu...@gmail.com> wrote:
>> On Wed, Jun 15, 2011 at 6:56 AM, Gilles Sadowski
>> <gi...@harfang.homelinux.org> wrote:
>>> On Wed, Jun 15, 2011 at 09:31:24AM +0100, sebb wrote:
>>>> For components that use Nexus, it's trivial to use mvn deploy on a
>>>> SNAPSHOT release.
>>>>
>>>> This can be useful for developers to check that a patch solves their problem.
>>>>
>>>> However, snapshots should not be advertised to the general user
>>>> public, so should never be referenced from download pages, nor on the
>>>> user list.
>>>>
>>>> But AFAIK it would be OK to mention the snapshot on the JIRA issue.
>>>>
>>>> There are also some projects that use the CI servers to upload
>>>> snapshots. Not sure how that is done.
>>>
>>> It would be nice to have a "latest" snapshot together with all snapshots
>>> that are supposed to solve a given issue. "latest" would be overwritten by
>>> the last issue snapshot.
>>> E.g. assuming that issue (MATH-799) is resolved, the following snapshots
>>> would be available:
>>>
>>> math-commons.MATH-774.jar
>>> math-commons.latest.jar -> math-commons.MATH-774.jar
>>>
>>> Then, later, when issue MATH-768 is resolved:
>>>
>>> math-commons.MATH-774.jar
>>> math-commons.MATH-768.jar
>>> math-commons.latest.jar -> math-commons.MATH-768.jar
>>>
>>
>> This snapshot-per-resolved-issue scheme certainly isn't something I'd
>> care to implement by hand. I don't really think that degree of detail
>> is necessary.
>
> +1, latest should be sufficient for checking if the issues are resolved.
>
>> It would be nice to publish our CI builds to the
>> snapshots repo. These are typically dated in the repo. E.g. Jenkins
>> will have svn info available per-build, so the only piece potentially
>> missing from this mixture would be the correlation between a given
>> snapshot and the Jenkins build.
>
> JMeter solves this by including the svn info as part of the version
> id, which is logged/displayed on startup.
> It also uses the revision as part of the snapshot build name.
>
> This is done with Ant, but it should be easy enough to adapt the code
> for Maven builds.
>
> I don't think it will be possible to rename the snapshot artifacts, as
> they are auto-generated by Maven, but updating the code should be easy
> enough, and it might even be possible to add the SVN info to the
> manifest which is present in all jars.
>
>> Not sure how the other available CI
>> options stack up in this regard. Since AFAIK our CI builds currently
>> are done in Continuum, I would be shocked to find that publishing a
>> snapshot isn't part of its repertoire.
>
> No idea whether Continuum supports snapshot publication - try asking
> on the builds@a.o list.
>
> However, this will all take some effort to achieve.
>
> In the short term, the occasional manual mvn deploy + update of JIRA
> with the reference should work for many use cases.
I would amend to say a simple "I have published a SNAPSHOT containing
this fix" should be enough for JIRA. Usually once fixed, things stay
fixed, time being something we only know how to move through in a
forward direction and all.
Matt
>
>> Matt
>>
>>> [Such a history might be useful to help users spot which change might have
>>> resulted in breaking something.]
>>>
>>>
>>> Best regards,
>>> Gilles
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] download development snapshot
Posted by sebb <se...@gmail.com>.
On 15 June 2011 15:34, Matt Benson <gu...@gmail.com> wrote:
> On Wed, Jun 15, 2011 at 6:56 AM, Gilles Sadowski
> <gi...@harfang.homelinux.org> wrote:
>> On Wed, Jun 15, 2011 at 09:31:24AM +0100, sebb wrote:
>>> For components that use Nexus, it's trivial to use mvn deploy on a
>>> SNAPSHOT release.
>>>
>>> This can be useful for developers to check that a patch solves their problem.
>>>
>>> However, snapshots should not be advertised to the general user
>>> public, so should never be referenced from download pages, nor on the
>>> user list.
>>>
>>> But AFAIK it would be OK to mention the snapshot on the JIRA issue.
>>>
>>> There are also some projects that use the CI servers to upload
>>> snapshots. Not sure how that is done.
>>
>> It would be nice to have a "latest" snapshot together with all snapshots
>> that are supposed to solve a given issue. "latest" would be overwritten by
>> the last issue snapshot.
>> E.g. assuming that issue (MATH-799) is resolved, the following snapshots
>> would be available:
>>
>> math-commons.MATH-774.jar
>> math-commons.latest.jar -> math-commons.MATH-774.jar
>>
>> Then, later, when issue MATH-768 is resolved:
>>
>> math-commons.MATH-774.jar
>> math-commons.MATH-768.jar
>> math-commons.latest.jar -> math-commons.MATH-768.jar
>>
>
> This snapshot-per-resolved-issue scheme certainly isn't something I'd
> care to implement by hand. I don't really think that degree of detail
> is necessary.
+1, latest should be sufficient for checking if the issues are resolved.
> It would be nice to publish our CI builds to the
> snapshots repo. These are typically dated in the repo. E.g. Jenkins
> will have svn info available per-build, so the only piece potentially
> missing from this mixture would be the correlation between a given
> snapshot and the Jenkins build.
JMeter solves this by including the svn info as part of the version
id, which is logged/displayed on startup.
It also uses the revision as part of the snapshot build name.
This is done with Ant, but it should be easy enough to adapt the code
for Maven builds.
I don't think it will be possible to rename the snapshot artifacts, as
they are auto-generated by Maven, but updating the code should be easy
enough, and it might even be possible to add the SVN info to the
manifest which is present in all jars.
> Not sure how the other available CI
> options stack up in this regard. Since AFAIK our CI builds currently
> are done in Continuum, I would be shocked to find that publishing a
> snapshot isn't part of its repertoire.
No idea whether Continuum supports snapshot publication - try asking
on the builds@a.o list.
However, this will all take some effort to achieve.
In the short term, the occasional manual mvn deploy + update of JIRA
with the reference should work for many use cases.
> Matt
>
>> [Such a history might be useful to help users spot which change might have
>> resulted in breaking something.]
>>
>>
>> Best regards,
>> Gilles
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] download development snapshot
Posted by Matt Benson <gu...@gmail.com>.
On Wed, Jun 15, 2011 at 6:56 AM, Gilles Sadowski
<gi...@harfang.homelinux.org> wrote:
> On Wed, Jun 15, 2011 at 09:31:24AM +0100, sebb wrote:
>> For components that use Nexus, it's trivial to use mvn deploy on a
>> SNAPSHOT release.
>>
>> This can be useful for developers to check that a patch solves their problem.
>>
>> However, snapshots should not be advertised to the general user
>> public, so should never be referenced from download pages, nor on the
>> user list.
>>
>> But AFAIK it would be OK to mention the snapshot on the JIRA issue.
>>
>> There are also some projects that use the CI servers to upload
>> snapshots. Not sure how that is done.
>
> It would be nice to have a "latest" snapshot together with all snapshots
> that are supposed to solve a given issue. "latest" would be overwritten by
> the last issue snapshot.
> E.g. assuming that issue (MATH-799) is resolved, the following snapshots
> would be available:
>
> math-commons.MATH-774.jar
> math-commons.latest.jar -> math-commons.MATH-774.jar
>
> Then, later, when issue MATH-768 is resolved:
>
> math-commons.MATH-774.jar
> math-commons.MATH-768.jar
> math-commons.latest.jar -> math-commons.MATH-768.jar
>
This snapshot-per-resolved-issue scheme certainly isn't something I'd
care to implement by hand. I don't really think that degree of detail
is necessary. It would be nice to publish our CI builds to the
snapshots repo. These are typically dated in the repo. E.g. Jenkins
will have svn info available per-build, so the only piece potentially
missing from this mixture would be the correlation between a given
snapshot and the Jenkins build. Not sure how the other available CI
options stack up in this regard. Since AFAIK our CI builds currently
are done in Continuum, I would be shocked to find that publishing a
snapshot isn't part of its repertoire.
Matt
> [Such a history might be useful to help users spot which change might have
> resulted in breaking something.]
>
>
> Best regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] download development snapshot
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Wed, Jun 15, 2011 at 09:31:24AM +0100, sebb wrote:
> For components that use Nexus, it's trivial to use mvn deploy on a
> SNAPSHOT release.
>
> This can be useful for developers to check that a patch solves their problem.
>
> However, snapshots should not be advertised to the general user
> public, so should never be referenced from download pages, nor on the
> user list.
>
> But AFAIK it would be OK to mention the snapshot on the JIRA issue.
>
> There are also some projects that use the CI servers to upload
> snapshots. Not sure how that is done.
It would be nice to have a "latest" snapshot together with all snapshots
that are supposed to solve a given issue. "latest" would be overwritten by
the last issue snapshot.
E.g. assuming that issue (MATH-799) is resolved, the following snapshots
would be available:
math-commons.MATH-774.jar
math-commons.latest.jar -> math-commons.MATH-774.jar
Then, later, when issue MATH-768 is resolved:
math-commons.MATH-774.jar
math-commons.MATH-768.jar
math-commons.latest.jar -> math-commons.MATH-768.jar
[Such a history might be useful to help users spot which change might have
resulted in breaking something.]
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org