Re: Download links for sha256/sha512 checksums

[Hervé BOUTEMY]

to me, going to sha1 only *for fingerprints* is the right move currently

going to sha256 would make people think that a strong fingerprint means a 
stronger security: this is wrong
If you want security, check signatures (ie. .asc files, with corresponding 
public keys) that are real security (done with strong fingerprints built 
inside)

but fingerprints only are just checksums against download issues: technically, 
we could stay with md5 or even weaker (good old crc?), IMHO. That's just to 
avoid bad md5 reputation that we need to avoid it now: md5 for signature is 
bad, but md5 for fingerprint could still be sufficient.

Regards,

Hervé

Le vendredi 6 avril 2018, 21:54:42 CEST Michael Osipov a écrit :
> Am 2018-04-06 um 21:50 schrieb Karl Heinz Marbaise:
> > Hi to all,
> > 
> > updated the download page having now sha256/sha512 links...
> > 
> > first step of the efforts to migrate away from .md5 to sha256/sha512..
> > 
> > Most important:
> > 
> > https://maven.apache.org/download.cgi
> > 
> > WDYT ?
> > 
> > other changes/improvements ?
> 
> I would definitively keep SHA-1 around. As for SHA2-512, isn't there any
> benefit for us ATM compared to 256?
> 
> Michael
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Download links for sha256/sha512 checksums

[Michael Osipov]

Am 2018-04-06 um 22:38 schrieb Karl Heinz Marbaise:

Hi,

On 06/04/18 22:28, Michael Osipov wrote:

Am 2018-04-06 um 22:13 schrieb Karl Heinz Marbaise:

Hi,

On 06/04/18 21:54, Michael Osipov wrote:

Am 2018-04-06 um 21:50 schrieb Karl Heinz Marbaise:

Hi to all,

updated the download page having now sha256/sha512 links...

first step of the efforts to migrate away from .md5 to sha256/sha512..

Most important:

https://maven.apache.org/download.cgi

WDYT ?

other changes/improvements ?


I would definitively keep SHA-1 around. As for SHA2-512, isn't there 
any benefit for us ATM compared to 256?


So you would say having only sha1, sha256 ?


Correct.


changed accordingly..


+1

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Download links for sha256/sha512 checksums

[Karl Heinz Marbaise]

Hi,

On 06/04/18 22:28, Michael Osipov wrote:

Am 2018-04-06 um 22:13 schrieb Karl Heinz Marbaise:

Hi,

On 06/04/18 21:54, Michael Osipov wrote:

Am 2018-04-06 um 21:50 schrieb Karl Heinz Marbaise:

Hi to all,

updated the download page having now sha256/sha512 links...

first step of the efforts to migrate away from .md5 to sha256/sha512..

Most important:

https://maven.apache.org/download.cgi

WDYT ?

other changes/improvements ?


I would definitively keep SHA-1 around. As for SHA2-512, isn't there 
any benefit for us ATM compared to 256?


So you would say having only sha1, sha256 ?


Correct.


changed accordingly..

Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Download links for sha256/sha512 checksums

[Michael Osipov]

Am 2018-04-06 um 22:13 schrieb Karl Heinz Marbaise:

Hi,

On 06/04/18 21:54, Michael Osipov wrote:

Am 2018-04-06 um 21:50 schrieb Karl Heinz Marbaise:

Hi to all,

updated the download page having now sha256/sha512 links...

first step of the efforts to migrate away from .md5 to sha256/sha512..

Most important:

https://maven.apache.org/download.cgi

WDYT ?

other changes/improvements ?


I would definitively keep SHA-1 around. As for SHA2-512, isn't there 
any benefit for us ATM compared to 256?


So you would say having only sha1, sha256 ?


Correct.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Download links for sha256/sha512 checksums

[Karl Heinz Marbaise]

Hi,

On 06/04/18 21:54, Michael Osipov wrote:

Am 2018-04-06 um 21:50 schrieb Karl Heinz Marbaise:

Hi to all,

updated the download page having now sha256/sha512 links...

first step of the efforts to migrate away from .md5 to sha256/sha512..

Most important:

https://maven.apache.org/download.cgi

WDYT ?

other changes/improvements ?


I would definitively keep SHA-1 around. As for SHA2-512, isn't there any 
benefit for us ATM compared to 256?


So you would say having only sha1, sha256 ?

Kind regards
Karl Heinz Marbaise


Michael



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Download links for sha256/sha512 checksums

[Michael Osipov]

Am 2018-04-06 um 21:50 schrieb Karl Heinz Marbaise:

Hi to all,

updated the download page having now sha256/sha512 links...

first step of the efforts to migrate away from .md5 to sha256/sha512..

Most important:

https://maven.apache.org/download.cgi

WDYT ?

other changes/improvements ?


I would definitively keep SHA-1 around. As for SHA2-512, isn't there any 
benefit for us ATM compared to 256?


Michael

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Download links for sha256/sha512 checksums

[Karl Heinz Marbaise]

Hi to all,

updated the download page having now sha256/sha512 links...

first step of the efforts to migrate away from .md5 to sha256/sha512..

Most important:

https://maven.apache.org/download.cgi

WDYT ?

other changes/improvements ?

Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Download links

[Arnaud Héritier]

Good. Thanks a lot

On Sun, Nov 19, 2017 at 8:35 PM, Robert Scholte 
wrote:

