On Mon, Apr 18, 2016 at 3:28 PM, sebb wrote:
> On 18 April 2016 at 22:27, Stian Soiland-Reyes wrote:
> > Well, if we move to the new layout without binaries/ and sources/
> > subfolders, (see other thread), then the filenames should include -src
> and
> > -bin so it is obvious which is which.
>
Sorry, my mistake.
Feel free to revert (I'm not very familiar with Git)
On 19 April 2016 at 00:38, Gilles wrote:
> Hi.
>
> Is there a reason why those changes were done in "master" rather than
> "develop"?
>
> Regards,
> Gilles
>
> On Mon, 18 Apr 2016 23:22:35 + (UTC), s...@apache.org wrote:
On 19 April 2016 at 00:02, Stian Soiland-Reyes wrote:
> Sorry, I'll have to change that to -1 as the pom fails with Java 6 and
> Maven 3.0.5
Not sure we can do anything about that.
Nor is it necessary, as that is why the java-1.x profiles exist.
It's also not a regression; CP39 (and earlier) ha
Hi.
Is there a reason why those changes were done in "master" rather than
"develop"?
Regards,
Gilles
On Mon, 18 Apr 2016 23:22:35 + (UTC), s...@apache.org wrote:
Repository: commons-math
Updated Branches:
refs/heads/master 050dfa6f0 -> 5bbd826e2
Standard Maven directory layout
Projec
Sorry, I'll have to change that to -1 as the pom fails with Java 6 and
Maven 3.0.5
Caused by: java.lang.UnsupportedClassVersionError:
org/codehaus/mojo/buildhelper/ParseVersionMojo : Unsupported
major.minor version 51.
[ERROR] Failed to execute goal
org.codehaus.mojo:build-helper-maven-plugin:1.10
Vote: 0 (non-binding)
+1 Signatures, hashes
+1 mvn apache-rat:check :)
+1 mvn install
+1 mvn -Prelease release:prepare -DdryRun=true on commons rdf using 40
as parent (but see below)
-1 No archive for https://dist.apache.org/repos/dist/release/commons/
-1 Not using latest commons-skin 4.1
This
On 18 April 2016 at 22:27, Stian Soiland-Reyes wrote:
> Well, if we move to the new layout without binaries/ and sources/
> subfolders, (see other thread), then the filenames should include -src and
> -bin so it is obvious which is which.
It's still possible to tell them apart; only the source ha
On 18 April 2016 at 22:16, Stian Soiland-Reyes wrote:
> On 18 Apr 2016 4:47 p.m., "sebb" wrote:
>
>> Using lazy votes for this was was agreed by the PMC a while back.
>
> Ah, I thought as it had its own website,
It has a page on the main website, like Commons Parent.
> (earlier) downloads
I'd
Well, if we move to the new layout without binaries/ and sources/
subfolders, (see other thread), then the filenames should include -src and
-bin so it is obvious which is which.
In most (modern) cases such dist files are made by the assembly plugin from
Maven, in which case that config needs to b
Hi,
Chen, Haifeng schrieb am Mo., 18. Apr. 2016 um
08:38 Uhr:
> Hi folks,
> I have configured the versions and components for the JIRA project for
> Apache Commons Crypto.
>
> And I also commented in https://issues.apache.org/jira/browse/INFRA-11627
> to ask Daniel to lift the lock on the git re
On 18 Apr 2016 4:48 p.m., "sebb" wrote:
> > (I would still say -1 until the RC is on dist.apache.org)
>
> I'm not convinced it's necessary.
Agreed, as you have provided hashes, so its not necessary to upload also to
dev/commons on dist, although that is the practice for other component
release ca
On 18 Apr 2016 4:47 p.m., "sebb" wrote:
> Using lazy votes for this was was agreed by the PMC a while back.
Ah, I thought as it had its own website, (earlier) downloads and Maven
Central artifacts it was one of the releases of Apache Commons.
Perhaps if it is only for internal project use it sh
Hi Stian,
Stian Soiland-Reyes wrote:
> These downloads lack -bin / -src suffixes:
>
> On 18 April 2016 at 10:43, Stian Soiland-Reyes wrote:
>> stain@biggie:~/Downloads/912/mirrors.ukfast.co.uk/sites/ftp.apache.org$
>> find . -type f | grep -v txt | grep -v -- -src.tar.gz | grep -v --
>> -src.z
It reports that it is a issue in DefaultParser but the same issue can be
seen in Basic Parser which is a depreciated class. Should it be considered
as a issue?
Thank You
Pushback on the naming convention.
On 17 April 2016 at 15:16, sebb wrote:
> This is a VOTE by LAZY consensus to release Commons Build Plugin 1.6
> based on RC1
>
> The changes from 1.5 are:
>
> Added new download-page layout property:
>set this to 'version' to use a single directory of the fo
On 18 April 2016 at 13:53, Stian Soiland-Reyes wrote:
> On 18 April 2016 at 13:43, Stian Soiland-Reyes wrote:
>
>> -1 apache-rat:check fails on
>> src/main/resources/commons-xdoc-templates/download-page-body.xml and
>> src/main/resources/commons-xdoc-templates/download-page-foot.xml
>
>
> These a
On 18 April 2016 at 13:43, Stian Soiland-Reyes wrote:
> I don't think we can do lazy release votes (even for an "internal" component):
>
> http://www.apache.org/dev/release.html#approving-a-release
Using lazy votes for this was was agreed by the PMC a while back.
>
> I notice this RC is 'straigh
On 18 April 2016 at 13:31, Stian Soiland-Reyes wrote:
> These downloads lack -bin / -src suffixes:
>
> On 18 April 2016 at 10:43, Stian Soiland-Reyes wrote:
>> stain@biggie:~/Downloads/912/mirrors.ukfast.co.uk/sites/ftp.apache.org$
>> find . -type f | grep -v txt | grep -v -- -src.tar.gz | grep
On 18 April 2016 at 13:43, Stian Soiland-Reyes wrote:
> -1 apache-rat:check fails on
> src/main/resources/commons-xdoc-templates/download-page-body.xml and
> src/main/resources/commons-xdoc-templates/download-page-foot.xml
These are not really XML files, but templates to be inserted in XML
file
I don't think we can do lazy release votes (even for an "internal" component):
http://www.apache.org/dev/release.html#approving-a-release
I notice this RC is 'straight to Maven' - but this should also be released to
https://dist.apache.org/repos/dist/release/commons/commons-build-plugin/source/
These downloads lack -bin / -src suffixes:
On 18 April 2016 at 10:43, Stian Soiland-Reyes wrote:
> stain@biggie:~/Downloads/912/mirrors.ukfast.co.uk/sites/ftp.apache.org$
> find . -type f | grep -v txt | grep -v -- -src.tar.gz | grep -v --
> -src.zip | grep -v -- -bin.zip | grep -v -- -bin.tar.g
For the download distributions, we might want to include the "apache-"
file prefix for trademark
reasons - as advocated to all incubator projects.
e.g.
/commons/lang/3.4/apache-commons-lang3-3.4-src.tar.gz
unpacking to:
apache-commons-lang3-3.4/pom.xml
apache-commons-lang3-3.4/src
etc
On 1
Le 18/04/2016 12:56, sebb a écrit :
> Why is that?
Because there is no reason to use the Maven artifactId here, the
distribution directory isn't a Maven repository. That's the same
reasoning for the -bin and -src files, commons-lang3-3.4 can be mistaken
for commons-lang 3.3.4.
Emmanuel Bourg
-
On 18 April 2016 at 07:53, Emmanuel Bourg wrote:
> Le 16/04/2016 01:02, sebb a écrit :
>
>> It would look like:
>>
>> lang/commons-lang-2.6/commons-lang-2.6-[bin|src].*
>> lang/commons-lang3-3.4/commons-lang3-3.4-[bin|src].*
>
> It we change the layout I'd prefer using the component name instead o
Adding -bin to artifact names is a separate issue, please start a new thread.
On 18 April 2016 at 10:43, Stian Soiland-Reyes wrote:
> Ah - as long as the INFRA and Mirror guys are OK with the potentially
> extra 500 MB then that sounds good!
>
> I've raised
> https://issues.apache.org/jira/browse
On 18 April 2016 at 10:59, Gilles wrote:
> On Mon, 18 Apr 2016 10:45:28 +0100, Stian Soiland-Reyes wrote:
>>
>> We might also want to include the "apache-" file prefix for trademark
>> reasons - as advocated to all incubator projects.
>>
>> e.g.
>>
>> /commons/lang/3.4/apache-commons-lang3-3.4-src
On Mon, 18 Apr 2016 10:45:28 +0100, Stian Soiland-Reyes wrote:
We might also want to include the "apache-" file prefix for trademark
reasons - as advocated to all incubator projects.
e.g.
/commons/lang/3.4/apache-commons-lang3-3.4-src.tar.gz
That certainly makes a lot of sense, also to avoid
We might also want to include the "apache-" file prefix for trademark
reasons - as advocated to all incubator projects.
e.g.
/commons/lang/3.4/apache-commons-lang3-3.4-src.tar.gz
On 18 April 2016 at 10:40, Gilles wrote:
> On Mon, 18 Apr 2016 11:18:49 +0200, Emmanuel Bourg wrote:
>>
>> Le 18/
Ah - as long as the INFRA and Mirror guys are OK with the potentially
extra 500 MB then that sounds good!
I've raised
https://issues.apache.org/jira/browse/INFRA-11702
to enquire how we should best do it.
BTW - the -bin and -src suffixes are quite consistent across the
boards. These are the onl
On Mon, 18 Apr 2016 11:18:49 +0200, Emmanuel Bourg wrote:
Le 18/04/2016 10:48, Gilles a écrit :
IIRC, I was once corrected that this is not the component's name
(which
in this case would be "Apache Commons Lang").
That's consistent with the site URL though:
http://commons.apache.org/prope
On Mon, 18 Apr 2016 10:22:53 +0100, Stian Soiland-Reyes wrote:
Changing download links for all existing releases (without a new
release)
sounds worse than having slightly inconsistent paths for a while.
I did not suggest to _delete_ anything.
Just that current archives should be accessible thr
Le 18/04/2016 10:48, Gilles a écrit :
> IIRC, I was once corrected that this is not the component's name (which
> in this case would be "Apache Commons Lang").
That's consistent with the site URL though:
http://commons.apache.org/proper/commons-lang/
An alternative would be to use the version
Changing download links for all existing releases (without a new release)
sounds worse than having slightly inconsistent paths for a while.
Moving the existing releases would also cause duplicates on
archive.apache.org (unless we ask INFRA to reorganise this as well, which
would break even permali
On Mon, 18 Apr 2016 08:53:10 +0200, Emmanuel Bourg wrote:
Le 16/04/2016 01:02, sebb a écrit :
It would look like:
lang/commons-lang-2.6/commons-lang-2.6-[bin|src].*
lang/commons-lang3-3.4/commons-lang3-3.4-[bin|src].*
It we change the layout I'd prefer using the component name instead
of
t
On Mon, 18 Apr 2016 09:12:16 +0100, Stian Soiland-Reyes wrote:
+1 for the change for future releases. Being able to do svn mv (or
rm) on a
single folder simplifies releasing and reduces chance of errors.
I think that your remark below calls for making the changes for all
components right now.
+1 for the change for future releases. Being able to do svn mv (or rm) on a
single folder simplifies releasing and reduces chance of errors.
Is the -src and -bin endings already used across all of Commons? That would
be a bit more important without source/ and binaries/
(Do some have download art
36 matches
Mail list logo