> Thanks for picking this up and the great results!
>
> Robert
>
>
> On Sun, 19 Nov 2017 18:59:00 +0100, Hervé BOUTEMY 
> wrote:
>
> issue fixed, and even more!!!
>> every issue with rewrite rules are fixed: thenks to Sebb idea, I replaced
>> the
>> rewrite rules with symlinks
>>
>> now it's easy to understand (even the mirror script can) and everything
>> works
>> as expected: no more /components redirection when you forgot trailing /
>> on a
>> directory
>>
>>
>> wow, that's good to fix such a longstanding issue...
>>
>> Regards,
>>
>> Hervé
>>
>> Le samedi 18 novembre 2017, 13:03:48 CET Hervé BOUTEMY a écrit :
>>
>>> found something that can explain: when using the real url starting with /
>>> components/, the CGI script works [4]
>>> But not when using the user-visible url (that uses .htaccess rewrite
>>> rules)
>>> [5]
>>>
>>> INFRA Jira issue opened: https://issues.apache.org/jira
>>> /browse/INFRA-15513
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>>
>>> [4] https://maven.apache.org/components/plugins/maven-jdeprscan-plugin/
>>> download.cgi
>>>
>>> [5] https://maven.apache.org/plugins/maven-jdeprscan-plugin/download.cgi
>>>
>>> Le samedi 18 novembre 2017, 01:18:27 CET Hervé BOUTEMY a écrit :
>>> > ok, xdoc/download.xml.vm was missing for this new plugin: I added it
>>> and
>>> > manually added a generated html result to svnpubsub location [1]
>>> >
>>> > this is not yet sufficient: I don't know why download.cgi script does
>>> not
>>> > find download.html
>>> >
>>> > this is working on main Maven site [2] from its own svnpubsub location
>>> [3]
>>> >
>>> > any hint?
>>> >
>>> > Regards,
>>> >
>>> > Hervé
>>> >
>>> > [1]
>>> > https://svn.apache.org/repos/infra/websites/production/maven
>>> /components/
>>> > plugins/maven-jdeprscan-plugin/
>>> >
>>> > [2] http://maven.apache.org/download.cgi
>>> >
>>> > [3] https://svn.apache.org/repos/infra/websites/production/maven
>>> /content/
>>> >
>>> > Le vendredi 17 novembre 2017, 12:47:51 CET Hervé BOUTEMY a écrit :
>>> > > the deeplink used to work: that's the objective of our
>>> > > "resources/download.cgi + xdoc/download.xml.vm" pattern that was
>>> created
>>> > > some years ago.
>>> > > download.cgi is supposed to use standard ASF script that uses
>>> > > download.html
>>> > > as content
>>> > >
>>> > > I don't know why this does not work any more.
>>> > >
>>> > > I vaguely remember something a few years ago about executable bit,
>>> some
>>> > > headache I had at that time to try to fix working with interested
>>> people
>>> > > (ie. not many, but Sebb was probably one of the few). Perhaps it's
>>> time
>>> > > to
>>> > > rework on it: I'll see tonight if I can find references on the
>>> analysis
>>> > > already done at that time.
>>> > >
>>> > > Regards,
>>> > >
>>> > > Hervé
>>> > >
>>> > > Le vendredi 17 novembre 2017, 12:27:49 CET Robert Scholte a écrit :
>>> > > > This topic deserves a separate mailthread.
>>> > > >
>>> > > > Quoting Sebb on a different thread:
>>> > > > "The download link points to the top-level of the ASF mirror
>>> system.
>>> > > >
>>> > > > This makes it very hard to use."
>>> > > >
>>> > > > AFAIK the ASF says there should be a download button for every
>>> > > > released
>>> > > > product.
>>> > > > In case of Maven we're talking about a lot of projects, and
>>> downloads
>>> > > > should be redirected via a mirror.
>>> > > > I don't think it is possible to do a deeplink to a specific folder.
>>> > > >
>>> > > > Also, in case of Maven plugins and other dependencies (all
>>> excluding
>>> > > > the
>>> > > > Maven distribution itself) it is kind of strange to provide a
>>> download
>>> > > > link when we could assume that they only want to have the
>>> > > > plugin/dependency XML fragment.
>>> > > >
>>> > > > I agree that the link is kind of useless right now, but also the
>>> best
>>> > > > we
>>> > > > can do when providing a direct download link.
>>> > > > If there's no way to do a deeplink, I'd prefer to remove it from
>>> the
>>> > > > pages
>>> > > > and announcements.
>>> > > >
>>> > > > thanks,
>>> > > > Robert
>>> > > >
>>> > > > 
>>> -
>>> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> > > > For additional commands, e-mail: dev-h...@maven.apache.org
>>> > >
>>> > > 
>>> -
>>> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> > > For additional commands, e-mail: dev-h...@maven.apache.org
>>> >
>>> > -
>>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> > For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> 

Re: Download links

[Robert Scholte]

Thanks for picking this up and the great results!

Robert

On Sun, 19 Nov 2017 18:59:00 +0100, Hervé BOUTEMY   
wrote:



issue fixed, and even more!!!
every issue with rewrite rules are fixed: thenks to Sebb idea, I  
replaced the

rewrite rules with symlinks

now it's easy to understand (even the mirror script can) and everything  
works
as expected: no more /components redirection when you forgot trailing /  
on a

directory


wow, that's good to fix such a longstanding issue...

Regards,

Hervé

Le samedi 18 novembre 2017, 13:03:48 CET Hervé BOUTEMY a écrit :
found something that can explain: when using the real url starting with  
/

components/, the CGI script works [4]
But not when using the user-visible url (that uses .htaccess rewrite  
rules)

[5]

INFRA Jira issue opened:  
https://issues.apache.org/jira/browse/INFRA-15513


Regards,

Hervé


[4] https://maven.apache.org/components/plugins/maven-jdeprscan-plugin/
download.cgi

[5] https://maven.apache.org/plugins/maven-jdeprscan-plugin/download.cgi

Le samedi 18 novembre 2017, 01:18:27 CET Hervé BOUTEMY a écrit :
> ok, xdoc/download.xml.vm was missing for this new plugin: I added it  
and

> manually added a generated html result to svnpubsub location [1]
>
> this is not yet sufficient: I don't know why download.cgi script does  
not

> find download.html
>
> this is working on main Maven site [2] from its own svnpubsub  
location [3]

>
> any hint?
>
> Regards,
>
> Hervé
>
> [1]
>  
https://svn.apache.org/repos/infra/websites/production/maven/components/

> plugins/maven-jdeprscan-plugin/
>
> [2] http://maven.apache.org/download.cgi
>
> [3]  
https://svn.apache.org/repos/infra/websites/production/maven/content/

>
> Le vendredi 17 novembre 2017, 12:47:51 CET Hervé BOUTEMY a écrit :
> > the deeplink used to work: that's the objective of our
> > "resources/download.cgi + xdoc/download.xml.vm" pattern that was  
created

> > some years ago.
> > download.cgi is supposed to use standard ASF script that uses
> > download.html
> > as content
> >
> > I don't know why this does not work any more.
> >
> > I vaguely remember something a few years ago about executable bit,  
some
> > headache I had at that time to try to fix working with interested  
people
> > (ie. not many, but Sebb was probably one of the few). Perhaps it's  
time

> > to
> > rework on it: I'll see tonight if I can find references on the  
analysis

> > already done at that time.
> >
> > Regards,
> >
> > Hervé
> >
> > Le vendredi 17 novembre 2017, 12:27:49 CET Robert Scholte a écrit :
> > > This topic deserves a separate mailthread.
> > >
> > > Quoting Sebb on a different thread:
> > > "The download link points to the top-level of the ASF mirror  
system.

> > >
> > > This makes it very hard to use."
> > >
> > > AFAIK the ASF says there should be a download button for every
> > > released
> > > product.
> > > In case of Maven we're talking about a lot of projects, and  
downloads

> > > should be redirected via a mirror.
> > > I don't think it is possible to do a deeplink to a specific  
folder.

> > >
> > > Also, in case of Maven plugins and other dependencies (all  
excluding

> > > the
> > > Maven distribution itself) it is kind of strange to provide a  
download

> > > link when we could assume that they only want to have the
> > > plugin/dependency XML fragment.
> > >
> > > I agree that the link is kind of useless right now, but also the  
best

> > > we
> > > can do when providing a direct download link.
> > > If there's no way to do a deeplink, I'd prefer to remove it from  
the

> > > pages
> > > and announcements.
> > >
> > > thanks,
> > > Robert
> > >
> > >  
-

> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >  
-

> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Download links

[Hervé BOUTEMY]

issue fixed, and even more!!!
every issue with rewrite rules are fixed: thenks to Sebb idea, I replaced the 
rewrite rules with symlinks

now it's easy to understand (even the mirror script can) and everything works 
as expected: no more /components redirection when you forgot trailing / on a 
directory


wow, that's good to fix such a longstanding issue...

Regards,

Hervé

Le samedi 18 novembre 2017, 13:03:48 CET Hervé BOUTEMY a écrit :
> found something that can explain: when using the real url starting with /
> components/, the CGI script works [4]
> But not when using the user-visible url (that uses .htaccess rewrite rules)
> [5]
> 
> INFRA Jira issue opened: https://issues.apache.org/jira/browse/INFRA-15513
> 
> Regards,
> 
> Hervé
> 
> 
> [4] https://maven.apache.org/components/plugins/maven-jdeprscan-plugin/
> download.cgi
> 
> [5] https://maven.apache.org/plugins/maven-jdeprscan-plugin/download.cgi
> 
> Le samedi 18 novembre 2017, 01:18:27 CET Hervé BOUTEMY a écrit :
> > ok, xdoc/download.xml.vm was missing for this new plugin: I added it and
> > manually added a generated html result to svnpubsub location [1]
> > 
> > this is not yet sufficient: I don't know why download.cgi script does not
> > find download.html
> > 
> > this is working on main Maven site [2] from its own svnpubsub location [3]
> > 
> > any hint?
> > 
> > Regards,
> > 
> > Hervé
> > 
> > [1]
> > https://svn.apache.org/repos/infra/websites/production/maven/components/
> > plugins/maven-jdeprscan-plugin/
> > 
> > [2] http://maven.apache.org/download.cgi
> > 
> > [3] https://svn.apache.org/repos/infra/websites/production/maven/content/
> > 
> > Le vendredi 17 novembre 2017, 12:47:51 CET Hervé BOUTEMY a écrit :
> > > the deeplink used to work: that's the objective of our
> > > "resources/download.cgi + xdoc/download.xml.vm" pattern that was created
> > > some years ago.
> > > download.cgi is supposed to use standard ASF script that uses
> > > download.html
> > > as content
> > > 
> > > I don't know why this does not work any more.
> > > 
> > > I vaguely remember something a few years ago about executable bit, some
> > > headache I had at that time to try to fix working with interested people
> > > (ie. not many, but Sebb was probably one of the few). Perhaps it's time
> > > to
> > > rework on it: I'll see tonight if I can find references on the analysis
> > > already done at that time.
> > > 
> > > Regards,
> > > 
> > > Hervé
> > > 
> > > Le vendredi 17 novembre 2017, 12:27:49 CET Robert Scholte a écrit :
> > > > This topic deserves a separate mailthread.
> > > > 
> > > > Quoting Sebb on a different thread:
> > > > "The download link points to the top-level of the ASF mirror system.
> > > > 
> > > > This makes it very hard to use."
> > > > 
> > > > AFAIK the ASF says there should be a download button for every
> > > > released
> > > > product.
> > > > In case of Maven we're talking about a lot of projects, and downloads
> > > > should be redirected via a mirror.
> > > > I don't think it is possible to do a deeplink to a specific folder.
> > > > 
> > > > Also, in case of Maven plugins and other dependencies (all excluding
> > > > the
> > > > Maven distribution itself) it is kind of strange to provide a download
> > > > link when we could assume that they only want to have the
> > > > plugin/dependency XML fragment.
> > > > 
> > > > I agree that the link is kind of useless right now, but also the best
> > > > we
> > > > can do when providing a direct download link.
> > > > If there's no way to do a deeplink, I'd prefer to remove it from the
> > > > pages
> > > > and announcements.
> > > > 
> > > > thanks,
> > > > Robert
> > > > 
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > 
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Download links

[Hervé BOUTEMY]

found something that can explain: when using the real url starting with /
components/, the CGI script works [4]
But not when using the user-visible url (that uses .htaccess rewrite rules) 
[5]

INFRA Jira issue opened: https://issues.apache.org/jira/browse/INFRA-15513

Regards,

Hervé


[4] https://maven.apache.org/components/plugins/maven-jdeprscan-plugin/
download.cgi

[5] https://maven.apache.org/plugins/maven-jdeprscan-plugin/download.cgi

Le samedi 18 novembre 2017, 01:18:27 CET Hervé BOUTEMY a écrit :
> ok, xdoc/download.xml.vm was missing for this new plugin: I added it and
> manually added a generated html result to svnpubsub location [1]
> 
> this is not yet sufficient: I don't know why download.cgi script does not
> find download.html
> 
> this is working on main Maven site [2] from its own svnpubsub location [3]
> 
> any hint?
> 
> Regards,
> 
> Hervé
> 
> [1] https://svn.apache.org/repos/infra/websites/production/maven/components/
> plugins/maven-jdeprscan-plugin/
> 
> [2] http://maven.apache.org/download.cgi
> 
> [3] https://svn.apache.org/repos/infra/websites/production/maven/content/
> 
> Le vendredi 17 novembre 2017, 12:47:51 CET Hervé BOUTEMY a écrit :
> > the deeplink used to work: that's the objective of our
> > "resources/download.cgi + xdoc/download.xml.vm" pattern that was created
> > some years ago.
> > download.cgi is supposed to use standard ASF script that uses
> > download.html
> > as content
> > 
> > I don't know why this does not work any more.
> > 
> > I vaguely remember something a few years ago about executable bit, some
> > headache I had at that time to try to fix working with interested people
> > (ie. not many, but Sebb was probably one of the few). Perhaps it's time to
> > rework on it: I'll see tonight if I can find references on the analysis
> > already done at that time.
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le vendredi 17 novembre 2017, 12:27:49 CET Robert Scholte a écrit :
> > > This topic deserves a separate mailthread.
> > > 
> > > Quoting Sebb on a different thread:
> > > "The download link points to the top-level of the ASF mirror system.
> > > 
> > > This makes it very hard to use."
> > > 
> > > AFAIK the ASF says there should be a download button for every released
> > > product.
> > > In case of Maven we're talking about a lot of projects, and downloads
> > > should be redirected via a mirror.
> > > I don't think it is possible to do a deeplink to a specific folder.
> > > 
> > > Also, in case of Maven plugins and other dependencies (all excluding the
> > > Maven distribution itself) it is kind of strange to provide a download
> > > link when we could assume that they only want to have the
> > > plugin/dependency XML fragment.
> > > 
> > > I agree that the link is kind of useless right now, but also the best we
> > > can do when providing a direct download link.
> > > If there's no way to do a deeplink, I'd prefer to remove it from the
> > > pages
> > > and announcements.
> > > 
> > > thanks,
> > > Robert
> > > 
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Download links

[Hervé BOUTEMY]

ok, xdoc/download.xml.vm was missing for this new plugin: I added it and 
manually added a generated html result to svnpubsub location [1]

this is not yet sufficient: I don't know why download.cgi script does not find 
download.html

this is working on main Maven site [2] from its own svnpubsub location [3]

any hint?

Regards,

Hervé

[1] https://svn.apache.org/repos/infra/websites/production/maven/components/
plugins/maven-jdeprscan-plugin/

[2] http://maven.apache.org/download.cgi

[3] https://svn.apache.org/repos/infra/websites/production/maven/content/

Le vendredi 17 novembre 2017, 12:47:51 CET Hervé BOUTEMY a écrit :
> the deeplink used to work: that's the objective of our
> "resources/download.cgi + xdoc/download.xml.vm" pattern that was created
> some years ago.
> download.cgi is supposed to use standard ASF script that uses download.html
> as content
> 
> I don't know why this does not work any more.
> 
> I vaguely remember something a few years ago about executable bit, some
> headache I had at that time to try to fix working with interested people
> (ie. not many, but Sebb was probably one of the few). Perhaps it's time to
> rework on it: I'll see tonight if I can find references on the analysis
> already done at that time.
> 
> Regards,
> 
> Hervé
> 
> Le vendredi 17 novembre 2017, 12:27:49 CET Robert Scholte a écrit :
> > This topic deserves a separate mailthread.
> > 
> > Quoting Sebb on a different thread:
> > "The download link points to the top-level of the ASF mirror system.
> > 
> > This makes it very hard to use."
> > 
> > AFAIK the ASF says there should be a download button for every released
> > product.
> > In case of Maven we're talking about a lot of projects, and downloads
> > should be redirected via a mirror.
> > I don't think it is possible to do a deeplink to a specific folder.
> > 
> > Also, in case of Maven plugins and other dependencies (all excluding the
> > Maven distribution itself) it is kind of strange to provide a download
> > link when we could assume that they only want to have the
> > plugin/dependency XML fragment.
> > 
> > I agree that the link is kind of useless right now, but also the best we
> > can do when providing a direct download link.
> > If there's no way to do a deeplink, I'd prefer to remove it from the pages
> > and announcements.
> > 
> > thanks,
> > Robert
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Download links

[sebb]

On 17 November 2017 at 11:27, Robert Scholte  wrote:
> This topic deserves a separate mailthread.
>
> Quoting Sebb on a different thread:
> "The download link points to the top-level of the ASF mirror system.
>
> This makes it very hard to use."
>
> AFAIK the ASF says there should be a download button for every released
> product.

Yes.

> In case of Maven we're talking about a lot of projects, and downloads should
> be redirected via a mirror.
>
> I don't think it is possible to do a deeplink to a specific folder.

Yes it is possible.

See
http://www.apache.org/dev/release-download-pages.html#closer
et seq.

In this case, you could use:

http://www.apache.org/dyn/closer.cgi/maven/plugins/

to at least show the correct directory.

and

http://www.apache.org/dyn/closer.cgi/maven/plugins/maven-jdeprscan-plugin-3.0.0-alpha-1-source-release.zip

to link to the file.

There are various other options; see the page quoted above.


> Also, in case of Maven plugins and other dependencies (all excluding the
> Maven distribution itself) it is kind of strange to provide a download link
> when we could assume that they only want to have the plugin/dependency XML
> fragment.
>
> I agree that the link is kind of useless right now, but also the best we can
> do when providing a direct download link.
> If there's no way to do a deeplink, I'd prefer to remove it from the pages
> and announcements.

The ASF mission is to produce open SOURCE software and links to the
source artifacts are required.

> thanks,
> Robert

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Download links

[Hervé BOUTEMY]

the deeplink used to work: that's the objective of our "resources/download.cgi 
+ xdoc/download.xml.vm" pattern that was created some years ago.
download.cgi is supposed to use standard ASF script that uses download.html as 
content

I don't know why this does not work any more.

I vaguely remember something a few years ago about executable bit, some 
headache I had at that time to try to fix working with interested people (ie. 
not many, but Sebb was probably one of the few). Perhaps it's time to rework 
on it: I'll see tonight if I can find references on the analysis already done 
at that time.

Regards,

Hervé

Le vendredi 17 novembre 2017, 12:27:49 CET Robert Scholte a écrit :
> This topic deserves a separate mailthread.
> 
> Quoting Sebb on a different thread:
> "The download link points to the top-level of the ASF mirror system.
> 
> This makes it very hard to use."
> 
> AFAIK the ASF says there should be a download button for every released
> product.
> In case of Maven we're talking about a lot of projects, and downloads
> should be redirected via a mirror.
> I don't think it is possible to do a deeplink to a specific folder.
> 
> Also, in case of Maven plugins and other dependencies (all excluding the
> Maven distribution itself) it is kind of strange to provide a download
> link when we could assume that they only want to have the
> plugin/dependency XML fragment.
> 
> I agree that the link is kind of useless right now, but also the best we
> can do when providing a direct download link.
> If there's no way to do a deeplink, I'd prefer to remove it from the pages
> and announcements.
> 
> thanks,
> Robert
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Download links

[Robert Scholte]

This topic deserves a separate mailthread.

Quoting Sebb on a different thread:
"The download link points to the top-level of the ASF mirror system.

This makes it very hard to use."

AFAIK the ASF says there should be a download button for every released  
product.
In case of Maven we're talking about a lot of projects, and downloads  
should be redirected via a mirror.

I don't think it is possible to do a deeplink to a specific folder.

Also, in case of Maven plugins and other dependencies (all excluding the  
Maven distribution itself) it is kind of strange to provide a download  
link when we could assume that they only want to have the  
plugin/dependency XML fragment.


I agree that the link is kind of useless right now, but also the best we  
can do when providing a direct download link.
If there's no way to do a deeplink, I'd prefer to remove it from the pages  
and announcements.


thanks,
Robert

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-site pull request: Fix download links for apache-maven-{3.2....

[Stephan202]

Github user Stephan202 closed the pull request at:

https://github.com/apache/maven-site/pull/2


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-site pull request: Fix download links for apache-maven-{3.2....

[Stephan202]

GitHub user Stephan202 opened a pull request:

https://github.com/apache/maven-site/pull/2

Fix download links for apache-maven-{3.2.5,3.1.1,3.0.5}-src.tar.gz.asc.

Summary says it. Some links on the download page contain the `/maven-2/` 
path component, while that should be `/maven-3/`.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Stephan202/maven-site fix-download-links

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-site/pull/2.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2


commit 0bf89b16ca070a971e54a0923ddb44b4d8661985
Author: Stephan Schroevers stephan.schroev...@escaladagroup.com
Date:   2015-03-24T22:21:06Z

Fix download links for apache-maven-{3.2.5,3.1.1,3.0.5}-src.tar.gz.asc.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Download links for source packages - where are they?

[sebb]

On 26 June 2013 02:48, Barrie Treloar baerr...@gmail.com wrote:
 On 26 June 2013 10:48, sebb seb...@gmail.com wrote:
 The point is that the ASF release source, and it must be provided for
 download via the ASF mirrors.

 See:

 http://www.apache.org/dev/release.html#host-GA

 If you don't point users to the source, I don't see how you can claim
 it has been properly released.

 Which part of http://www.apache.org/dev/release.html#host-GA do you
 think we are violating?

The spirit, if not the exact wording. Maybe the doc needs tweaking.

 Releases are available via http://archive.apache.org/dist/maven/plugins/

 We meet Project download pages must link to the mirrors for the
 Maven Core Project - but not the plugins.

 I can find no documentation that says you *must* provide a download page.
 Just that if there is a download page it must point to the mirrors.

Howewer the ASF releases source.
If you don't provide a download link to the source how are users
supposed to find it?

I agree that most people are not going to want to download the original source.
But that does not mean it should be left unlinked.

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Download links for source packages - where are they?

[Barrie Treloar]

On 26 June 2013 18:44, sebb seb...@gmail.com wrote:
 Howewer the ASF releases source.
 If you don't provide a download link to the source how are users
 supposed to find it?

 I agree that most people are not going to want to download the original 
 source.
 But that does not mean it should be left unlinked.

We provide all that for Maven core - the bit the users care about and run.

Plugins are download by Maven.
Few, if any, user is going to download a source distribution of a
plugin and built it themselves.
If they are going to do that, then they are likely to want to work on
Jira issues or provide a patch and it makes much more sense to work
with source control.
And we have prominent links to the source control repositories,
including the tags.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Download links for source packages - where are they?

[Stephen Connolly]

On Wednesday, 26 June 2013, Barrie Treloar wrote:

 On 26 June 2013 18:44, sebb seb...@gmail.com javascript:; wrote:
  Howewer the ASF releases source.
  If you don't provide a download link to the source how are users
  supposed to find it?
 
  I agree that most people are not going to want to download the original
 source.
  But that does not mean it should be left unlinked.

 We provide all that for Maven core - the bit the users care about and run.

 Plugins are download by Maven.
 Few, if any, user is going to download a source distribution of a
 plugin and built it themselves.
 If they are going to do that, then they are likely to want to work on
 Jira issues or provide a patch and it makes much more sense to work
 with source control.
 And we have prominent links to the source control repositories,
 including the tags.


I do not think it would be a major harm to add a reporting plugin to
generate the dist download link for source bundles... As it can only add...

I agree that there is no *requirement* for us to provide the download
link... But there are things we can improve.

Until recently, it was not clear to us that the source bundles had to be
copied into the dist directory... Someone at infra wrote an audit script
and we copied all the missing bundles over for plugins (they were on
repository.apache.org so it is not that we hadn't generated them)

I think we should turn on rat for all plugins, not just core... I will look
into this next week if nobody else has...

Most likely I will turn on rat without strong enforcement just yet, and
then turn on zero tollerance in a month or so to give people the chance to
fix rat issues and get out any emergency releases that might be required
(eg if there is a CVE requiring a plugin release, you don't want that
blocked while we review the integration test data that may or may not
require an ASF license header for the test to be valid, and I'd rather have
a valid set of exclusions rather than a lets just get the build passing to
make this release approach which can get forgotten to unwind after)


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:;
 For additional commands, e-mail: dev-h...@maven.apache.org javascript:;



-- 
Sent from my phone

Download links for source packages - where are they?

[sebb]

I could not find any download links for Maven source packages.

As the ASF primary purpose is to release source, and that must be
released via the mirror system, there ought to be download pages with
links to the source package, sigs, hashes and KEYS file.

Yes, there are source packages for some Maven plugins, but that is not
the same as providing download pages.

AFAIK every single other ASF project has download pages.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Download links for source packages - where are they?

[Olivier Lamy]

2013/6/26 sebb seb...@gmail.com:
 I could not find any download links for Maven source packages.

 As the ASF primary purpose is to release source, and that must be
 released via the mirror system, there ought to be download pages with
 links to the source package, sigs, hashes and KEYS file.

 Yes, there are source packages for some Maven plugins, but that is not
 the same as providing download pages.

 AFAIK every single other ASF project has download pages.

Is that mandatory ? Do you have any link saying that ?
At least for core I understand but for plugins...
BTW we started to put everything is here: http://www.us.apache.org/dist/maven/



 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Download links for source packages - where are they?

[Barrie Treloar]

On 26 June 2013 09:47, sebb seb...@gmail.com wrote:
 I could not find any download links for Maven source packages.

 As the ASF primary purpose is to release source, and that must be
 released via the mirror system, there ought to be download pages with
 links to the source package, sigs, hashes and KEYS file.

 Yes, there are source packages for some Maven plugins, but that is not
 the same as providing download pages.

 AFAIK every single other ASF project has download pages.


As a PMC member, I welcome scrutiny that we are following the
designated procedures.

Apologies for the length, I had to do some digging around to actually
remind myself of what we are meant to do.

According to http://www.apache.org/dev/release.html

http://www.apache.org/dev/release.html#where-do-releases-go

Where do releases go?

A release isn't 'released' until the contents are in the project's
distribution directory, which is a subdirectory of
www.apache.org/dist/. In addition to the distribution directory,
project that use Maven or a related build tool sometimes place their
releases on repository.apache.org beside some convenience binaries.
The distribution directory is required, while the repository system is
an optional convenience.

And http://www.apache.org/dev/release.html#what-must-every-release-contain

What Must Every ASF Release Contain?

Every ASF release must contain a source package, which must be
sufficient for a user to build and test the release provided they have
access to the appropriate platform and tools. The source package must
be cryptographically signed by the Release Manager with a detached
signature; and that package together with its signature must be tested
prior to voting +1 for release. Folks who vote +1 for release may
offer their own cryptographic signature to be concatenated with the
detached signature file (at the Release Manager's discretion) prior to
release.

Note that the PMC is responsible for all artifacts in their
distribution directory, which is a subdirectory of
www.apache.org/dist/ ; and all artifacts placed in their directory
must be signed by a committer, preferably by a PMC member. It is also
necessary for the PMC to ensure that the source package is sufficient
to build any binary artifacts associated with the release.

Every ASF release must comply with ASF licensing policy. This
requirement is of utmost importance and an audit should be performed
before any full release is created. In particular, every artifact
distributed must contain only appropriately licensed code. More
information can be found in the foundation website and in the release
licensing FAQ.

And http://www.apache.org/dev/release.html#release-announcements

How Should Releases Be Announced?

Please ensure that you wait at least 24 hours after uploading a new
release before updating the project download page and sending the
announcement email(s). This is so that mirrors have sufficient time to
catch up. (For time-critical security releases, the download pages
script supports bypassing this requirement.)

As far as I can tell there is no official policy requiring projects to
provide a download page.
It is just a convenience to end users to give them a direct download link.
The ASF documentation clearly defines where distributions must be placed.
Since you want people to use your project it makes sense to create a
download page to make it easy for them.

For Maven itself there are clearly defined download links from the
main entry point http://maven.apache.org.

For plugins I dont think it makes any sense to provide direct download
links to sources.
I checked http://www.apache.org/dev/release.html#maven-artifacts,
which links to http://www.apache.org/dev/publishing-maven-artifacts.html
doesn't provide any more guidance here either.

So why doesn't it make sense to provide direct download links?
Because it is Maven that is the consumer of artifacts rather than the end users.
And an end user is not likely to be building a plugin from source and
then installing it into their local Maven cache, it is much easier to
get Maven to download the binaries and use them that way.

The only reason I can think of a user wanting access to the source is
so they can make modifications, and if they dont know about the ASF
distribution pages, we give them the source repository link, e.g.
http://maven.apache.org/plugins/maven-compiler-plugin/source-repository.html,
on the automatically generated web pages. To me this is better as they
can then create patches.

Does that make sense?

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Download links for source packages - where are they?

[sebb]

On 26 June 2013 02:14, Barrie Treloar baerr...@gmail.com wrote:
 On 26 June 2013 09:47, sebb seb...@gmail.com wrote:
 I could not find any download links for Maven source packages.

 As the ASF primary purpose is to release source, and that must be
 released via the mirror system, there ought to be download pages with
 links to the source package, sigs, hashes and KEYS file.

 Yes, there are source packages for some Maven plugins, but that is not
 the same as providing download pages.

 AFAIK every single other ASF project has download pages.


 As a PMC member, I welcome scrutiny that we are following the
 designated procedures.

 Apologies for the length, I had to do some digging around to actually
 remind myself of what we are meant to do.

 According to http://www.apache.org/dev/release.html

 http://www.apache.org/dev/release.html#where-do-releases-go

 Where do releases go?

 A release isn't 'released' until the contents are in the project's
 distribution directory, which is a subdirectory of
 www.apache.org/dist/. In addition to the distribution directory,
 project that use Maven or a related build tool sometimes place their
 releases on repository.apache.org beside some convenience binaries.
 The distribution directory is required, while the repository system is
 an optional convenience.

 And http://www.apache.org/dev/release.html#what-must-every-release-contain

 What Must Every ASF Release Contain?

 Every ASF release must contain a source package, which must be
 sufficient for a user to build and test the release provided they have
 access to the appropriate platform and tools. The source package must
 be cryptographically signed by the Release Manager with a detached
 signature; and that package together with its signature must be tested
 prior to voting +1 for release. Folks who vote +1 for release may
 offer their own cryptographic signature to be concatenated with the
 detached signature file (at the Release Manager's discretion) prior to
 release.

 Note that the PMC is responsible for all artifacts in their
 distribution directory, which is a subdirectory of
 www.apache.org/dist/ ; and all artifacts placed in their directory
 must be signed by a committer, preferably by a PMC member. It is also
 necessary for the PMC to ensure that the source package is sufficient
 to build any binary artifacts associated with the release.

 Every ASF release must comply with ASF licensing policy. This
 requirement is of utmost importance and an audit should be performed
 before any full release is created. In particular, every artifact
 distributed must contain only appropriately licensed code. More
 information can be found in the foundation website and in the release
 licensing FAQ.

 And http://www.apache.org/dev/release.html#release-announcements

 How Should Releases Be Announced?

 Please ensure that you wait at least 24 hours after uploading a new
 release before updating the project download page and sending the
 announcement email(s). This is so that mirrors have sufficient time to
 catch up. (For time-critical security releases, the download pages
 script supports bypassing this requirement.)

 As far as I can tell there is no official policy requiring projects to
 provide a download page.
 It is just a convenience to end users to give them a direct download link.
 The ASF documentation clearly defines where distributions must be placed.
 Since you want people to use your project it makes sense to create a
 download page to make it easy for them.

 For Maven itself there are clearly defined download links from the
 main entry point http://maven.apache.org.

 For plugins I dont think it makes any sense to provide direct download
 links to sources.
 I checked http://www.apache.org/dev/release.html#maven-artifacts,
 which links to http://www.apache.org/dev/publishing-maven-artifacts.html
 doesn't provide any more guidance here either.

 So why doesn't it make sense to provide direct download links?
 Because it is Maven that is the consumer of artifacts rather than the end 
 users.
 And an end user is not likely to be building a plugin from source and
 then installing it into their local Maven cache, it is much easier to
 get Maven to download the binaries and use them that way.

 The only reason I can think of a user wanting access to the source is
 so they can make modifications, and if they dont know about the ASF
 distribution pages, we give them the source repository link, e.g.
 http://maven.apache.org/plugins/maven-compiler-plugin/source-repository.html,
 on the automatically generated web pages. To me this is better as they
 can then create patches.

 Does that make sense?

The point is that the ASF release source, and it must be provided for
download via the ASF mirrors.

See:

http://www.apache.org/dev/release.html#host-GA

If you don't point users to the source, I don't see how you can claim
it has been properly released

Re: Download links for source packages - where are they?

[Olivier Lamy]

funny discussion which come back around every 3years
:-)


2013/6/26 sebb seb...@gmail.com:
 On 26 June 2013 02:14, Barrie Treloar baerr...@gmail.com wrote:
 On 26 June 2013 09:47, sebb seb...@gmail.com wrote:
 I could not find any download links for Maven source packages.

 As the ASF primary purpose is to release source, and that must be
 released via the mirror system, there ought to be download pages with
 links to the source package, sigs, hashes and KEYS file.

 Yes, there are source packages for some Maven plugins, but that is not
 the same as providing download pages.

 AFAIK every single other ASF project has download pages.


 As a PMC member, I welcome scrutiny that we are following the
 designated procedures.

 Apologies for the length, I had to do some digging around to actually
 remind myself of what we are meant to do.

 According to http://www.apache.org/dev/release.html

 http://www.apache.org/dev/release.html#where-do-releases-go

 Where do releases go?

 A release isn't 'released' until the contents are in the project's
 distribution directory, which is a subdirectory of
 www.apache.org/dist/. In addition to the distribution directory,
 project that use Maven or a related build tool sometimes place their
 releases on repository.apache.org beside some convenience binaries.
 The distribution directory is required, while the repository system is
 an optional convenience.

 And http://www.apache.org/dev/release.html#what-must-every-release-contain

 What Must Every ASF Release Contain?

 Every ASF release must contain a source package, which must be
 sufficient for a user to build and test the release provided they have
 access to the appropriate platform and tools. The source package must
 be cryptographically signed by the Release Manager with a detached
 signature; and that package together with its signature must be tested
 prior to voting +1 for release. Folks who vote +1 for release may
 offer their own cryptographic signature to be concatenated with the
 detached signature file (at the Release Manager's discretion) prior to
 release.

 Note that the PMC is responsible for all artifacts in their
 distribution directory, which is a subdirectory of
 www.apache.org/dist/ ; and all artifacts placed in their directory
 must be signed by a committer, preferably by a PMC member. It is also
 necessary for the PMC to ensure that the source package is sufficient
 to build any binary artifacts associated with the release.

 Every ASF release must comply with ASF licensing policy. This
 requirement is of utmost importance and an audit should be performed
 before any full release is created. In particular, every artifact
 distributed must contain only appropriately licensed code. More
 information can be found in the foundation website and in the release
 licensing FAQ.

 And http://www.apache.org/dev/release.html#release-announcements

 How Should Releases Be Announced?

 Please ensure that you wait at least 24 hours after uploading a new
 release before updating the project download page and sending the
 announcement email(s). This is so that mirrors have sufficient time to
 catch up. (For time-critical security releases, the download pages
 script supports bypassing this requirement.)

 As far as I can tell there is no official policy requiring projects to
 provide a download page.
 It is just a convenience to end users to give them a direct download link.
 The ASF documentation clearly defines where distributions must be placed.
 Since you want people to use your project it makes sense to create a
 download page to make it easy for them.

 For Maven itself there are clearly defined download links from the
 main entry point http://maven.apache.org.

 For plugins I dont think it makes any sense to provide direct download
 links to sources.
 I checked http://www.apache.org/dev/release.html#maven-artifacts,
 which links to http://www.apache.org/dev/publishing-maven-artifacts.html
 doesn't provide any more guidance here either.

 So why doesn't it make sense to provide direct download links?
 Because it is Maven that is the consumer of artifacts rather than the end 
 users.
 And an end user is not likely to be building a plugin from source and
 then installing it into their local Maven cache, it is much easier to
 get Maven to download the binaries and use them that way.

 The only reason I can think of a user wanting access to the source is
 so they can make modifications, and if they dont know about the ASF
 distribution pages, we give them the source repository link, e.g.
 http://maven.apache.org/plugins/maven-compiler-plugin/source-repository.html,
 on the automatically generated web pages. To me this is better as they
 can then create patches.

 Does that make sense?

 The point is that the ASF release source, and it must be provided for
 download via the ASF mirrors.

 See:

 http://www.apache.org/dev/release.html#host-GA

 If you don't point users to the source, I don't see how you can claim

Re: Download links for source packages - where are they?

[Barrie Treloar]

On 26 June 2013 10:48, sebb seb...@gmail.com wrote:
 The point is that the ASF release source, and it must be provided for
 download via the ASF mirrors.

 See:

 http://www.apache.org/dev/release.html#host-GA

 If you don't point users to the source, I don't see how you can claim
 it has been properly released.

Which part of http://www.apache.org/dev/release.html#host-GA do you
think we are violating?
Releases are available via http://archive.apache.org/dist/maven/plugins/

We meet Project download pages must link to the mirrors for the
Maven Core Project - but not the plugins.

I can find no documentation that says you *must* provide a download page.
Just that if there is a download page it must point to the mirrors.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Errors in download links on maven.apache.org

[Marko Elezovic]

Hello everyone!

For some reason, there are a lot of links on the 
http://maven.apache.org/download.cgi webpage with improper protocol/uri:


For instance, the links in the Maven 3.0.4/2.2.1 (Source tar.gz) and 
(Binary zip) downloads contain an extraneous http// segment

http://http//www.us.apache.org/dist/maven/maven-2/2.2.1/binaries/apache-maven-2.2.1-bin.zip

Regards,
Marko

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Errors in download links on maven.apache.org

[Brett Porter]

Fixed - thanks for the report!

- Brett

On 05/01/2013, at 2:13 AM, Marko Elezovic ma...@element.hr wrote:

 Hello everyone!
 
 For some reason, there are a lot of links on the 
 http://maven.apache.org/download.cgi webpage with improper protocol/uri:
 
 For instance, the links in the Maven 3.0.4/2.2.1 (Source tar.gz) and (Binary 
 zip) downloads contain an extraneous http// segment
 http://http//www.us.apache.org/dist/maven/maven-2/2.2.1/binaries/apache-maven-2.2.1-bin.zip
 
 Regards,
 Marko
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 

--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: 2.0.6 download links broken

[Henning P. Schmiedehausen]

Wendy Smoak [EMAIL PROTECTED] writes:

Congrats, you just found the reason why for the Velocity site, I added
an extra directory where the filtered templates are located.

Is there any documentation on how to use these filters? Is it just
all files pass through Velocity or can one control it?

Best regards
Henning


On 4/2/07, Brett Porter [EMAIL PROTECTED] wrote:

  I'm getting errors and stack traces from Velocity.  Is there a way to
  tell it not to filter certain files?  The files it's complaining about
  are release-notes.apt, guide-bash-m2-completion.apt.

 The second can be ignored. I don't know about the first - it must
 have been one of your additions.

Yep, it's complaining about this line:

 * [MNG-2339] - $project.* are interpreted in the wrong place

-- 
Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-- 
Henning P. Schmiedehausen  -- [EMAIL PROTECTED] | J2EE, Linux,   
|gls
91054 Buckenhof, Germany   -- +49 9131 506540  | Apache person  |eau
Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc
|m k
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s
Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n

   Save the cheerleader. Save the world.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

2.0.6 download links broken

[Wendy Smoak]

I published the site to update the release notes, and someone on irc
pointed out that the download links are broken:

  http://maven.apache.org/download.html

Any ideas?  I just did 'mvn site' and 'mvn site:deploy'.

--
Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 2.0.6 download links broken

[Jason van Zyl]

On 2 Apr 07, at 5:57 PM 2 Apr 07, Wendy Smoak wrote:


I published the site to update the release notes, and someone on irc
pointed out that the download links are broken:

  http://maven.apache.org/download.html

Any ideas?  I just did 'mvn site' and 'mvn site:deploy'.



Requires trunk of the site plugin.

jason.


--
Wendy

-
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]

Re: 2.0.6 download links broken

[Wendy Smoak]

On 4/2/07, Jason van Zyl [EMAIL PROTECTED] wrote:


Requires trunk of the site plugin.


Okay.  I deployed another snapshot of the site plugin, it was only a
couple of days old but before that, 'mvn site -U' didn't seem to work.

I'm getting errors and stack traces from Velocity.  Is there a way to
tell it not to filter certain files?  The files it's complaining about
are release-notes.apt, guide-bash-m2-completion.apt.

Since everything else is controlled by directory name and file
extension, what about the suggestion (Brett's?) of using .vm for the
files you want it to filter?

--
Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 2.0.6 download links broken

[Brett Porter]

On 03/04/2007, at 12:17 PM, Wendy Smoak wrote:


On 4/2/07, Jason van Zyl [EMAIL PROTECTED] wrote:


Requires trunk of the site plugin.


Okay.  I deployed another snapshot of the site plugin, it was only a
couple of days old but before that, 'mvn site -U' didn't seem to work.


Hmm, I deployed one just yesterday specifically for this...



I'm getting errors and stack traces from Velocity.  Is there a way to
tell it not to filter certain files?  The files it's complaining about
are release-notes.apt, guide-bash-m2-completion.apt.


The second can be ignored. I don't know about the first - it must  
have been one of your additions.




Since everything else is controlled by directory name and file
extension, what about the suggestion (Brett's?) of using .vm for the
files you want it to filter?


I think Jason earlier said he's going to make a proposition or two  
for making it optional before the next release.


I'll put it in JIRA now...

...

http://jira.codehaus.org/browse/MSITE-223

Cheers,
Brett


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 2.0.6 download links broken

[Wendy Smoak]

On 4/2/07, Brett Porter [EMAIL PROTECTED] wrote:


 I'm getting errors and stack traces from Velocity.  Is there a way to
 tell it not to filter certain files?  The files it's complaining about
 are release-notes.apt, guide-bash-m2-completion.apt.

The second can be ignored. I don't know about the first - it must
have been one of your additions.


Yep, it's complaining about this line:

* [MNG-2339] - $project.* are interpreted in the wrong place

--
Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (MAVEN-113) Add download links to all plugin versions on the download page

[jira]

Message:

   The following issue has been closed.

   Resolver: Brett Porter
   Date: Mon, 28 Jun 2004 9:22 PM

done
-
View the issue:
  http://jira.codehaus.org/browse/MAVEN-113

Here is an overview of the issue:
-
Key: MAVEN-113
Summary: Add download links to all plugin versions on the download page
   Type: Improvement

 Status: Closed
   Priority: Minor
 Resolution: FIXED

 Original Estimate: 4 hours
 Time Spent: Unknown
  Remaining: 4 hours

Project: maven

   Assignee: 
   Reporter: dion gillard

Created: Thu, 19 Sep 2002 5:27 AM
Updated: Mon, 28 Jun 2004 9:22 PM
Environment: N/A

Description:
There is currently no easy way to know which versions of plugins are available @ 
ibiblio. It'd be nice if the download page listed the plugins (all versions) available 
for download.

This could be a generated page using the plugin's versions tag


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]