Re: [LANG] Jenkins Pipeline DSL

[sebb]

On Sun, 3 Mar 2019 at 13:28, Benedikt Ritter  wrote:
>
> Hi all,
>
> here is my proposal for a Jenkins Pipeline file for Commons Lang:
> https://github.com/apache/commons-lang/pull/410
> Please review and comment.

It looks OK to me, but I think we need to see it in action.

For example, what about notifications for failed builds - is that
maintained in Jenkins or in the pipeline file?

> Benedikt
>
> Am Mi., 20. Feb. 2019 um 11:40 Uhr schrieb Benedikt Ritter <
> brit...@apache.org>:
>
> > I'm happy about the positive feedback. I'm currently a little bit busy at
> > work. I hope to be able to spike something at the end of next week.
> >
> > Benedikt
> >
> > Am Mo., 18. Feb. 2019 um 20:25 Uhr schrieb Matt Sicker :
> >
> >> The DSL allows you to break out into parallel stages or sequential
> >> ones (or both). The log4net Jenkinsfile has an example of building
> >> across multiple agents:
> >>
> >>
> >> https://github.com/apache/logging-log4net/blob/feature/cd-pipeline/Jenkinsfile
> >>
> >> On Mon, 18 Feb 2019 at 12:44, sebb  wrote:
> >> >
> >> > Seems worth trying.
> >> >
> >> > I suggest start with one project (i.e. Lang) and see how well it works.
> >> >
> >> > I assume there will need to be a once-off change to Jenkins to switch
> >> > to using the DSL.
> >> >
> >> > Note that some components have multiple jobs, e.g. for different OSes
> >> and JVMs.
> >> > Does the DSL support such jobs? Or is that still done through the GUI?
> >> >
> >> > S.
> >> >
> >> > On Mon, 18 Feb 2019 at 18:05, Matt Sicker  wrote:
> >> > >
> >> > > +1. You could also make a shared library for reuse in commons
> >> projects.
> >> > >
> >> > > On Sun, 17 Feb 2019 at 14:41, Pascal Schumacher
> >> > >  wrote:
> >> > > >
> >> > > > +1 to using a pipeline
> >> > > >
> >> > > > Am 17.02.2019 um 18:35 schrieb Benedikt Ritter:
> >> > > > > Hi all,
> >> > > > >
> >> > > > > I feel like maintaining separate build descriptions on Jenkins is
> >> a PITA.
> >> > > > > Any objections against adopting Jenkins Pipeline DSL for Lang?
> >> > > > >
> >> > > > > Regards,
> >> > > > > Benedikt
> >> > > > >
> >> > > >
> >> > > >
> >> > > >
> >> -
> >> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> >> > > >
> >> > >
> >> > >
> >> > > --
> >> > > Matt Sicker 
> >> > >
> >> > > -
> >> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> > > For additional commands, e-mail: dev-h...@commons.apache.org
> >> > >
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> > For additional commands, e-mail: dev-h...@commons.apache.org
> >> >
> >>
> >>
> >> --
> >> Matt Sicker 
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>

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

Re: [ALL][RFC] Github subjects don't contain the repo name

[sebb]

This has now been implemented.

Unfortunately Infra did not agree to remove the [GitHub] prefix.

On Sat, 2 Mar 2019 at 09:19, sebb  wrote:
>
> Created https://issues.apache.org/jira/browse/INFRA-17940
>
> On Sat, 2 Mar 2019 at 08:39, Stefan Bodewig  wrote:
> >
> > On 2019-03-01, sebb wrote:
> >
> > > [GitHub] (commons-io) zsoltii opened a new pull request #74: Add new
> > > function: byteCountToDisplayRoundedSize
> >
> > > WDYT?
> >
> > I don't really care for the exact subject as long as the name of the
> > repo gets added :-)
> >
> > +1
> >
> > Stefan
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >

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

Re: [LANG] Jenkins Pipeline DSL

[sebb]

On Mon, 4 Mar 2019 at 09:47, Benedikt Ritter  wrote:
>
> Am So., 3. März 2019 um 14:57 Uhr schrieb sebb :
>
> > On Sun, 3 Mar 2019 at 13:28, Benedikt Ritter  wrote:
> > >
> > > Hi all,
> > >
> > > here is my proposal for a Jenkins Pipeline file for Commons Lang:
> > > https://github.com/apache/commons-lang/pull/410
> > > Please review and comment.
> >
> > It looks OK to me, but I think we need to see it in action.
> >
> > For example, what about notifications for failed builds - is that
> > maintained in Jenkins or in the pipeline file?
> >
>
> I will add notification. The PLC4X Project has a good example for that:
> https://github.com/apache/incubator-plc4x/blob/develop/Jenkinsfile

Thanks.

Sending emails looks really long-winded compared with the Jenkins UI.
Easy to get things wrong; harder to maintain.

>
> >
> > > Benedikt
> > >
> > > Am Mi., 20. Feb. 2019 um 11:40 Uhr schrieb Benedikt Ritter <
> > > brit...@apache.org>:
> > >
> > > > I'm happy about the positive feedback. I'm currently a little bit busy
> > at
> > > > work. I hope to be able to spike something at the end of next week.
> > > >
> > > > Benedikt
> > > >
> > > > Am Mo., 18. Feb. 2019 um 20:25 Uhr schrieb Matt Sicker <
> > boa...@gmail.com>:
> > > >
> > > >> The DSL allows you to break out into parallel stages or sequential
> > > >> ones (or both). The log4net Jenkinsfile has an example of building
> > > >> across multiple agents:
> > > >>
> > > >>
> > > >>
> > https://github.com/apache/logging-log4net/blob/feature/cd-pipeline/Jenkinsfile
> > > >>
> > > >> On Mon, 18 Feb 2019 at 12:44, sebb  wrote:
> > > >> >
> > > >> > Seems worth trying.
> > > >> >
> > > >> > I suggest start with one project (i.e. Lang) and see how well it
> > works.
> > > >> >
> > > >> > I assume there will need to be a once-off change to Jenkins to
> > switch
> > > >> > to using the DSL.
> > > >> >
> > > >> > Note that some components have multiple jobs, e.g. for different
> > OSes
> > > >> and JVMs.
> > > >> > Does the DSL support such jobs? Or is that still done through the
> > GUI?
> > > >> >
> > > >> > S.
> > > >> >
> > > >> > On Mon, 18 Feb 2019 at 18:05, Matt Sicker  wrote:
> > > >> > >
> > > >> > > +1. You could also make a shared library for reuse in commons
> > > >> projects.
> > > >> > >
> > > >> > > On Sun, 17 Feb 2019 at 14:41, Pascal Schumacher
> > > >> > >  wrote:
> > > >> > > >
> > > >> > > > +1 to using a pipeline
> > > >> > > >
> > > >> > > > Am 17.02.2019 um 18:35 schrieb Benedikt Ritter:
> > > >> > > > > Hi all,
> > > >> > > > >
> > > >> > > > > I feel like maintaining separate build descriptions on
> > Jenkins is
> > > >> a PITA.
> > > >> > > > > Any objections against adopting Jenkins Pipeline DSL for Lang?
> > > >> > > > >
> > > >> > > > > Regards,
> > > >> > > > > Benedikt
> > > >> > > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> -
> > > >> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > >> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> > > --
> > > >> > > Matt Sicker 
> > > >> > >
> > > >> > >
> > -
> > > >> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > >> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >> > >
> > > >> >
> > > >> >
> > -
> > > >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > >> > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >> >
> > > >>
> > > >>
> > > >> --
> > > >> Matt Sicker 
> > > >>
> > > >> -
> > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > >> For additional commands, e-mail: dev-h...@commons.apache.org
> > > >>
> > > >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

Re: [ALL] Avoiding duplication of work between GitHub PRs and JIRA

[sebb]

On Wed, 6 Mar 2019 at 13:54, Gary Gregory  wrote:
>
> Hi All:
>
> I'll start with this example from Commons VFS and its changes.xml:
>
>   
> Update Apache Commons Collections from 4.2 to 4.3.
>   
>
>   
> Add support for customizing FTP transfer aborted status codes.
> GitHub PR #51.
>   
>
> The first entry uses a JIRA reference as usual.
>
> In the second entry, I applied a PR from GitHub but I did not create a
> matching JIRA issue. The fact that we have a change is still tracked in
> changes.xml. The site report will not have a URL to JIRA.
>
> Question: Can we make the changes plugin generate a link to GitHub for a PR?

http://maven.apache.org/plugins/maven-changes-plugin/changes-report-mojo.html#issueLinkTemplatePerSystem

I don't think the plugin can support more that one type of URL
generation per pom.
It would need some way to distinguish different types of issues.
e.g. a different attribute name (gitpr) or an extra attribute to
qualify the issue type.

This is really a question for the Maven user list.

> Gary

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

Re: [Parent] RAT check

[sebb]

OK, but please provide a property to switch it off on the command-line.

I think it is going to be very annoying for local development,
especially if it runs at such an early phase.

It could also be done in a much later phase, e.g. verify
That would certainly be sufficient for RC creation.

On Sun, 10 Mar 2019 at 08:43, Pascal Schumacher
 wrote:
>
> +1
>
> Am 09.03.2019 um 23:44 schrieb Gary Gregory:
> > Hi all:
> >
> > How about making apache-rat:check run automatically in commons-parent? In
> > the Maven validate phase?
> >
> > That would mean one less thing to check when integrating a patch and
> > validating an RC.
> >
> > Gary
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

MD5/SHA1 links - make sure they are removed in component source!

[sebb]

DIGESTER-191 - md5 checksum: 404 Not Found
noted that the hash download links did not work.

It transpired that many of the commons download pages still linked to
the SHA1/MD5 hashes, even if these had been replaced on the download
site.

I think I have now fixed all the links - and dropped old md5/sha1
hashes that were not needed.

I did this by editting the SVN production website files to avoid
having to regenerate all the sites.
However I have not fixed all the source files, so please check that
the correct hashes are being generated and linked when republishing.

Thanks!
S

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

Re: MD5/SHA1 links - make sure they are removed in component source!

[sebb]

On Tue, 12 Mar 2019 at 09:11, Bernd Eckenfels  wrote:
>
> Is that change done here?
>
> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/

Yes, I have a local checkout of the top two levels (only) which makes
this very easy.

> Is there a Svn Web view where we can see the commit and check out what files 
> have been changed?

The changes were all sent to the notificati...@commons.apache.org list.

I don't know if there is a web view.

> Maybe we can also reduce the number of download links to mainly the mirror 
> scripts?

If you are talking about dropping the links to KEYS, hashes and sigs,
they are required
https://www.apache.org/dev/release-distribution#download-links

It must be easy for downloaders to fetch these files for verification purposes.

> Gruss
> Bernd
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
> 
> Von: sebb 
> Gesendet: Dienstag, März 12, 2019 9:56 AM
> An: CommonsDev
> Betreff: MD5/SHA1 links - make sure they are removed in component source!
>
> DIGESTER-191 - md5 checksum: 404 Not Found
> noted that the hash download links did not work.
>
> It transpired that many of the commons download pages still linked to
> the SHA1/MD5 hashes, even if these had been replaced on the download
> site.
>
> I think I have now fixed all the links - and dropped old md5/sha1
> hashes that were not needed.
>
> I did this by editting the SVN production website files to avoid
> having to regenerate all the sites.
> However I have not fixed all the source files, so please check that
> the correct hashes are being generated and linked when republishing.
>
> Thanks!
> S
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: MD5/SHA1 links - make sure they are removed in component source!

[sebb]

On Tue, 12 Mar 2019 at 09:52, Bernd Eckenfels  wrote:
>
> Hello,
>
> I was only looking on the commit mailing list, found it on notify, thanks.
>
> You did not explicitely mention it, but it looks like you only had to change 
> download pages, so my comment about removing the links anywhere else is I 
> guess moot.
>
> BTW the (Imaging] Download (still) points to incubator, are we planning to 
> change this?

Please start a new thread for a new issue, thanks!

> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> Von: sebb 
> Gesendet: Dienstag, März 12, 2019 10:37 AM
> An: Commons Developers List
> Betreff: Re: MD5/SHA1 links - make sure they are removed in component source!
>
> On Tue, 12 Mar 2019 at 09:11, Bernd Eckenfels  wrote:
> >
> > Is that change done here?
> >
> > https://svn.apache.org/repos/infra/websites/production/commons/content/proper/
>
> Yes, I have a local checkout of the top two levels (only) which makes
> this very easy.
>
> > Is there a Svn Web view where we can see the commit and check out what 
> > files have been changed?
>
> The changes were all sent to the notificati...@commons.apache.org list.
>
> I don't know if there is a web view.
>
> > Maybe we can also reduce the number of download links to mainly the mirror 
> > scripts?
>
> If you are talking about dropping the links to KEYS, hashes and sigs,
> they are required
> https://www.apache.org/dev/release-distribution#download-links
>
> It must be easy for downloaders to fetch these files for verification 
> purposes.

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

Re: [RDF] Graduated from the Incubator but Releases remain in Incubator Dist SVN

[sebb]

On Thu, 14 Mar 2019 at 18:02, Dave Fisher  wrote:
>
> Hi -
>
> You still have Commons RDF releases in the Incubator’s area of SVN - 
> https://dist.apache.org/repos/dist/release/incubator/ 
> 
>
> Please plan to move or remove these soon.

Removed

> Thank you!
>
> Regards,
> Dave

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

Re: [codec] Java 8

[sebb]

I see no reason to update to Java 8 unless continuing with Java 7
becomes a big hassle.

Why penalise people stuck on Java 7 unnecessarily?

On Fri, 22 Mar 2019 at 15:31, Rob Tompkins  wrote:
>
> That seems reasonable.
>
> > On Mar 22, 2019, at 11:23 AM, Gary Gregory  wrote:
> >
> > This comes up from time to time and I can only offer my usual "if you want
> > support for a dead version of Java, feel free to provide a PR" We can
> > always provide 1.12.1 for Java 7 security fixes or other fixes deemed
> > important enough.
> >
> > Gary
> >
> >> On Fri, Mar 22, 2019 at 11:20 AM Rob Tompkins  wrote:
> >>
> >> +1, but there are considerable projects out there that would want us to
> >> maintain backwards compatibility with Java 7.
> >>
> >>> On Mar 22, 2019, at 11:12 AM, Gary Gregory 
> >> wrote:
> >>>
> >>> Hi All,
> >>>
> >>> Now that Codec 1.12 is out, I plan on updating from Java 7 to Java 8.
> >>>
> >>> Gary
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [codec] Java 8

[sebb]

On Fri, 22 Mar 2019 at 18:56, Gary Gregory  wrote:
>
> On Fri, Mar 22, 2019 at 2:53 PM sebb  wrote:
>
> > I see no reason to update to Java 8 unless continuing with Java 7
> > becomes a big hassle.
> >
> > Why penalise people stuck on Java 7 unnecessarily?
> >
>
> I see it the other way around: Why do we want to handcuff new development
> on a dead platforms? For new contributors, this is a huge turn off.

Code written for Java 7 still runs on Java 8+
Java 7 is not dead in that sense.

> Gary
>
>
> > On Fri, 22 Mar 2019 at 15:31, Rob Tompkins  wrote:
> > >
> > > That seems reasonable.
> > >
> > > > On Mar 22, 2019, at 11:23 AM, Gary Gregory 
> > wrote:
> > > >
> > > > This comes up from time to time and I can only offer my usual "if you
> > want
> > > > support for a dead version of Java, feel free to provide a PR" We can
> > > > always provide 1.12.1 for Java 7 security fixes or other fixes deemed
> > > > important enough.
> > > >
> > > > Gary
> > > >
> > > >> On Fri, Mar 22, 2019 at 11:20 AM Rob Tompkins 
> > wrote:
> > > >>
> > > >> +1, but there are considerable projects out there that would want us
> > to
> > > >> maintain backwards compatibility with Java 7.
> > > >>
> > > >>> On Mar 22, 2019, at 11:12 AM, Gary Gregory 
> > > >> wrote:
> > > >>>
> > > >>> Hi All,
> > > >>>
> > > >>> Now that Codec 1.12 is out, I plan on updating from Java 7 to Java 8.
> > > >>>
> > > >>> Gary
> > > >>
> > > >> -
> > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > >> For additional commands, e-mail: dev-h...@commons.apache.org
> > > >>
> > > >>
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

Re: [all] What versions of java do we support?

[sebb]

On Fri, 22 Mar 2019 at 21:27, Matt Sicker  wrote:
>
> Ensuring projects are source compatible with 1.8 but buildable and
> usable using Java 11 or whatever the latest release is at the time
> (currently 12) seems like a good compromise for most of the libraries.
> I wouldn't require 9+ in anything unless it's pointless for earlier
> releases of Java or if it's necessary to continue the logical path of
> development by supporting new APIs.

I would go a bit further and say it's counter-productive to update to
a new version of Java just for the sake of it.
If extensive changes are being made, and these require the next
version, then OK.

But updating to the next version of Java and only making a few minor
changes before the next release seems wrong.

Note that Oracle extended support for Java 6 only just ended (Dec 2018)
Java 7 has extended support until July 2022.

https://www.oracle.com/technetwork/java/java-se-support-roadmap.html


> On Fri, 22 Mar 2019 at 07:30, Gary Gregory  wrote:
> >
> > On Thu, Mar 21, 2019 at 10:29 PM Rob Tompkins  wrote:
> >
> > >
> > >
> > > > On Mar 21, 2019, at 10:22 PM, Bernd Eckenfels 
> > > wrote:
> > > >
> > > > Nearly all vendors I have seen announced to follow voluntarily or
> > > commercial guaranteed the OpenJDK LTS versions (11, some 8) (Redhat,
> > > adoptopenjdk, Azul, ojdkbuild, sapengine, Amazon, Ubuntu/Debian, suse).
> > > Actually only Oracle‘s OpenJDK is not.
> > > >
> > >
> > > Cool. Then pardon my being tied to a vendor.
> > >
> > > Regardless, I suppose the question remains the same though right? We
> > > should be compatible with both 8 and 11.
> > >
> >
> > I think we should generalize this to Oracle and anyone's LTS version for
> > Java >= 8.
> >
> > Gary
> >
> >
> > > -Rob
> > >
> > > > Gruss
> > > > Bernd
> > > > --
> > > > http://bernd.eckenfels.net
> > > >
> > > > 
> > > > Von: Rob Tompkins 
> > > > Gesendet: Freitag, März 22, 2019 2:59 AM
> > > > An: Commons Developers List
> > > > Betreff: Re: [all] What versions of java do we support?
> > > >
> > > > Is there LTS with those other imolementations?
> > > >
> > > >> On Mar 21, 2019, at 9:43 PM, Ralph Goers 
> > > wrote:
> > > >>
> > > >> Why are you singling out Corretto? What about AdoptOpenJDK or RedHat’s
> > > OpenJDK support? The ASF is supposed to be vendor neutral.
> > > >>
> > > >> Ralph
> > > >>
> > > >>> On Mar 21, 2019, at 11:05 AM, Rob Tompkins  wrote:
> > > >>>
> > > >>> Hello all,
> > > >>>
> > > >>> I would think that with the Amazon Corretto play at long term support
> > > for java 8 and 11 we would want to build using the latest version of the
> > > Corretto 8-JDK, and we would want to ensure that we work for Java 11.
> > > Regarding later versions of Java I’m a tad agnostic currently as we are
> > > less certain with their stability.
> > > >>>
> > > >>> What are folks’ thoughts?
> > > >>>
> > > >>> -Rob
> > > >>> -
> > > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > >>> For additional commands, e-mail: dev-h...@commons.apache.org
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >> -
> > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > >> For additional commands, e-mail: dev-h...@commons.apache.org
> > > >>
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
>
>
>
> --
> Matt Sicker 
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Confluence space (was: GitHub Pull Requests (and Confluence))

[sebb]

On Mon, 25 Mar 2019 at 15:32, Jochen Wiedmann  wrote:
>
> Which reminds me: Do we have a Confluence space? If not: Would anyone
> mind, if I asked for one on Jira?

Remember that Moin Moin is being withdrawn.
There is quite a large Commons Wiki on it; maybe that should be
migrated rather than starting again?

As to creating Confluence Wikis, that is self-service.

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

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

Re: [codec] Java 8

[sebb]

On Tue, 26 Mar 2019 at 19:01, Matt Sicker  wrote:
>
> I'd like to know what developers are both stuck in Java 7 (or earlier)
> and also have the liberty to upgrade any of their dependencies
> regardless of compatibility concerns. My thoughts are that being stuck
> in the past for one dependency tends to leak into every other
> dependency for the same underlying reasons.

There is a big difference between upgrading the JVM and upgrading one
or two dependencies.

It's much easier to test against a new version of a single dependency
than to test against a new version of Java.

Changing JVM is akin to asking a business to upgrade from Windows 7 to
Windows 8 just to use an updated version of one application on a
system that has many other apps that rely on Windows 7.

> On Sat, 23 Mar 2019 at 06:27, Pascal Schumacher
>  wrote:
> >
> >
> >
> > Am 22. März 2019 19:56:29 MEZ schrieb Gary Gregory :
> > >On Fri, Mar 22, 2019 at 2:53 PM sebb  wrote:
> > >
> > >> I see no reason to update to Java 8 unless continuing with Java 7
> > >> becomes a big hassle.
> > >>
> > >> Why penalise people stuck on Java 7 unnecessarily?
> > >>
> > >
> > >I see it the other way around: Why do we want to handcuff new
> > >development
> > >on a dead platforms? For new contributors, this is a huge turn off.
> >
> > +1
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> --
> Matt Sicker 
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [CLI] Option arguments without - or --

[sebb]

On Fri, 29 Mar 2019 at 07:04, Amey Jadiye  wrote:
>
> Hi,
>
> Looks like the functionality is not present in the code base.
>
> I'm proposing the SimpleCommandParser which can implement CommandLineParser
> for achieving below requirements. let me know your thoughts on this.

Thanks for the suggestion.

However, unless I have misunderstood the requirement, parsing looks to
be trivial and not worth the additional effort of creating and
maintaining library code.

It also seems to be a very uncommon use case, so I doubt that many
people would use the code.

> Regards,
> Amey
>
> On Wed, Mar 27, 2019 at 11:32 AM Amey Jadiye  wrote:
>
> > Hi,
> >
> > I'm developing a console application and required to get the command and
> > argument in non traditional fashion where command name dont start with
> > -name=value or --name=value.
> >
> > I expect the cli library should handle in below fashion
> >
> > Push 1 2 3 4
> > Pull 5 8 9
> >
> > Where push and Pull is command proceed with their arguments.
> >
> > I searched the library but didn't found such option, does anyone know how
> > to achieve this with Apache Commons CLI ?
> >
> > If this functionality is not present I can contribute in couple of weeks.
> >
> > Regards,
> > Amey
> >
> >
>
> --
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>
> For additional commands, e-mail: dev-h...@commons.apache.org

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

Re: [all] Should we use MathJaX in Javadoc on all repos? (Was: Re: [jira] [Commented] (NUMBERS-58) Javadoc: Use MathJaX)

[sebb]

On Tue, 12 Mar 2019 at 12:28, Rob Tompkins  wrote:
>
> For those unfamiliar with MathJaX, is the javascript mechanism for 
> accommodating for LaTeX (the math typesetting language, written by Donald 
> Knuth) in html.
>
> It could be convenient to use mathematical notation in our javadoc generally. 
> That said, Java doesn’t do this so it would indeed be non-standard. My 
> opinion is in the +0.5 zone currently.
>
> Thoughts?
>

Is it likely that existing Javadoc comments will trigger MathJaX?
That would perhaps mean lots of changes just to stay still.

What does it look like if JavaScript is not in use?

I think it would be sensible for the processing to be optional, e.g.
via a marker file.

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

Re: [VOTE] Release Apache Commons Pool 2.6.2 based on RC1

[sebb]

On Sat, 6 Apr 2019 at 03:15, Gary Gregory  wrote:
>
> We have fixed a few bugs since Apache Commons Pool 2.6.1 was released, so I
> would like to release Apache Commons Pool 2.6.2.
>
> Apache Commons Pool 2.6.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/pool/2.6.2-RC1 (svn
> revision 33480)
>
> The Git tag commons-pool-2.6.2-RC1 commit for this RC is
> 06de412e2ce72007a6e43112164c371de4a66d3b which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-pool.git;a=commit;h=06de412e2ce72007a6e43112164c371de4a66d3b
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-pool.git -b
> commons-pool-2.6.2-RC1 commons-pool-2.6.2-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1432/org/apache/commons/commons-pool2/2.6.2/
>
> These are the Maven artifacts and their hashes in Nexus:
>
> #Release SHA-512s
> #Fri Apr 05 21:23:42 EDT 2019
> commons-pool2-2.6.2-test-sources-java-source=7494677ccb265bca20fa61fd143f8a5f2e518653926c9a8ca5b33a6b379f9c9c5c262613839ff722200c7053356cbf6fb3a436823c4d6bf504dce4782a206373

What is commons-pool2-2.6.2-test-sources-java-source ?

> commons-pool2-2.6.2-src-zip=86a8e77b6d50ab57c2e9374a6f1d1e3d66946e541f90eacc822126026901ba4f172ddb0549f101c62757cb0389e23751063bb0e97128699aa9d8a7b8c5ebbd7a
> commons-pool2-2.6.2-sources-java-source=7984cabeda669cb84d54dc65cfe8992ee73bc87b9cb32853482649fe3bb09062f48ee3fe739ec141dad17c071853d6a8ef2ad4a738ceb532b71d49722fa914d0

Ditto commons-pool2-2.6.2-sources-java-source ?

> commons-pool2-2.6.2-pom.asc=0c2aa02dbac198db0b13d928130c258f1cf9f1e6432a2aedb3639401fb15b332245378cf439b735da61b024d2032ca889133586062cd01c548adcae5c57c82fa
> commons-pool2-2.6.2-tests-jar.asc=c4eab9e7200a9ef6577af29889982d60febf0534e7cddb57950049044ffaece22aacd1ced22aed0fc8c8a5236e5423afdfe445c0da517b9f5d6c33a4cc71e321
> commons-pool2-2.6.2-bin-zip.asc=66c004f5805eecf897bdf007d746489e1eaf74d484d6136b72bcac0a5654f45be351b83fe6015880c1581a8b143f913b29aff07462c28371e5e6483bf28e1687
> commons-pool2-2.6.2-src-tar.gz=a02f34c5e38bbcf2f1960cc1b89f468e6c4229b7d5f48b60044dd7a670d2a00eaab08fa8eca7b135b2696fe7a09824fcafe7ab3c4513716d1a4003f0bb3c0336
> commons-pool2-2.6.2-javadoc-jar.asc=97ab6e2ecf47ec356f8514d51325652468469e99d819769014dbbd1fe77830d27c4efbb4389116052369af5ccc18167a98a1dedda0243a2cf98942e98c05ba45
> commons-pool2-2.6.2-test-sources-jar.asc=141122c4aebb25f72d91f208d9b6912c0ecc1b1dedc41972ee281bc6b54c6222ff4993d5c8ad6ab939e5154109f226f67206bb34bed913c6ee00a76c9ba21260
> commons-pool2-2.6.2-bin-tar.gz.asc=67a787a210e787a1f74d0fa4af9c3708ed236c70aa4329e202d6bec0837b23a7779a72a358d02b7ee99d2a6d2eaaf8b01c0d7b2e404e742e9e8aca54bd0377fe
> commons-pool2-2.6.2-sources-jar.asc=ec62de6a0c294687abffe56a5faea5725e704b792593e7ea3a12b7837cccf476f69c70fe7d8f19ef67a7f1a6bb5f28cbbc239e37cd396caf530bcca7acf6057a
> commons-pool2-2.6.2-bin-tar.gz=8bf3b5bdd81c88761421e45ae8904e9718f152d09124880cf0acdcf08e7e64ab9a16eed23977f871bc8365801e3a7d4b1af254dd83fcdadca43520f7399b140e
> commons-pool2-2.6.2-javadoc-javadoc=31504dce4d3e7ef638dcdec1bcbef15467837cf80c21c3fc9a89abcaf2e04de6b2a33165ea3ac809ba3fa27410d7dc6dbe7bb1773b73f9045c73a8081a1f9e17

And javadoc-javadoc?

> commons-pool2-2.6.2-src-tar.gz.asc=61ae67fb0c9aa6e6760dfbe73c554642acace81a5f1cfa84cd5cdeab1ceb8fe122899514db185ef91920881a5ca9124e93c423f632bc02dd186705719a502eeb
> commons-pool2-2.6.2-src-zip.asc=523227eca9aac3fbb2dc118e1a7cc62f79541bc29362c4d3c0923e4f19f4dcb1e2562422e849f90243d840b32ff9ce9787df0491753c7f6b3d0667d95d53e666
> commons-pool2-2.6.2-tests-test-jar=c8f9df3a4b8c9eb291a173846cacbdf7d29aa0ba34936889ae825873d82cdfb25ed5e66f728260d1b64bee4d19e7256e3b0052eb099909a0baaa65027960ce81
> commons-pool2-2.6.2-jar.asc=fe3b932a97ca44c4c2c7a41b015b184d9e8d21ba2197f1157ba71f60808b735ada20b6c1cfacc4f6fbc59ea5c0f0cbbe957c6ab2c16892f18b6f911497e795d8
> commons-pool2-2.6.2-bin-zip=f80ef3718b319f4c2d0605466a49947598d74f1c50d0c3e53d7603f022f3d78d56b3b1291cf0f6382d20642dd4782d87b55c6f56b49475281e21179dbfae4fcd

The above are really difficult to read, it would be easier if the name
and hash were on subsequent lines

> (no need for .asc hashes!)

So why include them?

> I have tested this with 'clean package site' using:
>
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> 2018-10-24T14:41:47-04:00)
> Maven home: C:\Java\apache-maven-3.6.0\bin\..
> Java version: 1.8.0_202, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk1.8.0_202\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Microsoft Windows [Version 10.0.16299.967]
>
> Details of changes since 2.6.1 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/pool/2.6.2-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/pool/2.6.2-RC1/site/changes-report.html
>
> Site:
> https://dist.apache.o

Re: [release-plugin] sha’s (Was: Re: [VOTE] Release Apache Commons Pool 2.6.2 based on RC1)

[sebb]

On Sat, 6 Apr 2019 at 17:59, Gary Gregory  wrote:
>
> On Sat, Apr 6, 2019 at 12:48 PM Rob Tompkins  wrote:
>>
>>
>>
>> > On Apr 6, 2019, at 12:24 PM, Gary Gregory  wrote:
>> >
>> > Hi Sebb,
>> >
>> > Thank you for your review. Some comments below.
>> >
>> >> On Sat, Apr 6, 2019 at 5:00 AM sebb  wrote:
>> >>
>> >>> On Sat, 6 Apr 2019 at 03:15, Gary Gregory  wrote:
>> >>>
>> >>> We have fixed a few bugs since Apache Commons Pool 2.6.1 was released,
>> >> so I
>> >>> would like to release Apache Commons Pool 2.6.2.
>> >>>
>> >>> Apache Commons Pool 2.6.2 RC1 is available for review here:
>> >>>https://dist.apache.org/repos/dist/dev/commons/pool/2.6.2-RC1 (svn
>> >>> revision 33480)
>> >>>
>> >>> The Git tag commons-pool-2.6.2-RC1 commit for this RC is
>> >>> 06de412e2ce72007a6e43112164c371de4a66d3b which you can browse here:
>> >>>
>> >>>
>> >> https://gitbox.apache.org/repos/asf?p=commons-pool.git;a=commit;h=06de412e2ce72007a6e43112164c371de4a66d3b
>> >>> You may checkout this tag using:
>> >>>git clone https://gitbox.apache.org/repos/asf/commons-pool.git -b
>> >>> commons-pool-2.6.2-RC1 commons-pool-2.6.2-RC1
>> >>>
>> >>> Maven artifacts are here:
>> >>>
>> >>>
>> >> https://repository.apache.org/content/repositories/orgapachecommons-1432/org/apache/commons/commons-pool2/2.6.2/
>> >>>
>> >>> These are the Maven artifacts and their hashes in Nexus:
>> >>>
>> >>> #Release SHA-512s
>> >>> #Fri Apr 05 21:23:42 EDT 2019
>> >>>
>> >> commons-pool2-2.6.2-test-sources-java-source=7494677ccb265bca20fa61fd143f8a5f2e518653926c9a8ca5b33a6b379f9c9c5c262613839ff722200c7053356cbf6fb3a436823c4d6bf504dce4782a206373
>> >>
>> >> What is commons-pool2-2.6.2-test-sources-java-source ?
>> >>
>> >
>> > Looks like a SNAFU in our release plugin; sorted, the entries should be:
>>
>> That’s on me :-)
>>
>> I used dashes in there for consistency in property naming, but in hindsight 
>> it’s more confusing. I’m planning on switching it to the file name verbatim.
>>
>> Do we want to include the sha1’s of the nexus “convenience” artifacts? We 
>> can do this, but have hesitated to in the past.
>
>
> On our page http://commons.apache.org/releases/prepare.html I read: "Also the 
> revisions for the various tags, and hashes for the release artifacts", which 
> I interpret as having the vote email contain the hashes of any files we 
> release on Nexus and Dist folders.
>
> @Sebastian Bazley  WDYT?

The intention of the hash is to tie the published artifacts back to the VOTE.

So I thjnk we need hashes of all the artifacts that are listed in the VOTE.
This includes the convenience artifacts as they should be checked too.
e.g. they can be checked for valid N&L files and spurious content

> Gary
>
>>
>> -Rob
>>
>> >
>> > commons-pool2-2.6.2-bin-tar.gz
>> > SHA512
>> > 8bf3b5bdd81c88761421e45ae8904e9718f152d09124880cf0acdcf08e7e64ab9a16eed23977f871bc8365801e3a7d4b1af254dd83fcdadca43520f7399b140e
>> >
>> > commons-pool2-2.6.2-bin.zip
>> > SHA512
>> > f80ef3718b319f4c2d0605466a49947598d74f1c50d0c3e53d7603f022f3d78d56b3b1291cf0f6382d20642dd4782d87b55c6f56b49475281e21179dbfae4fcd
>> >
>> > commons-pool2-2.6.2-src-tar.gz
>> > SHA512
>> > a02f34c5e38bbcf2f1960cc1b89f468e6c4229b7d5f48b60044dd7a670d2a00eaab08fa8eca7b135b2696fe7a09824fcafe7ab3c4513716d1a4003f0bb3c0336
>> >
>> > commons-pool2-2.6.2-src.zip
>> > SHA512
>> > 86a8e77b6d50ab57c2e9374a6f1d1e3d66946e541f90eacc822126026901ba4f172ddb0549f101c62757cb0389e23751063bb0e97128699aa9d8a7b8c5ebbd7a
>> >
>> > /org/apache/commons/commons-pool2/2.6.2/commons-pool2-2.6.2-javadoc.jar
>> > (SHA1: 16cea19174aa457aa254572b9a439926adc4f02a)
>> > /org/apache/commons/commons-pool2/2.6.2/commons-pool2-2.6.2-test-sources.jar
>> > (SHA1: df34b03e3af2183cce59faa892b2fbd6adacfea1)
>> > /org/apache/commons/commons-pool2/2.6.2/commons-pool2-2.6.2-test-sources.jar.asc
>> > (SHA1: 11e34225a509129a726781fb8f179d1c08f4f43f)
>> > /org/apache/commons/commons-pool2/2.6.2/commons-pool2-2.6.2.jar.asc
>> > (SHA1: a80bf487ec6a5a5a40b8e0437ea3e27557a8002d)
>> > /org/apache/commons/commons-pool2/2.6.

Re: [lang] LANG-1442

[sebb]

On Sat, 6 Apr 2019 at 17:18, Gilles Sadowski  wrote:
>
> Le sam. 6 avr. 2019 à 16:59, Rob Tompkins  a écrit :
> >
> > @Gilles - thoughts on this wording: 
> > https://github.com/apache/commons-lang/commit/3f43706192b1b75c5023f165534a12b192c31442
> >  
> > 
> >  ?
>
> There is a typo "the user use" -> "the user uses".

Note that 'suggest that' is a subjunctive, for which 'use' is usually
considered more correct [1]

However neither reads well to me.

> Otherwise seems fair, but I'd suggest being assertive:

Agreed.

>  * "We would like to further note to users" -> "Please note that [...]"
>  * "For a more extensive treatment of random numbers" -> "For more
> stringent requirements (performance and/or correctness) [...]"
>
> That would give concrete hints that there is more to it than it looks.
>
> Thus, how about inserting this paragraph:
> ---
>  * Please note that the Apache Commons project provides a component
>  * dedicated to pseudo-random number generation, namely
>  * https://commons.apache.org/rng";>Commons RNG, that may be
>  * a better choice for applications with more stringent requirements
> (performance
>  * and/or correctness).
> ---
> ?

That reads better.

Note: I still think we should stop short of making recommendations
regarding cryptographically secure RNGs here.
So the previous sentence "Consider instead ..." needs be dropped.

S.
[1] https://grammarist.com/grammar/subjunctive-mood/
Note: 'I suggest that he implement a ...'

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

Re: [release-plugin] sha’s (Was: Re: [VOTE] Release Apache Commons Pool 2.6.2 based on RC1)

[sebb]

On Sun, 7 Apr 2019 at 11:25, Rob Tompkins  wrote:
>
>
>
> > On Apr 7, 2019, at 5:52 AM, sebb  wrote:
> >
> >> On Sat, 6 Apr 2019 at 17:59, Gary Gregory  wrote:
> >>
> >>> On Sat, Apr 6, 2019 at 12:48 PM Rob Tompkins  wrote:
> >>>
> >>>
> >>>
> >>>> On Apr 6, 2019, at 12:24 PM, Gary Gregory  wrote:
> >>>>
> >>>> Hi Sebb,
> >>>>
> >>>> Thank you for your review. Some comments below.
> >>>>
> >>>>>> On Sat, Apr 6, 2019 at 5:00 AM sebb  wrote:
> >>>>>>
> >>>>>> On Sat, 6 Apr 2019 at 03:15, Gary Gregory  wrote:
> >>>>>>
> >>>>>> We have fixed a few bugs since Apache Commons Pool 2.6.1 was released,
> >>>>> so I
> >>>>>> would like to release Apache Commons Pool 2.6.2.
> >>>>>>
> >>>>>> Apache Commons Pool 2.6.2 RC1 is available for review here:
> >>>>>>   https://dist.apache.org/repos/dist/dev/commons/pool/2.6.2-RC1 (svn
> >>>>>> revision 33480)
> >>>>>>
> >>>>>> The Git tag commons-pool-2.6.2-RC1 commit for this RC is
> >>>>>> 06de412e2ce72007a6e43112164c371de4a66d3b which you can browse here:
> >>>>>>
> >>>>>>
> >>>>> https://gitbox.apache.org/repos/asf?p=commons-pool.git;a=commit;h=06de412e2ce72007a6e43112164c371de4a66d3b
> >>>>>> You may checkout this tag using:
> >>>>>>   git clone https://gitbox.apache.org/repos/asf/commons-pool.git -b
> >>>>>> commons-pool-2.6.2-RC1 commons-pool-2.6.2-RC1
> >>>>>>
> >>>>>> Maven artifacts are here:
> >>>>>>
> >>>>>>
> >>>>> https://repository.apache.org/content/repositories/orgapachecommons-1432/org/apache/commons/commons-pool2/2.6.2/
> >>>>>>
> >>>>>> These are the Maven artifacts and their hashes in Nexus:
> >>>>>>
> >>>>>> #Release SHA-512s
> >>>>>> #Fri Apr 05 21:23:42 EDT 2019
> >>>>>>
> >>>>> commons-pool2-2.6.2-test-sources-java-source=7494677ccb265bca20fa61fd143f8a5f2e518653926c9a8ca5b33a6b379f9c9c5c262613839ff722200c7053356cbf6fb3a436823c4d6bf504dce4782a206373
> >>>>>
> >>>>> What is commons-pool2-2.6.2-test-sources-java-source ?
> >>>>>
> >>>>
> >>>> Looks like a SNAFU in our release plugin; sorted, the entries should be:
> >>>
> >>> That’s on me :-)
> >>>
> >>> I used dashes in there for consistency in property naming, but in 
> >>> hindsight it’s more confusing. I’m planning on switching it to the file 
> >>> name verbatim.
> >>>
> >>> Do we want to include the sha1’s of the nexus “convenience” artifacts? We 
> >>> can do this, but have hesitated to in the past.
> >>
> >>
> >> On our page http://commons.apache.org/releases/prepare.html I read: "Also 
> >> the revisions for the various tags, and hashes for the release artifacts", 
> >> which I interpret as having the vote email contain the hashes of any files 
> >> we release on Nexus and Dist folders.
> >>
> >> @Sebastian Bazley  WDYT?
> >
> > The intention of the hash is to tie the published artifacts back to the 
> > VOTE.
> >
> > So I thjnk we need hashes of all the artifacts that are listed in the VOTE.
> > This includes the convenience artifacts as they should be checked too.
> > e.g. they can be checked for valid N&L files and spurious content
> >
>
> Cool. Do we want the hashes to be those that nexus stores, namely the sha1’s, 
> or do we think they need to be the more secure sha512?

I think they need to agree with the ones in the dist.a.o repo, because
those are the primary release artifacts.
SHA1 is no longer used there.
[I suspect that SHA1 will be dropped from Nexus at some point anyway]

> -Rob
>
>
> >> Gary
> >>
> >>>
> >>> -Rob
> >>>
> >>>>
> >>>> commons-pool2-2.6.2-bin-tar.gz
> >>>> SHA512
> >>>> 8bf3b5bdd81c88761421e45ae8904e9718f152d09124880cf0acdcf08e7e64ab9a16eed23977f871bc8365801e3a7d4b1af254dd83fcdadca43520f7399b140e
> >>>>
> >>>> commons-pool2-2.6

Re: [commons-lang] branch master updated: (docs) update user use -> user explore

[sebb]

On Mon, 8 Apr 2019 at 13:16, Rob Tompkins  wrote:
>
> I think that maybe hits what you guys were getting after with my wording.
>
> And you know me, english as a first language, still writing poorly :-p
>
> Do we think lang 3.9 is ready?

I still think the sentence starting "Consider instead using a more..."
should be removed.

This affects the following para as well, the following change would fix it:

"We would like to further note to users that the"
=>
"The"

> -Rob
>
> > On Apr 8, 2019, at 8:13 AM, chtom...@apache.org wrote:
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > chtompki pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/commons-lang.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> > new 69326c8  (docs) update user use -> user explore
> > 69326c8 is described below
> >
> > commit 69326c8ba9d4b0399701ab3de40ed20d35f9e248
> > Author: Tompkins 
> > AuthorDate: Mon Apr 8 08:13:39 2019 -0400
> >
> >(docs) update user use -> user explore
> > ---
> > src/main/java/org/apache/commons/lang3/RandomStringUtils.java | 2 +-
> > src/main/java/org/apache/commons/lang3/RandomUtils.java   | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/main/java/org/apache/commons/lang3/RandomStringUtils.java 
> > b/src/main/java/org/apache/commons/lang3/RandomStringUtils.java
> > index 9fe6684..e0472c9 100644
> > --- a/src/main/java/org/apache/commons/lang3/RandomStringUtils.java
> > +++ b/src/main/java/org/apache/commons/lang3/RandomStringUtils.java
> > @@ -40,7 +40,7 @@ import java.util.Random;
> >  * We would like to further note to users that the Apache Commons 
> > Project has
> >  * a component entirely dedicated to random number generation, namely
> >  * http://commons.apache.org/rng";>Commons RNG. For a more 
> > extensive
> > - * treatment of random numbers, we suggest that the user use this 
> > library.
> > + * treatment of random numbers, we suggest that the user explore this 
> > library.
> >  *
> >  * #ThreadSafe#
> >  * @since 1.0
> > diff --git a/src/main/java/org/apache/commons/lang3/RandomUtils.java 
> > b/src/main/java/org/apache/commons/lang3/RandomUtils.java
> > index 6f1b3b9..4d37b9e 100644
> > --- a/src/main/java/org/apache/commons/lang3/RandomUtils.java
> > +++ b/src/main/java/org/apache/commons/lang3/RandomUtils.java
> > @@ -28,7 +28,7 @@ import java.util.Random;
> >  * We would like to further note to users that the Apache Commons 
> > Project has
> >  * a component entirely dedicated to random number generation, namely
> >  * http://commons.apache.org/rng";>Commons RNG. For a more 
> > extensive
> > - * treatment of random numbers, we suggest that the user use this 
> > library.
> > + * treatment of random numbers, we suggest that the user explore this 
> > library.
> >  *
> >  * @since 3.3
> >  */
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [commons-lang] branch master updated: (docs) update user use -> user explore

[sebb]

On Mon, 8 Apr 2019 at 14:25, Gilles Sadowski  wrote:
>
> Hi Rob.
>
> Le lun. 8 avr. 2019 à 14:16, Rob Tompkins  a écrit :
> >
> > I think that maybe hits what you guys were getting after with my wording.
>
> You probably missed a thread.
> I've just committed the alternative text.

Looks good to me.

> Regards,
> Gilles
>
> >
> > And you know me, english as a first language, still writing poorly :-p
> >
> > Do we think lang 3.9 is ready?
> >
> > -Rob
> >
> > > On Apr 8, 2019, at 8:13 AM, chtom...@apache.org wrote:
> > >
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > chtompki pushed a commit to branch master
> > > in repository https://gitbox.apache.org/repos/asf/commons-lang.git
> > >
> > >
> > > The following commit(s) were added to refs/heads/master by this push:
> > > new 69326c8  (docs) update user use -> user explore
> > > 69326c8 is described below
> > >
> > > commit 69326c8ba9d4b0399701ab3de40ed20d35f9e248
> > > Author: Tompkins 
> > > AuthorDate: Mon Apr 8 08:13:39 2019 -0400
> > >
> > >(docs) update user use -> user explore
> > > ---
> > > src/main/java/org/apache/commons/lang3/RandomStringUtils.java | 2 +-
> > > src/main/java/org/apache/commons/lang3/RandomUtils.java   | 2 +-
> > > 2 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git 
> > > a/src/main/java/org/apache/commons/lang3/RandomStringUtils.java 
> > > b/src/main/java/org/apache/commons/lang3/RandomStringUtils.java
> > > index 9fe6684..e0472c9 100644
> > > --- a/src/main/java/org/apache/commons/lang3/RandomStringUtils.java
> > > +++ b/src/main/java/org/apache/commons/lang3/RandomStringUtils.java
> > > @@ -40,7 +40,7 @@ import java.util.Random;
> > >  * We would like to further note to users that the Apache Commons 
> > > Project has
> > >  * a component entirely dedicated to random number generation, namely
> > >  * http://commons.apache.org/rng";>Commons RNG. For a more 
> > > extensive
> > > - * treatment of random numbers, we suggest that the user use this 
> > > library.
> > > + * treatment of random numbers, we suggest that the user explore this 
> > > library.
> > >  *
> > >  * #ThreadSafe#
> > >  * @since 1.0
> > > diff --git a/src/main/java/org/apache/commons/lang3/RandomUtils.java 
> > > b/src/main/java/org/apache/commons/lang3/RandomUtils.java
> > > index 6f1b3b9..4d37b9e 100644
> > > --- a/src/main/java/org/apache/commons/lang3/RandomUtils.java
> > > +++ b/src/main/java/org/apache/commons/lang3/RandomUtils.java
> > > @@ -28,7 +28,7 @@ import java.util.Random;
> > >  * We would like to further note to users that the Apache Commons 
> > > Project has
> > >  * a component entirely dedicated to random number generation, namely
> > >  * http://commons.apache.org/rng";>Commons RNG. For a more 
> > > extensive
> > > - * treatment of random numbers, we suggest that the user use this 
> > > library.
> > > + * treatment of random numbers, we suggest that the user explore this 
> > > library.
> > >  *
> > >  * @since 3.3
> > >  */
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

[sebb]

On Tue, 9 Apr 2019 at 07:59, Jochen Wiedmann  wrote:
>
> Hi,
>
> I have studied EMAIL-186. My impression is, that all commons jar files
> should provide a fixed module name, rather than trusting in the choice
> of the JDK. Thus, it seems best to handle this in parent. So, here's
> my proposal for a change. Please, let me know, what you think of that,
> so that I can either fix it, op proceed with committing.

What exactly does 'fixed' mean in this context?

If it is supposed to be tied to API compatibility, then strictly
speaking it needs the group-id as well.

If there is only supposed to be one module name regardless of API
compatibility, then artifact-id won't do as it is not immutable.

> Thanks,
>
> Jochen
>
>
> $ git diff pom.xml
> diff --git a/pom.xml b/pom.xml
> index 2612dd6..54a88e4 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -570,6 +570,7 @@
>
> ${implementation.build}
>
> ${maven.compiler.source}
>
> ${maven.compiler.target}
> +  
> ${commons.module.name}
>  
>
>  
> @@ -1608,6 +1609,9 @@
>  1.3
>  1.3
>
> +
> +${project.artifactId}
> +
>  
>  false
>  
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

[sebb]

On Tue, 9 Apr 2019 at 11:43, Gilles Sadowski  wrote:
>
> > [...]
> > >
> > > $ git diff pom.xml
> > > diff --git a/pom.xml b/pom.xml
> > > index 2612dd6..54a88e4 100644
> > > --- a/pom.xml
> > > +++ b/pom.xml
> > > @@ -570,6 +570,7 @@
> > >
> > > ${implementation.build}
> > >
> > > ${maven.compiler.source}
> > >
> > > ${maven.compiler.target}
> > > +  
> > > ${commons.module.name}
>
> ${commons.automatic.module.name}
>
> > >  
> > >
> > >  
> > > @@ -1608,6 +1609,9 @@
> > >  1.3
> > >  1.3
> > >
> > > +
> > > +${project.artifactId}
>
> No default should be defined (to avoid the risk of creating incompatible
> but identically named modules).

Surely that *should* be solved by using groupId + artifactId?
We change one or the other when releasing an incompatible module.

> Then the release plugin could be enhanced (?) so that it would check
> whether the variable has been defined for each JAR to be created (and
> fail the build otherwise).

But how would that ensure incompatible modules were given different names?

> Gilles
>
> > > +
> > >  
> > >  false
> > >  
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

[sebb]

On Tue, 9 Apr 2019 at 13:32, Jochen Wiedmann  wrote:
>
> On Tue, Apr 9, 2019 at 10:48 AM John Patrick  wrote:
>
>
> > As commons-lang3 has the module name org.apache.commons.lang3, not
> > commons-lang3 which is the artifactId, because "-" is invalid in a
> > real module name and they realised this when starting to support jpms.
>
> Commons-lang, and others, can fix this by overriding the property value.
>
> > So could the default be something like OVERRIDE_PER_RELEASED_JAR, so
> > it's very very clear.
>
> I think we can do better than that: Use the maven-antrun plugin (or
> the groovy-maven-plugin, or whatever) to check, whether the propery
> value is given. If not, abort the build. That way, components will
> have that property value as soon as they adopt the respective version
> of commons-parent.

Unless I am misunderstanding this, the property value won't be checked
to see if i is changed when an incompatible versioni s released.

i.e. another item people need to remember to change when an
incompatible version is released.

However, if the module name is derived from gid+aid (with invalid
characters suitably replaced), it will happen automatically.

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

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

Re: [lang] 3.9, switch from cobertura to jacoco?

[sebb]

On Tue, 9 Apr 2019 at 13:39, Rob Tompkins  wrote:
>
> Thoughts on doing this switch? I’m heavily leaning towards it because I can’t 
> get code coverage to work on java 11 with the current build.

+0

It's trivial to switch back isn't it?

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

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

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

[sebb]

On Tue, 9 Apr 2019 at 13:54, Jochen Wiedmann  wrote:
>
> On Tue, Apr 9, 2019 at 2:43 PM sebb  wrote:
>
> > Unless I am misunderstanding this, the property value won't be checked
> > to see if i is changed when an incompatible versioni s released.
>
> True, but that applies in either case, as soon as we have module
> names, doesn't it?

Not sure which cases you are referring to.

We already have a process for ensuring that Maven coords and package
names are changed when API breaks.
Do we really want to have yet another name that has to be maintained?

> So, I'd like to keep this out of the current
> discussion, which is (IMO) about how we implement the module name.

But what are we trying to achieve here?

Being able to define the module name independently is all very well,
but it does not solve the problem of ensuring that the module name is
correct, and remains correct when code is updated.

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

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

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

[sebb]

On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann  wrote:
>
> On Tue, Apr 9, 2019 at 3:51 PM sebb  wrote:
>
> > We already have a process for ensuring that Maven coords and package
> > names are changed when API breaks.
> > Do we really want to have yet another name that has to be maintained?
>
> What's the alternative?

As I already wrote, use the gid + aid to generate a suitable name.

>
> > Being able to define the module name independently is all very well,
> > but it does not solve the problem of ensuring that the module name is
> > correct, and remains correct when code is updated.
>
> That is, IMO, a problem, which can (and will) be solved later.

Which may involve reverting the work already done.

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

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

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

[sebb]

On Tue, 9 Apr 2019 at 17:06, Rob Tompkins  wrote:
>
>
>
> > On Apr 9, 2019, at 11:57 AM, sebb  wrote:
> >
> > On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann  
> > wrote:
> >>
> >> On Tue, Apr 9, 2019 at 3:51 PM sebb  wrote:
> >>
> >>> We already have a process for ensuring that Maven coords and package
> >>> names are changed when API breaks.
> >>> Do we really want to have yet another name that has to be maintained?
> >>
> >> What's the alternative?
> >
> > As I already wrote, use the gid + aid to generate a suitable name.
>
> We already do this for OSGI here’s the [lang] example: 
> https://github.com/apache/commons-lang/blob/master/pom.xml#L581 
> <https://github.com/apache/commons-lang/blob/master/pom.xml#L581> combined 
> with https://github.com/apache/commons-parent/blob/master/pom.xml#L1743 
> <https://github.com/apache/commons-parent/blob/master/pom.xml#L1743>

I think 'org.apache.commons' should probably be: ${project.groupId} in CP.
Otherwise projects that are still on a different groupId may get a
duplicate conflicting name if they move to o.a.c as the groupId.

>
>
>
> >
> >>
> >>> Being able to define the module name independently is all very well,
> >>> but it does not solve the problem of ensuring that the module name is
> >>> correct, and remains correct when code is updated.
> >>
> >> That is, IMO, a problem, which can (and will) be solved later.
> >
> > Which may involve reverting the work already done.
> >
> >> Jochen
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>

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

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

[sebb]

On Tue, 9 Apr 2019 at 18:14, Rob Tompkins  wrote:
>
>
>
> > On Apr 9, 2019, at 1:11 PM, sebb  wrote:
> >
> > On Tue, 9 Apr 2019 at 17:06, Rob Tompkins  > <mailto:chtom...@gmail.com>> wrote:
> >>
> >>
> >>
> >>> On Apr 9, 2019, at 11:57 AM, sebb  wrote:
> >>>
> >>> On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann  
> >>> wrote:
> >>>>
> >>>> On Tue, Apr 9, 2019 at 3:51 PM sebb  wrote:
> >>>>
> >>>>> We already have a process for ensuring that Maven coords and package
> >>>>> names are changed when API breaks.
> >>>>> Do we really want to have yet another name that has to be maintained?
> >>>>
> >>>> What's the alternative?
> >>>
> >>> As I already wrote, use the gid + aid to generate a suitable name.
> >>
> >> We already do this for OSGI here’s the [lang] example: 
> >> https://github.com/apache/commons-lang/blob/master/pom.xml#L581 
> >> <https://github.com/apache/commons-lang/blob/master/pom.xml#L581> 
> >> <https://github.com/apache/commons-lang/blob/master/pom.xml#L581 
> >> <https://github.com/apache/commons-lang/blob/master/pom.xml#L581>> 
> >> combined with 
> >> https://github.com/apache/commons-parent/blob/master/pom.xml#L1743 
> >> <https://github.com/apache/commons-parent/blob/master/pom.xml#L1743> 
> >> <https://github.com/apache/commons-parent/blob/master/pom.xml#L1743 
> >> <https://github.com/apache/commons-parent/blob/master/pom.xml#L1743>>
> >
> > I think 'org.apache.commons' should probably be: ${project.groupId} in CP.
> > Otherwise projects that are still on a different groupId may get a
> > duplicate conflicting name if they move to o.a.c as the groupId.
>
> I’m a +1 to that idea, but it is worth noting that we do have antiquated 
> groupId’s that look like “commons-” in the project. They would 
> have to be changed at their next release.

It's those components that I was thinking of.
But if they have already been released with the o.a.c name then it's
probably too late.
If they currently have an OSGI name starting with o.a.c, then that
won't currently change if they change groupId only.
Any such components would also need to change artifactID and package name.


> -Rob
>
> >
> >>
> >>
> >>
> >>>
> >>>>
> >>>>> Being able to define the module name independently is all very well,
> >>>>> but it does not solve the problem of ensuring that the module name is
> >>>>> correct, and remains correct when code is updated.
> >>>>
> >>>> That is, IMO, a problem, which can (and will) be solved later.
> >>>
> >>> Which may involve reverting the work already done.
> >>>
> >>>> Jochen
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
> > <mailto:dev-unsubscr...@commons.apache.org>
> > For additional commands, e-mail: dev-h...@commons.apache.org 
> > <mailto:dev-h...@commons.apache.org>

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

Re: Build failed in Jenkins: commons-lang #517

[sebb]

On Tue, 16 Apr 2019 at 14:43, Gary Gregory  wrote:
>
> Is this a credentials issue in Jenkins or an issue with our release plugin?
>
> Why are we even invoking our release plugin here?

The profile -Prelease may have something to do with that.

> Gary
>
> -- Forwarded message -
> From: Apache Jenkins Server 
> Date: Tue, Apr 16, 2019 at 9:18 AM
> Subject: Build failed in Jenkins: commons-lang #517
> To: 
>
>
> See <
> https://builds.apache.org/job/commons-lang/517/display/redirect?page=changes
> >
>
> Changes:
>
> [gardgregory] Add OpenJDK 8 to Travis builds.
>
> --
> Started by an SCM change
> [EnvInject] - Loading node environment variables.
> Building remotely on H22 (ubuntu xenial) in workspace <
> https://builds.apache.org/job/commons-lang/ws/>
> No credentials specified
> Cloning the remote Git repository
> Cloning repository https://gitbox.apache.org/repos/asf/commons-lang.git
>  > git init  # timeout=10
> Fetching upstream changes from
> https://gitbox.apache.org/repos/asf/commons-lang.git
>  > git --version # timeout=10
>  > git fetch --tags --progress
> https://gitbox.apache.org/repos/asf/commons-lang.git
> +refs/heads/*:refs/remotes/origin/*
>  > git config remote.origin.url
> https://gitbox.apache.org/repos/asf/commons-lang.git # timeout=10
>  > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
> # timeout=10
>  > git config remote.origin.url
> https://gitbox.apache.org/repos/asf/commons-lang.git # timeout=10
> Fetching upstream changes from
> https://gitbox.apache.org/repos/asf/commons-lang.git
>  > git fetch --tags --progress
> https://gitbox.apache.org/repos/asf/commons-lang.git
> +refs/heads/*:refs/remotes/origin/*
>  > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
>  > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
> Checking out Revision 7964c45a54347dcdcd9ea1640c62dac7b3d71809
> (refs/remotes/origin/master)
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f 7964c45a54347dcdcd9ea1640c62dac7b3d71809
> Commit message: "Add OpenJDK 8 to Travis builds."
>  > git rev-list --no-walk f2c28e67b7c883db33a6cd1f7aba154b79f73d5b #
> timeout=10
> Parsing POMs
> Downloaded artifact
> http://repo.maven.apache.org/maven2/org/apache/commons/commons-parent/48/commons-parent-48.pom
> Established TCP socket on 44520
> maven35-agent.jar already up to date
> maven35-interceptor.jar already up to date
> maven3-interceptor-commons.jar already up to date
> [commons-lang] $ /home/jenkins/tools/java/latest1.8/bin/java -Xmx4g -Xms4g
> -cp
> /home/jenkins/jenkins-slave/maven35-agent.jar:/home/jenkins/tools/maven/latest/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/latest/conf/logging
> jenkins.maven3.agent.Maven35Main /home/jenkins/tools/maven/latest/
> /home/jenkins/jenkins-slave/remoting.jar
> /home/jenkins/jenkins-slave/maven35-interceptor.jar
> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 44520
> <===[JENKINS REMOTING CAPACITY]===>   channel started
> Executing Maven:  -B -f <
> https://builds.apache.org/job/commons-lang/ws/pom.xml>
> -Dmaven.repo.local=/home/jenkins/jenkins-slave/maven-repositories/1 clean
> install javadoc:javadoc --batch-mode -Dgpg.skip -Prelease
> [INFO] Scanning for projects...
> [INFO]
> [INFO] --< org.apache.commons:commons-lang3
> >--
> [INFO] Building Apache Commons Lang 3.10-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO] Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/3.1.1/maven-jar-plugin-3.1.1.pom
> [INFO] Downloaded from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/3.1.1/maven-jar-plugin-3.1.1.pom
> (6.7 kB at 26 kB/s)
> [INFO] Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/3.1.1/maven-jar-plugin-3.1.1.jar
> [INFO] Downloaded from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/3.1.1/maven-jar-plugin-3.1.1.jar
> (27 kB at 1.4 MB/s)
> [INFO] Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/commons/commons-release-plugin/1.6/commons-release-plugin-1.6.pom
> [INFO] Downloaded from central:
> https://repo.maven.apache.org/maven2/org/apache/commons/commons-release-plugin/1.6/commons-release-plugin-1.6.pom
> (28 kB at 1.5 MB/s)
> [INFO] Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/commons/commons-release-plugin/1.6/commons-release-plugin-1.6.jar
> [INFO] Downloaded from central:
> https://repo.maven.apache.org/maven2/org/apache/commons/commons-release-plugin/1.6/commons-release-plugin-1.6.jar
> (53 kB at 2.8 MB/s)
> [INFO] Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-assembly-plugin/3

Re: [compress] Java 7 to Java 8

[sebb]

On Tue, 16 Apr 2019 at 14:51, Stefan Bodewig  wrote:
>
> On 2019-04-16, Gary Gregory wrote:
>
> > On Tue, Apr 16, 2019 at 9:39 AM Stefan Bodewig  wrote:
>
> >> As long as using Java 7 doesn't hurt us, I don't see any reason to
> >> update.
>
> > Using old dead versions of Java turns off potential contributors IMO.
> > You have to go dig around and install an archived version of the JDK
> > which Oracle has EOLed.
>
> How so? You can build Compress with Java 13 and nobody is going to stop
> you. If you happen to use a feature of something not supported in Java 7
> then this may point to a reason to switch.
>
> > Not only that but you can't use the more modern features and APIs.
>
> This sounds as if you believed switching to more modern language
> constructs and APIs would magically attract collaborators. Been there,
> see the dead compress-2 branch, and don't buy this anymore.
>
> Note I haven't cast any vote (and this is not a vote at all), I just
> don't see any reason to add requirements as long as doing so doesn't
> provide any benefits. As soon as it does, I'll be happy to switch.

+1, well put.

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

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

Re: Build failed in Jenkins: Commons-Compress JDK-Matrix Build » JDK 1.7 (latest) #799

[sebb]

On Tue, 16 Apr 2019 at 16:15, Stefan Bodewig  wrote:
>
> After Compress has been upgraded to Parent 48 the JDK 7 build started to
> fail as the new version of the bnd plugin has been compiled with
> -target 8, or so it seems.
>
> I'll downgrade the bnd plugin for compress for now.

An alternative is to run Maven with Java 8, but compile/test for Java
7 using the appropriate profile.
See Commons NET for an example of how to do this.

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

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

Re: [compress] Java 7 to Java 8

[sebb]

On Wed, 17 Apr 2019 at 15:39, Matt Sicker  wrote:
>
> How long until javac removes -source and -target 1.7? They already
> removed 1.6 in Java 12. At some point, we'll be forced to upgrade just
> to remain source compatible with recent compilers. That's likely not
> for another year or more, though, so not an immediate problem; just
> something to consider for long term.

Note that Java 7 has extended support until at least July 2022:
https://www.oracle.com/technetwork/java/java-se-support-roadmap.html

> On Tue, 16 Apr 2019 at 09:53, sebb  wrote:
> >
> > On Tue, 16 Apr 2019 at 14:51, Stefan Bodewig  wrote:
> > >
> > > On 2019-04-16, Gary Gregory wrote:
> > >
> > > > On Tue, Apr 16, 2019 at 9:39 AM Stefan Bodewig  
> > > > wrote:
> > >
> > > >> As long as using Java 7 doesn't hurt us, I don't see any reason to
> > > >> update.
> > >
> > > > Using old dead versions of Java turns off potential contributors IMO.
> > > > You have to go dig around and install an archived version of the JDK
> > > > which Oracle has EOLed.
> > >
> > > How so? You can build Compress with Java 13 and nobody is going to stop
> > > you. If you happen to use a feature of something not supported in Java 7
> > > then this may point to a reason to switch.
> > >
> > > > Not only that but you can't use the more modern features and APIs.
> > >
> > > This sounds as if you believed switching to more modern language
> > > constructs and APIs would magically attract collaborators. Been there,
> > > see the dead compress-2 branch, and don't buy this anymore.
> > >
> > > Note I haven't cast any vote (and this is not a vote at all), I just
> > > don't see any reason to add requirements as long as doing so doesn't
> > > provide any benefits. As soon as it does, I'll be happy to switch.
> >
> > +1, well put.
> >
> > > Stefan
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> --
> Matt Sicker 
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

[ALL] Confluence Wiki permissions - allow all Commons committers write access?

[sebb]

Confluence supports LDAP member attributes only [1] currently.

This means we could automatically grant access to Commons committers.
However it's not currently possible to restrict access to PMC members
- but I'm not sure that we need that.

I propose to ask Infra to allow Commons committer write access to the Wiki.

Agreed?

[Administrators can always grant write access to individual
non-committers if that proves necessary.]

Sebb.
[1] 
https://lists.apache.org/thread.html/33d84ab4720f56827895b9cac6743943c0bfe1af2f838cdab2a026d4@%3Cusers.infra.apache.org%3E

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

Re: [compress] Java 7 to Java 8

[sebb]

On Wed, 17 Apr 2019 at 16:15, Matt Sicker  wrote:
>
> On Wed, 17 Apr 2019 at 10:05, sebb  wrote:
> > Note that Java 7 has extended support until at least July 2022:
> > https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
>
> Right, but does that mean that OpenJDK (and its various forks) will
> also keep 1.7 input and output formats for just as long? Because in
> July 2022, you'll still be able to compile Java 7 code with their
> extended support version of Java 7, though not necessarily whatever
> the latest release of Java is at the time.

Let's cross that bridge when we come to it, rather than crossing the
bridge and burning it now.

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

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

Re: [VFS] Sftp oddity?

[sebb]

On Sat, 27 Apr 2019 at 18:09, Gary Gregory  wrote:
>
> Hi All:
>
> Can anyone say why we build a SftpFileSystem here:
>
> https://github.com/apache/commons-vfs/blob/master/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/sftp/SftpFileProvider.java#L90
>
>
> instead of here:
>
> https://github.com/apache/commons-vfs/blob/master/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/sftp/SftpFileProvider.java#L83
>
>
> The current code allows a SftpFileSystem to be returned when a failure took
> place.

Surely line 90 is not reached if an exception occurred?

If the instance were created at line 83, then it too would be subject
to the catch clause whereas currently any creation failures are
propagated to the caller.

> Thank you,
> Gary

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

Re: [VFS] Deleting the git branch 'trunk'

[sebb]

On Wed, 1 May 2019 at 21:48, Gary Gregory  wrote:
>
> On Wed, May 1, 2019 at 3:54 PM Gary Gregory  wrote:
>
> > I created https://issues.apache.org/jira/browse/INFRA-18316
> >
>
> And the work is done. Note that open PRs on trunk have been closed
> automatically, so they would need to be re-opened.

That sounds like a LOT of work.

How can they be re-opened?

> Gary
>
>
> >
> > Gary
> >
> > On Wed, May 1, 2019 at 3:55 AM Benedikt Ritter  wrote:
> >
> >> Am Di., 30. Apr. 2019 um 14:43 Uhr schrieb Gary Gregory <
> >> garydgreg...@gmail.com>:
> >>
> >> > Should we take a broader stroke and remove ALL trunk branches from all
> >> > Commons git repos?
> >> >
> >>
> >> I think we should remove all trunk branches from git repos.
> >>
> >>
> >> >
> >> > Gary
> >> >
> >> > On Mon, Apr 29, 2019 at 11:25 AM Otto Fowler 
> >> > wrote:
> >> >
> >> > > Probably need INFRA
> >> > >
> >> > >
> >> > > On April 29, 2019 at 11:23:38, Gary Gregory (garydgreg...@gmail.com)
> >> > > wrote:
> >> > >
> >> > > On Mon, Apr 29, 2019 at 11:22 AM Gary Gregory  >> >
> >> > > wrote:
> >> > >
> >> > > > Well, crud, neither these works:
> >> > > >
> >> > > > C:\git\commons-vfs>git push origin --delete trunk
> >> > > > remote: Rewinding refs/heads/trunk is forbidden.
> >> > > > remote:
> >> > > > To https://gitbox.apache.org/repos/asf/commons-vfs
> >> > > > ! [remote rejected] trunk (pre-receive hook declined)
> >> > > > error: failed to push some refs to '
> >> > > > https://gitbox.apache.org/repos/asf/commons-vfs'
> >> > > >
> >> > > > C:\git\commons-vfs> git push origin :trunk
> >> > > > remote: Rewinding refs/heads/trunk is forbidden.
> >> > > > remote:
> >> > > > To https://gitbox.apache.org/repos/asf/commons-vfs
> >> > > > ! [remote rejected] trunk (pre-receive hook declined)
> >> > > > error: failed to push some refs to '
> >> > > > https://gitbox.apache.org/repos/asf/commons-vfs'
> >> > > >
> >> > > > Thoughts?
> >> > > >
> >> > >
> >> > > BTW, I had deleted the branch locally OK with 'git branch -d trunk'
> >> > >
> >> > > Gary
> >> > >
> >> > >
> >> > > >
> >> > > > Gary
> >> > > >
> >> > > > On Mon, Apr 29, 2019 at 11:11 AM Rob Tompkins 
> >> > > wrote:
> >> > > >
> >> > > >> +1
> >> > > >>
> >> > > >> > On Apr 29, 2019, at 10:58 AM, Otto Fowler <
> >> ottobackwa...@gmail.com>
> >> > > >> wrote:
> >> > > >> >
> >> > > >> > +1
> >> > > >> >
> >> > > >> >
> >> > > >> > On April 29, 2019 at 08:01:43, Gary Gregory (
> >> garydgreg...@gmail.com
> >> > )
> >> > > >> wrote:
> >> > > >> >
> >> > > >> > I am going to delete the branch 'trunk'.
> >> > > >> >
> >> > > >> > It's too confusing.
> >> > > >> >
> >> > > >> > Gary
> >> > > >>
> >> > > >>
> >> > > >>
> >> -
> >> > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> > > >> For additional commands, e-mail: dev-h...@commons.apache.org
> >> > > >>
> >> > > >>
> >> > >
> >> >
> >>
> >

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

Re: [VFS] Deleting the git branch 'trunk'

[sebb]

On Wed, 1 May 2019 at 23:02, Gary Gregory  wrote:
>
> On Wed, May 1, 2019 at 5:30 PM sebb  wrote:
>
> > On Wed, 1 May 2019 at 21:48, Gary Gregory  wrote:
> > >
> > > On Wed, May 1, 2019 at 3:54 PM Gary Gregory 
> > wrote:
> > >
> > > > I created https://issues.apache.org/jira/browse/INFRA-18316
> > > >
> > >
> > > And the work is done. Note that open PRs on trunk have been closed
> > > automatically, so they would need to be re-opened.
> >
> > That sounds like a LOT of work.
> >
> > How can they be re-opened?
> >
>
> Here:
>
> https://issues.apache.org/jira/browse/INFRA-18316?focusedCommentId=16831238&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16831238
>
> Mark T. says this is a manual process.

Re-opening the PR is pretty easy.

However the PRs then need to be modified to be against master rather than trunk.

How does one do that?

> Gary
>
>
> >
> > > Gary
> > >
> > >
> > > >
> > > > Gary
> > > >
> > > > On Wed, May 1, 2019 at 3:55 AM Benedikt Ritter 
> > wrote:
> > > >
> > > >> Am Di., 30. Apr. 2019 um 14:43 Uhr schrieb Gary Gregory <
> > > >> garydgreg...@gmail.com>:
> > > >>
> > > >> > Should we take a broader stroke and remove ALL trunk branches from
> > all
> > > >> > Commons git repos?
> > > >> >
> > > >>
> > > >> I think we should remove all trunk branches from git repos.
> > > >>
> > > >>
> > > >> >
> > > >> > Gary
> > > >> >
> > > >> > On Mon, Apr 29, 2019 at 11:25 AM Otto Fowler <
> > ottobackwa...@gmail.com>
> > > >> > wrote:
> > > >> >
> > > >> > > Probably need INFRA
> > > >> > >
> > > >> > >
> > > >> > > On April 29, 2019 at 11:23:38, Gary Gregory (
> > garydgreg...@gmail.com)
> > > >> > > wrote:
> > > >> > >
> > > >> > > On Mon, Apr 29, 2019 at 11:22 AM Gary Gregory <
> > garydgreg...@gmail.com
> > > >> >
> > > >> > > wrote:
> > > >> > >
> > > >> > > > Well, crud, neither these works:
> > > >> > > >
> > > >> > > > C:\git\commons-vfs>git push origin --delete trunk
> > > >> > > > remote: Rewinding refs/heads/trunk is forbidden.
> > > >> > > > remote:
> > > >> > > > To https://gitbox.apache.org/repos/asf/commons-vfs
> > > >> > > > ! [remote rejected] trunk (pre-receive hook declined)
> > > >> > > > error: failed to push some refs to '
> > > >> > > > https://gitbox.apache.org/repos/asf/commons-vfs'
> > > >> > > >
> > > >> > > > C:\git\commons-vfs> git push origin :trunk
> > > >> > > > remote: Rewinding refs/heads/trunk is forbidden.
> > > >> > > > remote:
> > > >> > > > To https://gitbox.apache.org/repos/asf/commons-vfs
> > > >> > > > ! [remote rejected] trunk (pre-receive hook declined)
> > > >> > > > error: failed to push some refs to '
> > > >> > > > https://gitbox.apache.org/repos/asf/commons-vfs'
> > > >> > > >
> > > >> > > > Thoughts?
> > > >> > > >
> > > >> > >
> > > >> > > BTW, I had deleted the branch locally OK with 'git branch -d
> > trunk'
> > > >> > >
> > > >> > > Gary
> > > >> > >
> > > >> > >
> > > >> > > >
> > > >> > > > Gary
> > > >> > > >
> > > >> > > > On Mon, Apr 29, 2019 at 11:11 AM Rob Tompkins <
> > chtom...@gmail.com>
> > > >> > > wrote:
> > > >> > > >
> > > >> > > >> +1
> > > >> > > >>
> > > >> > > >> > On Apr 29, 2019, at 10:58 AM, Otto Fowler <
> > > >> ottobackwa...@gmail.com>
> > > >> > > >> wrote:
> > > >> > > >> >
> > > >> > > >> > +1
> > > >> > > >> >
> > > >> > > >> >
> > > >> > > >> > On April 29, 2019 at 08:01:43, Gary Gregory (
> > > >> garydgreg...@gmail.com
> > > >> > )
> > > >> > > >> wrote:
> > > >> > > >> >
> > > >> > > >> > I am going to delete the branch 'trunk'.
> > > >> > > >> >
> > > >> > > >> > It's too confusing.
> > > >> > > >> >
> > > >> > > >> > Gary
> > > >> > > >>
> > > >> > > >>
> > > >> > > >>
> > > >> -
> > > >> > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > >> > > >> For additional commands, e-mail: dev-h...@commons.apache.org
> > > >> > > >>
> > > >> > > >>
> > > >> > >
> > > >> >
> > > >>
> > > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

Re: [VFS] Deleting the git branch 'trunk'

[sebb]

On Thu, 2 May 2019 at 00:09, Bruno P. Kinoshita
 wrote:
>
>  Yesterday I submitted a pull request against the wrong branch in GitHub. 
> Spent a couple of minutes scratching my head and trying to find out how to 
> change that... then found the option while editing it.
>
> GitHub help has a page explaining how to do that: 
> https://help.github.com/en/articles/changing-the-base-branch-of-a-pull-request

Thanks, it's pretty easy - apart from the issue of how to determine
whether commits will be removed from the timeline.


> CheersBruno
>
>
> On Thursday, 2 May 2019, 10:23:50 am NZST, sebb  wrote:
>
>  On Wed, 1 May 2019 at 23:02, Gary Gregory  wrote:
> >
> > On Wed, May 1, 2019 at 5:30 PM sebb  wrote:
> >
> > > On Wed, 1 May 2019 at 21:48, Gary Gregory  wrote:
> > > >
> > > > On Wed, May 1, 2019 at 3:54 PM Gary Gregory 
> > > wrote:
> > > >
> > > > > I created https://issues.apache.org/jira/browse/INFRA-18316
> > > > >
> > > >
> > > > And the work is done. Note that open PRs on trunk have been closed
> > > > automatically, so they would need to be re-opened.
> > >
> > > That sounds like a LOT of work.
> > >
> > > How can they be re-opened?
> > >
> >
> > Here:
> >
> > https://issues.apache.org/jira/browse/INFRA-18316?focusedCommentId=16831238&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16831238
> >
> > Mark T. says this is a manual process.
>
> Re-opening the PR is pretty easy.
>
> However the PRs then need to be modified to be against master rather than 
> trunk.
>
> How does one do that?
>
> > Gary
> >
> >
> > >
> > > > Gary
> > > >
> > > >
> > > > >
> > > > > Gary
> > > > >
> > > > > On Wed, May 1, 2019 at 3:55 AM Benedikt Ritter 
> > > wrote:
> > > > >
> > > > >> Am Di., 30. Apr. 2019 um 14:43 Uhr schrieb Gary Gregory <
> > > > >> garydgreg...@gmail.com>:
> > > > >>
> > > > >> > Should we take a broader stroke and remove ALL trunk branches from
> > > all
> > > > >> > Commons git repos?
> > > > >> >
> > > > >>
> > > > >> I think we should remove all trunk branches from git repos.
> > > > >>
> > > > >>
> > > > >> >
> > > > >> > Gary
> > > > >> >
> > > > >> > On Mon, Apr 29, 2019 at 11:25 AM Otto Fowler <
> > > ottobackwa...@gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Probably need INFRA
> > > > >> > >
> > > > >> > >
> > > > >> > > On April 29, 2019 at 11:23:38, Gary Gregory (
> > > garydgreg...@gmail.com)
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > > On Mon, Apr 29, 2019 at 11:22 AM Gary Gregory <
> > > garydgreg...@gmail.com
> > > > >> >
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > > > Well, crud, neither these works:
> > > > >> > > >
> > > > >> > > > C:\git\commons-vfs>git push origin --delete trunk
> > > > >> > > > remote: Rewinding refs/heads/trunk is forbidden.
> > > > >> > > > remote:
> > > > >> > > > To https://gitbox.apache.org/repos/asf/commons-vfs
> > > > >> > > > ! [remote rejected] trunk (pre-receive hook declined)
> > > > >> > > > error: failed to push some refs to '
> > > > >> > > > https://gitbox.apache.org/repos/asf/commons-vfs'
> > > > >> > > >
> > > > >> > > > C:\git\commons-vfs> git push origin :trunk
> > > > >> > > > remote: Rewinding refs/heads/trunk is forbidden.
> > > > >> > > > remote:
> > > > >> > > > To https://gitbox.apache.org/repos/asf/commons-vfs
> > > > >> > > > ! [remote rejected] trunk (pre-receive hook declined)
> > > > >> > > > error: failed to push some refs to '
> > > > >> > > > https://gitbox.ap

Re: [bcel] broken repo?

[sebb]

Same issue applies to commons-net and -daemon.
However commons-io and -lang are OK.

Looks like the default branch has not been set up correctly for some
of the repos (probably the ones that were migrated last).

How does one set the default branch?

On Mon, 6 May 2019 at 19:09, Rob Tompkins  wrote:
>
> I wonder if the default branch, “trunk,” no longer exists and that’s what 
> it’s trying to clone down onto. When I run the following it works:
>
> git clone --single-branch --branch master 
> https://gitbox.apache.org/repos/asf/commons-bcel.git 
> 
>
> -Rob
>
> > On May 6, 2019, at 2:05 PM, Rob Tompkins  wrote:
> >
> > looking now. -Rob
> >
> >> On May 6, 2019, at 1:23 PM, Gary Gregory  wrote:
> >>
> >> Hi All:
> >>
> >> When I try a clean checkout of BCEL I get:
> >>
> >> C:\git>git clone https://gitbox.apache.org/repos/asf/commons-bcel.git
> >> Cloning into 'commons-bcel'...
> >> remote: Counting objects: 21585, done.
> >> remote: Compressing objects: 100% (2646/2646), done.
> >> Receiving objects: 100% (21585/21585), 3.83 MiB | 4.36 MiB/s, done.ing
> >> objects: 100% (21585/21585), 1.25 MiB | 2.46 MiB/s
> >>
> >> Resolving deltas: 100% (14986/14986), done.
> >> warning: remote HEAD refers to nonexistent ref, unable to checkout.
> >>
> >> Ideas?
> >>
> >> Gary
> >
>

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

Re: [bcel] broken repo?

[sebb]

https://issues.apache.org/jira/browse/INFRA-18339

On Mon, 6 May 2019 at 19:24, Rob Tompkins  wrote:
>
>
>
> > On May 6, 2019, at 2:14 PM, sebb  wrote:
> >
> > Same issue applies to commons-net and -daemon.
> > However commons-io and -lang are OK.
> >
> > Looks like the default branch has not been set up correctly for some
> > of the repos (probably the ones that were migrated last).
> >
> > How does one set the default branch?
>
> I had to put in tickets with Infra to do that back in December/Januaray. I 
> would guess that it would have something to do with their puppet automation, 
> but that’s totally a guess.
>
> -Rob
>
> >
> > On Mon, 6 May 2019 at 19:09, Rob Tompkins  > <mailto:chtom...@gmail.com>> wrote:
> >>
> >> I wonder if the default branch, “trunk,” no longer exists and that’s what 
> >> it’s trying to clone down onto. When I run the following it works:
> >>
> >> git clone --single-branch --branch master 
> >> https://gitbox.apache.org/repos/asf/commons-bcel.git 
> >> <https://gitbox.apache.org/repos/asf/commons-bcel.git> 
> >> <https://gitbox.apache.org/repos/asf/commons-bcel.git 
> >> <https://gitbox.apache.org/repos/asf/commons-bcel.git>>
> >>
> >> -Rob
> >>
> >>> On May 6, 2019, at 2:05 PM, Rob Tompkins  wrote:
> >>>
> >>> looking now. -Rob
> >>>
> >>>> On May 6, 2019, at 1:23 PM, Gary Gregory  wrote:
> >>>>
> >>>> Hi All:
> >>>>
> >>>> When I try a clean checkout of BCEL I get:
> >>>>
> >>>> C:\git>git clone https://gitbox.apache.org/repos/asf/commons-bcel.git
> >>>> Cloning into 'commons-bcel'...
> >>>> remote: Counting objects: 21585, done.
> >>>> remote: Compressing objects: 100% (2646/2646), done.
> >>>> Receiving objects: 100% (21585/21585), 3.83 MiB | 4.36 MiB/s, done.ing
> >>>> objects: 100% (21585/21585), 1.25 MiB | 2.46 MiB/s
> >>>>
> >>>> Resolving deltas: 100% (14986/14986), done.
> >>>> warning: remote HEAD refers to nonexistent ref, unable to checkout.
> >>>>
> >>>> Ideas?
> >>>>
> >>>> Gary
> >>>
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
> > <mailto:dev-unsubscr...@commons.apache.org>
> > For additional commands, e-mail: dev-h...@commons.apache.org 
> > <mailto:dev-h...@commons.apache.org>

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

Re: Commons Validator

[sebb]

On Sat, 11 May 2019 at 08:30, Andre van der Wal  wrote:
>
> Hi,
>
> When can we expect a new release of the validator?

When someone decides to release it...

> New email domains we
> need were added in April 2017 but the latest release is still from Feb 2017.

The list changes too frequently to be able to keep up with the changes.

You can update the GENERIC_TLDS array programmatically, so long as you
do it before first usage.

http://commons.apache.org/proper/commons-validator/apidocs/org/apache/commons/validator/routines/DomainValidator.html#updateTLDOverride(org.apache.commons.validator.routines.DomainValidator.ArrayType,%20java.lang.String[])

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

Re: Immutable Keys message

[sebb]

On Sat, 11 May 2019 at 13:19, Blaise Carie  wrote:
>
> To Whom This May Concern:
>  I received the following message when applying for a job.  I did not
> receive this message when applying for it yesterday, and today I am unable
> to access my application or other jobs.
> Entry.next=null, data[removeIndex]=241265648=true previous=241265648=true
> key=651070971 value=true size=4096 maxSize=4096 Please check that your keys
> are immutable, and that you have used synchronization properly. If so, then
> please report this to dev@commons.apache.org as a bug.

The above is a part of an IllegalStateException message which is
generated under certain error conditions.

The information is intended for the people using the relevant Commons
component as part of their application.
(in this case it seems to be part of Collections)

It is not intended for end-users.
Such exceptions should normally be captured by the application and
brought to the attention of the application developers.

> May you please help me with this error in order to be able to navigate the
> website ALSDE?

You should report the error to the ALSDE website maintainers.
They need to check whether the pre-conditions in the message
(immutable keys, synchronisation) have been complied with.

> Thank you for your help and please let me know if you have any questions.
>
> Sincerely,
>
> Blaise
>
> Blaise Carie
> *Cold Springs High School*
> Science Teacher
> XC and Track Coach
> *Email*: bca...@ccboe.org

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

Using email addresses in exception messages

[sebb]

Some of our code has Exception messages such as the following:

>> (Collections:LRUMap)
throw new IllegalStateException("Entry.before is null." +
" Please check that your keys are immutable, and that you have used
synchronization properly." +
" If so, then please report this to dev@commons.apache.org as a bug.");
<<

I guess it seemed like a good idea at the time, but I think the idea
has backfired:

https://lists.apache.org/thread.html/3363e23218b4c1c21b8093321ac293d68d2e4ab35b982adb53b1d5d6@%3Cdev.commons.apache.org%3E

I have seen about 30 of these mails altogether so far.

The intention was for the developer to capture the exception, check
for the possible programming errors and then inform Commons developers
if they believe there is a bug.

However it looks like the developers in the case have shown the error
message direct to end users.

I think the messages (there are quite a lot in Collections, possibly
elsewhere) should not include an email address. Instead maybe say
something like:

>>
throw new IllegalStateException("Entry.before is null." +
" This should not occur if your keys are immutable, and you have used
synchronization properly." +
>>

This would leave it up to the developers to work out how contact us
once they have eliminated any programming errors. Whilst this is a bit
more work for the developers, I don't think it's unreasonable to
expect developers to know how to report bugs in code they are using.

WDYT?

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

Re: Using email addresses in exception messages

[sebb]

On Mon, 13 May 2019 at 18:42, Bill Igoe  wrote:
>
> In a prop shop long ago , I also emailed all exception messages. It is a
> great way to correct logic errors and capture  potentially sloppy code.
> Graphing the errors resulted in an exponential decline in errors.
>
> I also developed a handy performance tracker for critical algorithms and
> saved those results to a log file.
>
> Helps a ton.

A 'ton' is the appropriate word - there have been over 100 emails to
the dev@commons list complaining about the same problem.
(They have not been moderated through as it would not help)

It's only appropriate to email errors if they are sent to the people
who can do something about the problem.
In this case, that is the website developers who are using Collections
incorrectly.
Furthermore, they have exposed the Exception message to end users,
which means we get the emails direct from end users.

> Cheers to all
>
>
>
>
> On Sun, May 12, 2019 at 3:22 PM Emmanuel Bourg  wrote:
>
> > Le 12/05/2019 à 14:25, Gary Gregory a écrit :
> > > +1 to removing email addresses from exception messages. We should do a
> > pass
> > > over all of Commons.
> >
> > +1, makes sense.
> >
> > Emmanuel Bourg
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

Re: [Text] Case conversion

[sebb]

On Sat, 18 May 2019 at 13:37, Gary Gregory  wrote:
>
> Hi All:
>
> What do you all think about this addition for Commons Text (I currently do
> use it):

I think it's unnecessary and should not be added.


> import java.util.Locale;
>
> /**
>  * Enumerates letter cases and converts strings.
>  *
>  * @author mailto:ggreg...@rocketsoftware.com";>Gary Gregory
>  */
> public enum LetterCase {
>
> LOWER {
> @Override
> public char[] convert(final char[] source, final Locale locale) {
> return String.valueOf(source).toLowerCase(locale).toCharArray();
> }
>
> @Override
> public String convert(final String source, final Locale locale) {
> return source.toLowerCase(locale);
> }
>
> },
> UPPER {
> @Override
> public char[] convert(final char[] source, final Locale locale) {
> return String.valueOf(source).toUpperCase(locale).toCharArray();
> }
>
> @Override
> public String convert(final String source, final Locale locale) {
> return source.toUpperCase(locale);
> }
> };
>
> /**
>  * Converts from the given {@code source} char[] to the case specified
> by this enum using the default {@code locale}.
>  *
>  * @param source
>  *the char[] to convert
>  * @param locale
>  *the locale to use for conversion.
>  * @return a converted char[].
>  */
> public char[] convert(final char[] source) {
> return convert(source, Locale.getDefault());
> }
>
> /**
>  * Converts from the given {@code source} char[] to the case specified
> by this enum using the given {@code locale}.
>  *
>  * @param source
>  *the char[] to convert
>  * @param locale
>  *the locale to use for conversion.
>  * @return a converted char[].
>  */
> public abstract char[] convert(char[] source, Locale locale);
>
> /**
>  * Converts from the given {@code source} string to the case specified
> by this enum using the default {@code locale}.
>  *
>  * @param source
>  *the string to convert
>  * @param locale
>  *the locale to use for conversion.
>  * @return a converted string.
>  */
> public String convert(final String source) {
> return convert(source, Locale.getDefault());
> }
>
> /**
>  * Converts from the given {@code source} string to the case specified
> by this enum using the given {@code locale}.
>  *
>  * @param source
>  *the string to convert
>  * @param locale
>  *the locale to use for conversion.
>  * @return a converted string.
>  */
> public abstract String convert(String source, Locale locale);
>
> }
>
> ?
>
> Gary

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

Re: [IO] Update to Java 8

[sebb]

On Sat, 18 May 2019 at 12:51, Gary Gregory  wrote:
>
> On Thu, May 16, 2019 at 3:40 PM Chesney, Mark 
> wrote:
>
> > I think it's a good idea. A recent update of the parent POM version seems
> > to have broken the Travis build for Java 7. Discontinuing Java 7 support
> > would make that a non-issue.
> >
>
> I fixed that a couple of days ago:
>
> https://github.com/apache/commons-io/commit/6d46195e7cac37c28dd58f462e2d15cc1b1eb388

Ideally we should fix CP so it uses the relevant version of felix for
Java 1.7 builds.

> Gary
>
>
> >
> > > -Original Message-
> > > From: Rob Tompkins 
> > > Sent: Thursday, May 16, 2019 8:10 AM
> > > To: Commons Developers List 
> > > Subject: Re: [IO] Update to Java 8
> > >
> > >
> > > On 5/15/2019 2:42 PM, Gary Gregory wrote:
> > > > Hi all,
> > > >
> > > > Time to update to Java 8 methinks.
> > >
> > > +1
> > >
> > > >
> > > > Gary
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

Re: [Configuration] Optional Includes in Properties files

[sebb]

On Mon, 20 May 2019 at 14:58, Gary Gregory  wrote:
>
> On Mon, May 20, 2019 at 9:16 AM Gilles Sadowski 
> wrote:
>
> > Le lun. 20 mai 2019 à 14:51, Gary Gregory  a
> > écrit :
> > >
> > > Hi All:
> > >
> > > Right now, if you uses an 'include' in a properties file and that file is
> > > missing, the rest of the file does not load.
> >
> > IMHO, it seems like a bug.
> >
> > If the contents is required, failure should occur because of that
> > (later, according to code logic), not because the file is missing.
> >
> > > I'd like to add a 'includesoptional' where nothing happens if the file is
> > > missing.
> > >
> > > Any objections or thoughts on a better name?
> >
> > includeifexist
> > (?)
> >
>
> Maybe; with includeoptional, I was imitating
> https://httpd.apache.org/docs/2.4/mod/core.html#includeoptional

I find includeoptional marginally easier to read.
And it avoids having to remember if the spelling is includeifexist or
includeifexists

But I agree with Gilles that it seems like a bug if a missing include
does not throw an error.

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

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

Re: [rng] binary compatibility with final modifier

[sebb]

Are the classes supposed to be final?
Or just the existing constructor(s)?

On Thu, 23 May 2019 at 12:51, Gilles Sadowski  wrote:
>
> Hello.
>
> Le jeu. 23 mai 2019 à 13:43, Alex Herbert  a écrit :
> >
> > [rng] has three classes with a private constructor that are not
> > currently marked as final. 1 is public and 2 are package private.
> >
> > If I mark them as final then clirr:check ignores the package private
> > ones and produces this warning for the public one:
>
> If it's a "Warning" and not an "Error", I don't think that it could
> count as a release blocker.  [Confirmation from PMC members
> welcome...]
>
> >
> > "Added final modifier to class, but class was effectively final anyway"
> >
> >
> > Given the class could not have been extended (due to a private
> > constructor) it seems OK to allow the final modifier.
>
> I think so.
>
> >
> > So can the final modifier be added? Is there a precedent here with
> > regard to releases?
>
> Cf. above.
>
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: svn commit: r1859859 [1/5] - in /commons/proper/jcs/trunk/commons-jcs-core/src: main/java/org/apache/commons/jcs/ main/java/org/apache/commons/jcs/access/ main/java/org/apache/commons/jcs/admin/ m

[sebb]

On Fri, 24 May 2019 at 11:34, Gary Gregory  wrote:
>
> -1
>
> We are now on gitbox https://gitbox.apache.org/repos/asf/commons-jcs.git
>
> We have to make the old repos read only.

We did make commons/proper read-only for most people.
However members of the Commons PMC are still allowed to update them if
necessary.

I don't know if all the tidying up has been done yet, so it might be
premature to change access for PMC members.

> Gary
>
> On Fri, May 24, 2019, 05:26  wrote:
>
> > Author: tv
> > Date: Fri May 24 09:26:50 2019
> > New Revision: 1859859
> >
> > URL: http://svn.apache.org/viewvc?rev=1859859&view=rev
> > Log:
> > Use Java7 diamond operator
> >
> > Modified:
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/JCS.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/access/CacheAccess.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/access/GroupCacheAccess.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/access/PartitionedCacheAccess.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/admin/JCSAdminBean.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/AbstractAuxiliaryCache.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/AbstractDiskCache.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/block/BlockDisk.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/block/BlockDiskCache.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/block/BlockDiskCacheFactory.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/block/BlockDiskKeyStore.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/indexed/IndexedDiskCache.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/indexed/IndexedDiskCacheFactory.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/indexed/IndexedDiskDumper.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/jdbc/JDBCDiskCache.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/jdbc/JDBCDiskCacheFactory.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/jdbc/ShrinkerThread.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/jdbc/dsfactory/JndiDataSourceFactory.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/jdbc/hsql/HSQLDiskCacheFactory.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/jdbc/mysql/MySQLDiskCacheFactory.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/LateralCache.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/LateralCacheMonitor.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/LateralCacheNoWait.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/LateralCacheNoWaitFacade.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/socket/tcp/LateralTCPCacheFactory.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/socket/tcp/LateralTCPDiscoveryListener.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/socket/tcp/LateralTCPListener.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/socket/tcp/LateralTCPService.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/AbstractRemoteAuxiliaryCache.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/AbstractRemoteCacheNoWaitFacade.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/RemoteCache.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/RemoteCacheFactory.java
> >
> > commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/RemoteCacheManager.java
> >
> > commons/proper/jcs/trunk/commons-

Lost SVN updates following conversion to Git

[sebb]

Some updates have been made to the Commons 'proper' SVN repos since
they were converted to Git.

Such changes should not have been made, as they are not automatically
reflected in the Git repos.

I think we need to do the following:

- revert the spurious changes so SVN reflects the state at conversion
(I am working on a list of the updates that were made after conversion)

- create PRs/JIRAs for the changes that are still needed

- make it harder to accidentally update the SVN repos for Commons
proper components
The simplest way to stop further updates is probably to rename the SVN
directory from /proper to /_moved_to_git. This will still allow
updates by PMC members, but it's much more obvious that the SVN repo
should no longer be updated.

WDYT?
S.

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

Re: Lost SVN updates following conversion to Git

[sebb]

On Fri, 24 May 2019 at 22:37, Emmanuel Bourg  wrote:
>
> Le 24/05/2019 à 22:59, sebb a écrit :
>
> > The simplest way to stop further updates is probably to rename the SVN
> > directory from /proper to /_moved_to_git. This will still allow
> > updates by PMC members, but it's much more obvious that the SVN repo
> > should no longer be updated.
>
> Couldn't we set the ACL on the /proper path to read-only instead? At
> least it doesn't break the URLs pointing to the current path.

Yes, that would also be possible, but that can only be done by INFRA,
and can only be done when all the components have been fixed.
Also it might give a false impression of the state of the project.
I think it would be better to replace the tree with a readme pointing
to the new location.

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

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

Re: Lost SVN updates following conversion to Git

[sebb]

On Sat, 25 May 2019 at 00:13, Gary Gregory  wrote:
>
> I like the pointer idea.

This is an example of what we did for the original moves:

http://svn.apache.org/repos/asf/commons/proper/io/IoNowUsesGit.txt

> Gary
>
> On Fri, May 24, 2019, 18:35 sebb  wrote:
>
> > On Fri, 24 May 2019 at 22:37, Emmanuel Bourg  wrote:
> > >
> > > Le 24/05/2019 à 22:59, sebb a écrit :
> > >
> > > > The simplest way to stop further updates is probably to rename the SVN
> > > > directory from /proper to /_moved_to_git. This will still allow
> > > > updates by PMC members, but it's much more obvious that the SVN repo
> > > > should no longer be updated.
> > >
> > > Couldn't we set the ACL on the /proper path to read-only instead? At
> > > least it doesn't break the URLs pointing to the current path.
> >
> > Yes, that would also be possible, but that can only be done by INFRA,
> > and can only be done when all the components have been fixed.
> > Also it might give a false impression of the state of the project.
> > I think it would be better to replace the tree with a readme pointing
> > to the new location.
> >
> > > Emmanuel Bourg
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

scm.html or source-repository.html?

[sebb]

Why do some components use:

http://commons.apache.org/proper/commons-lang/scm.html
and some use
http://commons.apache.org/proper/commons-math/source-repository.html

They have the same content, so why the different URLs?

Should we standardise on one (and add redirects for the other?)

Are there any other discrepancies in the standard page names?

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

Re: scm.html or source-repository.html?

[sebb]

On Sat, 25 May 2019 at 12:25, Maxim Solodovnik  wrote:
>
> This is caused by different versions of maven-project-info-reports-plugin
>
> https://maven.apache.org/plugins/maven-project-info-reports-plugin/#Incompatibility_Notice
>

I see, thanks for the info.

==

That's a big nuisance.
We cannot remain on the original version of the plugin forever so we
are forced to break the existing URLs.

Question is: what do we do about it, if anything?

>
> On Sat, 25 May 2019 at 17:24, sebb  wrote:
>
> > Why do some components use:
> >
> > http://commons.apache.org/proper/commons-lang/scm.html
> > and some use
> > http://commons.apache.org/proper/commons-math/source-repository.html
> >
> > They have the same content, so why the different URLs?
> >
> > Should we standardise on one (and add redirects for the other?)
> >
> > Are there any other discrepancies in the standard page names?
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
> --
> WBR
> Maxim aka solomax

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

Re: Changes to SVN proper that have occurred since move to Git

[sebb]

Forgot to say that I have yet to check the commons-* trees (commons-build etc)

On Sun, 26 May 2019 at 13:13, sebb  wrote:
>
> I've done a comparison of the latest SVN revision with the most recent
> trunk(master) Git entry that includes a line of the following form:
> git-svn-id: 
> https://svn-us.apache.org/repos/asf/commons/proper/jexl/trunk@1821853
> 13f79535-47bb-0310-9956-ffa450edef68
>
> AFAICT any discrepancies mean that the SVN repo has been updated since
> the move to Git.
>
> I have moved all [1] the components to _moved_to_git where the latest
> SVN revision agrees with the latest git-svn-id comment in the trunk
> log.
>
> The following 4 components have had changes to SVN that don't appear
> in the SVN-Git conversion comments. I've listed the changes following
> the summary line.
>
>
> bcel git-svn-id='1852359' SVN='1852455'
> 
> r1852455 | ggregory | 2019-01-29 14:10:43 + (Tue, 29 Jan 2019) | 1 line
>
> Use proper hashes.
> 
>
>
>
> beanutils git-svn-id='1852248' SVN='1852822'
> 
> r1852822 | britter | 2019-02-03 09:57:04 + (Sun, 03 Feb 2019) | 1 line
>
> Drop ant build
> 
>
>
>
> jcs git-svn-id='1852304' SVN='1859859'
> 
> r1858701 | tv | 2019-05-05 18:59:39 +0100 (Sun, 05 May 2019) | 1 line
>
> Remove most Iterators
> 
> r1859280 | tv | 2019-05-15 10:27:20 +0100 (Wed, 15 May 2019) | 1 line
>
> JCS-195 Update element attributes size on serialization
> 
> r1859283 | tv | 2019-05-15 10:43:32 +0100 (Wed, 15 May 2019) | 1 line
>
> Remove duplicate code
> 
> r1859284 | tv | 2019-05-15 10:44:22 +0100 (Wed, 15 May 2019) | 1 line
>
> JCS-195 Update element attributes size on serialization
> 
> r1859285 | tv | 2019-05-15 10:44:56 +0100 (Wed, 15 May 2019) | 1 line
>
> Make all statistic numbers long
> 
> r1859286 | tv | 2019-05-15 10:45:24 +0100 (Wed, 15 May 2019) | 1 line
>
> Remove synchronized sections
> 
> r1859289 | tv | 2019-05-15 13:46:21 +0100 (Wed, 15 May 2019) | 1 line
>
> JCS-194 NullPointerException in IndexedDiskCache.addToRecycleBin(...)
> 
> r1859857 | tv | 2019-05-24 10:12:04 +0100 (Fri, 24 May 2019) | 1 line
>
> Use lambdas for Runnables
> 
> r1859859 | tv | 2019-05-24 10:26:50 +0100 (Fri, 24 May 2019) | 1 line
>
> Use Java7 diamond operator
> 
>
>
>
> jexl git-svn-id='1821853' SVN='1831656'
> 
> r1831656 | ggregory | 2018-05-15 19:57:05 +0100 (Tue, 15 May 2018) | 1 line
>
> Typo: 'JavaDoc' -> 'Javadoc'.
> 
>
>
> [1] I had to leave weaver for now as it is currently read-only; I will
> fix that shortly.

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

Changes to SVN proper that have occurred since move to Git

[sebb]

I've done a comparison of the latest SVN revision with the most recent
trunk(master) Git entry that includes a line of the following form:
git-svn-id: 
https://svn-us.apache.org/repos/asf/commons/proper/jexl/trunk@1821853
13f79535-47bb-0310-9956-ffa450edef68

AFAICT any discrepancies mean that the SVN repo has been updated since
the move to Git.

I have moved all [1] the components to _moved_to_git where the latest
SVN revision agrees with the latest git-svn-id comment in the trunk
log.

The following 4 components have had changes to SVN that don't appear
in the SVN-Git conversion comments. I've listed the changes following
the summary line.


bcel git-svn-id='1852359' SVN='1852455'

r1852455 | ggregory | 2019-01-29 14:10:43 + (Tue, 29 Jan 2019) | 1 line

Use proper hashes.




beanutils git-svn-id='1852248' SVN='1852822'

r1852822 | britter | 2019-02-03 09:57:04 + (Sun, 03 Feb 2019) | 1 line

Drop ant build




jcs git-svn-id='1852304' SVN='1859859'

r1858701 | tv | 2019-05-05 18:59:39 +0100 (Sun, 05 May 2019) | 1 line

Remove most Iterators

r1859280 | tv | 2019-05-15 10:27:20 +0100 (Wed, 15 May 2019) | 1 line

JCS-195 Update element attributes size on serialization

r1859283 | tv | 2019-05-15 10:43:32 +0100 (Wed, 15 May 2019) | 1 line

Remove duplicate code

r1859284 | tv | 2019-05-15 10:44:22 +0100 (Wed, 15 May 2019) | 1 line

JCS-195 Update element attributes size on serialization

r1859285 | tv | 2019-05-15 10:44:56 +0100 (Wed, 15 May 2019) | 1 line

Make all statistic numbers long

r1859286 | tv | 2019-05-15 10:45:24 +0100 (Wed, 15 May 2019) | 1 line

Remove synchronized sections

r1859289 | tv | 2019-05-15 13:46:21 +0100 (Wed, 15 May 2019) | 1 line

JCS-194 NullPointerException in IndexedDiskCache.addToRecycleBin(...)

r1859857 | tv | 2019-05-24 10:12:04 +0100 (Fri, 24 May 2019) | 1 line

Use lambdas for Runnables

r1859859 | tv | 2019-05-24 10:26:50 +0100 (Fri, 24 May 2019) | 1 line

Use Java7 diamond operator




jexl git-svn-id='1821853' SVN='1831656'

r1831656 | ggregory | 2018-05-15 19:57:05 +0100 (Tue, 15 May 2018) | 1 line

Typo: 'JavaDoc' -> 'Javadoc'.



[1] I had to leave weaver for now as it is currently read-only; I will
fix that shortly.

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

Re: svn commit: r1859859 [1/5] - in /commons/proper/jcs/trunk/commons-jcs-core/src: main/java/org/apache/commons/jcs/ main/java/org/apache/commons/jcs/access/ main/java/org/apache/commons/jcs/admin/ m

[sebb]

On Sun, 26 May 2019 at 12:27, Thomas Vandahl  wrote:
>
> On 24.05.19 12:33, Gary Gregory wrote:
> > -1
> >
> > We are now on gitbox https://gitbox.apache.org/repos/asf/commons-jcs.git
> >
>
> When did that happen? I don't remember an announcement or a vote.

Jan 2019

https://lists.apache.org/thread.html/053bb8f18e90800d918956f69364167b23c0cdca175568300b1108f6@%3Cdev.commons.apache.org%3E


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

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

Re: Changes to SVN proper that have occurred since move to Git

[sebb]

I think all but jcs have now been dealt with.

On Sun, 26 May 2019 at 13:28, sebb  wrote:
>
> Forgot to say that I have yet to check the commons-* trees (commons-build etc)
>
> On Sun, 26 May 2019 at 13:13, sebb  wrote:
> >
> > I've done a comparison of the latest SVN revision with the most recent
> > trunk(master) Git entry that includes a line of the following form:
> > git-svn-id: 
> > https://svn-us.apache.org/repos/asf/commons/proper/jexl/trunk@1821853
> > 13f79535-47bb-0310-9956-ffa450edef68
> >
> > AFAICT any discrepancies mean that the SVN repo has been updated since
> > the move to Git.
> >
> > I have moved all [1] the components to _moved_to_git where the latest
> > SVN revision agrees with the latest git-svn-id comment in the trunk
> > log.
> >
> > The following 4 components have had changes to SVN that don't appear
> > in the SVN-Git conversion comments. I've listed the changes following
> > the summary line.
> >
> >
> > bcel git-svn-id='1852359' SVN='1852455'
> > 
> > r1852455 | ggregory | 2019-01-29 14:10:43 + (Tue, 29 Jan 2019) | 1 line
> >
> > Use proper hashes.
> > 
> >
> >
> >
> > beanutils git-svn-id='1852248' SVN='1852822'
> > 
> > r1852822 | britter | 2019-02-03 09:57:04 + (Sun, 03 Feb 2019) | 1 line
> >
> > Drop ant build
> > 
> >
> >
> >
> > jcs git-svn-id='1852304' SVN='1859859'
> > 
> > r1858701 | tv | 2019-05-05 18:59:39 +0100 (Sun, 05 May 2019) | 1 line
> >
> > Remove most Iterators
> > 
> > r1859280 | tv | 2019-05-15 10:27:20 +0100 (Wed, 15 May 2019) | 1 line
> >
> > JCS-195 Update element attributes size on serialization
> > 
> > r1859283 | tv | 2019-05-15 10:43:32 +0100 (Wed, 15 May 2019) | 1 line
> >
> > Remove duplicate code
> > 
> > r1859284 | tv | 2019-05-15 10:44:22 +0100 (Wed, 15 May 2019) | 1 line
> >
> > JCS-195 Update element attributes size on serialization
> > 
> > r1859285 | tv | 2019-05-15 10:44:56 +0100 (Wed, 15 May 2019) | 1 line
> >
> > Make all statistic numbers long
> > 
> > r1859286 | tv | 2019-05-15 10:45:24 +0100 (Wed, 15 May 2019) | 1 line
> >
> > Remove synchronized sections
> > 
> > r1859289 | tv | 2019-05-15 13:46:21 +0100 (Wed, 15 May 2019) | 1 line
> >
> > JCS-194 NullPointerException in IndexedDiskCache.addToRecycleBin(...)
> > 
> > r1859857 | tv | 2019-05-24 10:12:04 +0100 (Fri, 24 May 2019) | 1 line
> >
> > Use lambdas for Runnables
> > 
> > r1859859 | tv | 2019-05-24 10:26:50 +0100 (Fri, 24 May 2019) | 1 line
> >
> > Use Java7 diamond operator
> > 
> >
> >
> >
> > jexl git-svn-id='1821853' SVN='1831656'
> > 
> > r1831656 | ggregory | 2018-05-15 19:57:05 +0100 (Tue, 15 May 2018) | 1 line
> >
> > Typo: 'JavaDoc' -> 'Javadoc'.
> > 
> >
> >
> > [1] I had to leave weaver for now as it is currently read-only; I will
> > fix that shortly.

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

Re: svn commit: r1859859 [1/5] - in /commons/proper/jcs/trunk/commons-jcs-core/src: main/java/org/apache/commons/jcs/ main/java/org/apache/commons/jcs/access/ main/java/org/apache/commons/jcs/admin/ m

[sebb]

On Sun, 26 May 2019 at 17:42, Thomas Vandahl  wrote:
>
> On 26.05.19 15:54, sebb wrote:
> > Jan 2019
> >
> > https://lists.apache.org/thread.html/053bb8f18e90800d918956f69364167b23c0cdca175568300b1108f6@%3Cdev.commons.apache.org%3E
>
> Ok, I missed that one completely.
> What do I have to do?

Either re-apply each of the commits in turn to Git.

If there have been no changes to the Git repo, maybe ask Infra if the
repo can be re-converted from the new baseline, replacing the existing
Git copy.

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

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

Re: Proposal to introduce JUnit 5 in commons-numbers

[sebb]

On Tue, 28 May 2019 at 21:44, Karl Heinz Marbaise  wrote:
>
> Hi,
>
> just a small comment of mine.
>
> to get very good support for exceptions etc. I would suggest to use
> assertj which will work in JUnit 4 and Jupiter (aka 5)...

What License does it use?

> Furthermore I would not rely on a unit testing framework for assertions
> which others can do better like assertj does.
>
> Snippets from the Docs:
>
> assertThatThrownBy(() -> { throw new Exception("boom!"); })
> .isInstanceOf(Exception.class)
> .hasMessageContaining("boom");
>
> or:
>
> assertThatExceptionOfType(IOException.class)
> .isThrownBy(() -> { throw new IOException("boom!"); })
> .withMessage("%s!", "boom")
> .withMessageContaining("boom")
> .withNoCause();
>
> Real code example:
>
> assertThatIllegalArgumentException()
>.isThrownBy(() -> Complex.parse(re + "," + im + ")"));
> (This is the equivalent of using
> @Test(expected=IllegalArgumentException.class))...
> but you can also check the message very easy:
>
> assertThatIllegalArgumentException()
>.isThrownBy(() -> Complex.parse(re + "," + im +
> ")")).withMessage("");
>
> Another code example:
>
> current code:
> Assert.assertTrue(Complex.ofCartesian(re, im).equals(Complex.parse(str)));

Should not be doing comparisons that way as the expected and actual
values are not shown...

> And this it would looks like with AssertJ:
>
> assertThat(Complex.parse(str)).isEqualTo(Complex.ofCartesian(re, im));

Note that the expected and actual values are the other way round from JUnit.
This could cause some confusion; care will need to be taken when converting.

Especially since there is likely to be existing code with expected and
actual the wrong way round.
I found (and fixed!) quite a lot of that in Commons code in the past;
I expect there is more.

>
> Furthermore (current code):
>
>  Assert.assertTrue(Double.isNaN(nanZero.getArgument()));
>  Assert.assertTrue(Double.isNaN(zeroNaN.getArgument()));
>  Assert.assertTrue(Double.isNaN(NAN.getArgument()));

Again, surely one would use a comparison with expected and actual?

> via AssertJ:
>
>  assertThat(nanZero.getArgument()).isNaN();
>  assertThat(zeroNaN.getArgument()).isNaN();
>  assertThat(NAN.getArgument()).isNaN();
>
>
> Furthermore about  the subject for running JUnit 4 and JUnit Jupiter
> (aka 5) in one build can be simply handled by just using the following
> dependencies instead of JUnit 4:
>
>
>  
>org.junit.jupiter
>junit-jupiter-engine
>5.4.2
>test
>  
>  
>org.junit.vintage
>junit-vintage-engine
>5.4.2
>test
>  
>
>
> That gives you the opportunity to write your Tests with JUnit 4 and also
> with JUnit Jupiter aka JUnit 5. This would help to get a smooth
> transition to JUnit 5.
>
>
> I have created a branch
> https://github.com/khmarbaise/commons-numbers/tree/JUNIT5-ASSERTJ where
> you can take a look how such tests could look like and running together
> JUnit 4 / JUnit Jupiter (aka JUnit 5)...also
> some examples how using assertj looks like in particular for assertions
> about Exceptions inlcuding the messages.
>
> (Just as an example not meant to be a real pull request cause that is
> not finished yet. This can be improved much more)...
>
> Those tests show me the exception messages in CoseAngle need some
> improvement (missing space).
>
> * ComplexTest using assertj assertions
> * CosAngleTest using junit 5 + assertj assertions..
>
>
> Kind regards
> Karl Heinz Marbaise
>
> [1]:
> https://joel-costigliola.github.io/assertj/assertj-core-features-highlight.html#exception-assertion
>
> On 22.05.19 18:34, Heinrich Bohne wrote:
> > Right now, commons-numbers is using JUnit 4.12, the last stable version
> > of JUnit 4. As far as I am aware, there is no explicit syntax in JUnit
> > 4.12 for testing whether an exception is thrown apart from either using
> > the deprecated class ExpectedException or adding the "expected"
> > parameter to the Test annotation. The problem with the latter approach
> > is that it is impossible to ascertain where exactly in the annotated
> > method the exception is thrown – it could be thrown somewhere unexpected
> > and the test will still pass. Besides, when testing the same exception
> > trigger with multiple different inputs, it is impractical to create a
> > separate method for each test case, which would be necessary with both
> > aforementioned approaches.
> >
> > This has led to the creation of constructs where the expected exception
> > is swallowed, which has been deemed undesirable
> > .
> >
> > Because of this, I propose to add JUnit 5 as a dependency in
> > commons-numbers. JUnit 5 has several "assertThrows" methods that would
> > solve the described dilemma.
> >
>
> -

Re: svn commit: r1859859 [1/5] - in /commons/proper/jcs/trunk/commons-jcs-core/src: main/java/org/apache/commons/jcs/ main/java/org/apache/commons/jcs/access/ main/java/org/apache/commons/jcs/admin/ m

[sebb]

Thanks, I've reverted SVN back to r1852304 which corresponds to git
ad897014842fc830483f32fdfb903f3bb8f70289, i.e. immediately after
conversion to Git.

Also moved SVN to _moved_to_git

On Wed, 29 May 2019 at 07:02, Thomas Vandahl  wrote:
>
> On 27.05.19 10:21, sebb wrote:
> > Either re-apply each of the commits in turn to Git.
> Done.
>
> Bye, Thomas
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

[ALL] Issues with Git repos: bad HEADs and unexpected refs - need Git guru

[sebb]

I noticed that JCS still has a trunk branch and that appears to be the
default, so I did a check of all the commons git repos.

The command used is:

git ls-remote #{repo} HEAD master trunk
where repo = https://gitbox.apache.org/repos/asf/{commons-???}.git

I then compared the hashes for HEAD and refs/heads/master.
If different, then the HEAD is not master.

Some of the repos have references other than HEAD, refs/heads/master
or refs/remotes/trunk (which I assume are OK?)

The discrepancies are listed below.

The most important ones are obviously the ones with bad heads - I
guess we should ask Infra to reset those. But what if changes have
been made to trunk?

I don't know what to do about the additional references, if anything.

Unexpected HEADs:

https://gitbox.apache.org/repos/asf/commons-configuration.git
61732d3c65cbfae58d71e2dd55caf8760a9aa642 HEAD **not master**
61732d3c65cbfae58d71e2dd55caf8760a9aa642 refs/heads/trunk REF?
61732d3c65cbfae58d71e2dd55caf8760a9aa642 refs/remotes/trunk
96720ced6f263462aaae7217392399267b1d141f refs/heads/master

https://gitbox.apache.org/repos/asf/commons-jcs.git
ad897014842fc830483f32fdfb903f3bb8f70289 HEAD **not master**
ad897014842fc830483f32fdfb903f3bb8f70289 refs/heads/trunk REF?
ad897014842fc830483f32fdfb903f3bb8f70289 refs/remotes/trunk
b59d43e64e3759dac71b4b68bf43f3ac32d484c3 refs/heads/master


Unexpected REFS (HEAD looks OK):

https://gitbox.apache.org/repos/asf/commons-weaver.git
141e820c70fa3a86d49b740076b11ba50dc8b456 refs/remotes/origin/master REF?
9329b1486e28b4d7112dc30ba381892dccb924db refs/remotes/trunk
a88dbbbd76aed4ac98d94ceb2e1bc9bd2183aa84 HEAD
a88dbbbd76aed4ac98d94ceb2e1bc9bd2183aa84 refs/heads/master

https://gitbox.apache.org/repos/asf/commons-logging.git
0548efba5be8c7dd04f71d81e642488fec6f5472 HEAD
0548efba5be8c7dd04f71d81e642488fec6f5472 refs/heads/master
0548efba5be8c7dd04f71d81e642488fec6f5472 refs/heads/trunk REF?
0548efba5be8c7dd04f71d81e642488fec6f5472 refs/remotes/trunk
e7f1bbad19cbd1f4ed3085b83d2866c9bc247815 refs/original/refs/remotes/trunk REF?

https://gitbox.apache.org/repos/asf/commons-codec.git
163d643d1176e0dc9334ee83e21b9ce21d24fc1a refs/remotes/trunk
3ee99ea6cabeee96d5dfbb45e43b1e8cf74a9929 refs/original/refs/heads/trunk REF?
3ee99ea6cabeee96d5dfbb45e43b1e8cf74a9929 refs/original/refs/remotes/trunk REF?
48b615756d1d770091ea3322eefc08011ee8b113 HEAD
48b615756d1d770091ea3322eefc08011ee8b113 refs/heads/master

https://gitbox.apache.org/repos/asf/commons-proxy.git
838024d7d8193d181506568fec9e681b6e11e59a HEAD
838024d7d8193d181506568fec9e681b6e11e59a refs/heads/master
838024d7d8193d181506568fec9e681b6e11e59a refs/heads/trunk REF?
838024d7d8193d181506568fec9e681b6e11e59a refs/remotes/trunk

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

Re: Changes to SVN proper that have occurred since move to Git

[sebb]

FTR jcs has also now been sorted

On Sun, 26 May 2019 at 15:27, sebb  wrote:
>
> I think all but jcs have now been dealt with.
>
> On Sun, 26 May 2019 at 13:28, sebb  wrote:
> >
> > Forgot to say that I have yet to check the commons-* trees (commons-build 
> > etc)
> >
> > On Sun, 26 May 2019 at 13:13, sebb  wrote:
> > >
> > > I've done a comparison of the latest SVN revision with the most recent
> > > trunk(master) Git entry that includes a line of the following form:
> > > git-svn-id: 
> > > https://svn-us.apache.org/repos/asf/commons/proper/jexl/trunk@1821853
> > > 13f79535-47bb-0310-9956-ffa450edef68
> > >
> > > AFAICT any discrepancies mean that the SVN repo has been updated since
> > > the move to Git.
> > >
> > > I have moved all [1] the components to _moved_to_git where the latest
> > > SVN revision agrees with the latest git-svn-id comment in the trunk
> > > log.
> > >
> > > The following 4 components have had changes to SVN that don't appear
> > > in the SVN-Git conversion comments. I've listed the changes following
> > > the summary line.
> > >
> > >
> > > bcel git-svn-id='1852359' SVN='1852455'
> > > 
> > > r1852455 | ggregory | 2019-01-29 14:10:43 + (Tue, 29 Jan 2019) | 1 
> > > line
> > >
> > > Use proper hashes.
> > > 
> > >
> > >
> > >
> > > beanutils git-svn-id='1852248' SVN='1852822'
> > > 
> > > r1852822 | britter | 2019-02-03 09:57:04 + (Sun, 03 Feb 2019) | 1 line
> > >
> > > Drop ant build
> > > 
> > >
> > >
> > >
> > > jcs git-svn-id='1852304' SVN='1859859'
> > > 
> > > r1858701 | tv | 2019-05-05 18:59:39 +0100 (Sun, 05 May 2019) | 1 line
> > >
> > > Remove most Iterators
> > > 
> > > r1859280 | tv | 2019-05-15 10:27:20 +0100 (Wed, 15 May 2019) | 1 line
> > >
> > > JCS-195 Update element attributes size on serialization
> > > 
> > > r1859283 | tv | 2019-05-15 10:43:32 +0100 (Wed, 15 May 2019) | 1 line
> > >
> > > Remove duplicate code
> > > 
> > > r1859284 | tv | 2019-05-15 10:44:22 +0100 (Wed, 15 May 2019) | 1 line
> > >
> > > JCS-195 Update element attributes size on serialization
> > > 
> > > r1859285 | tv | 2019-05-15 10:44:56 +0100 (Wed, 15 May 2019) | 1 line
> > >
> > > Make all statistic numbers long
> > > 
> > > r1859286 | tv | 2019-05-15 10:45:24 +0100 (Wed, 15 May 2019) | 1 line
> > >
> > > Remove synchronized sections
> > > 
> > > r1859289 | tv | 2019-05-15 13:46:21 +0100 (Wed, 15 May 2019) | 1 line
> > >
> > > JCS-194 NullPointerException in IndexedDiskCache.addToRecycleBin(...)
> > > 
> > > r1859857 | tv | 2019-05-24 10:12:04 +0100 (Fri, 24 May 2019) | 1 line
> > >
> > > Use lambdas for Runnables
> > > 
> > > r1859859 | tv | 2019-05-24 10:26:50 +0100 (Fri, 24 May 2019) | 1 line
> > >
> > > Use Java7 diamond operator
> > > 
> > >
> > >
> > >
> > > jexl git-svn-id='1821853' SVN='1831656'
> > > 
> > > r1831656 | ggregory | 2018-05-15 19:57:05 +0100 (Tue, 15 May 2018) | 1 
> > > line
> > >
> > > Typo: 'JavaDoc' -> 'Javadoc'.
> > > 
> > >
> > >
> > > [1] I had to leave weaver for now as it is currently read-only; I will
> > > fix that shortly.

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

Re: [All] Alpha/beta releases

[sebb]

I'm not sure what problem this is trying to solve.

How is it intended to use the facility?

On Tue, 4 Jun 2019 at 17:35, Matt Sicker  wrote:
>
> This sounds like a shade feature, yes. However, in order to
> automatically extract the version extra data and detect a version
> keyword like "alpha" may require some additional code, though maybe
> the shade plugin already supports that.
>
> Alternatively, JUnit 5.x uses a tool called API Guardian for marking
> which APIs are stable or not:
> https://github.com/apiguardian-team/apiguardian
>
> On Tue, 4 Jun 2019 at 05:53, Gilles Sadowski  wrote:
> >
> > Hello.
> >
> > Does someone see a practical way to automate package names
> > and source files conversions so that each all alpha/beta releases
> > can be used together (e.g. to compare their behaviours).
> >
> > I mean, for release version "1.0-alpha1", the top-level package
> > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> >
> > This would also solve issues with compatibility checkers (with the
> > added bonus that JAR hell could never happen).
> >
> > Couldn't the "shade" plugin be put to use (so that all artefacts have
> > their top-level package transparently set to "o.a.c.compid.alpha1"
> > and all the tools operate on that)?
> >
> >
> > Regards,
> > Gilles
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> --
> Matt Sicker 
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [All] Alpha/beta releases

[sebb]

On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski  wrote:
>
> Le mer. 5 juin 2019 à 15:18, sebb  a écrit :
> >
> > I'm not sure what problem this is trying to solve.
> >
> > How is it intended to use the facility?
>
> Ideally:
> $ mvn -Pbetarelease [... other settings ...] -Dbetasubversion=alpha1
> where the latter profile would take care of changing the
> toplevel package name
> o.a.c.somecomp
> to
> o.a.c.somecomp.alpha1
>
> And, if the upcoming version is, say, "2.3", the generated
> artefact(s) would be:
>   commons-somecomp-2.3-alpha1

That's not what I intended to ask.

What problem does the ability to readily change the package name actually solve?
And how are the amended packages going to be used?

> Regards,
> Gilles
>
> >
> > On Tue, 4 Jun 2019 at 17:35, Matt Sicker  wrote:
> > >
> > > This sounds like a shade feature, yes. However, in order to
> > > automatically extract the version extra data and detect a version
> > > keyword like "alpha" may require some additional code, though maybe
> > > the shade plugin already supports that.
> > >
> > > Alternatively, JUnit 5.x uses a tool called API Guardian for marking
> > > which APIs are stable or not:
> > > https://github.com/apiguardian-team/apiguardian
> > >
> > > On Tue, 4 Jun 2019 at 05:53, Gilles Sadowski  wrote:
> > > >
> > > > Hello.
> > > >
> > > > Does someone see a practical way to automate package names
> > > > and source files conversions so that each all alpha/beta releases
> > > > can be used together (e.g. to compare their behaviours).
> > > >
> > > > I mean, for release version "1.0-alpha1", the top-level package
> > > > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> > > >
> > > > This would also solve issues with compatibility checkers (with the
> > > > added bonus that JAR hell could never happen).
> > > >
> > > > Couldn't the "shade" plugin be put to use (so that all artefacts have
> > > > their top-level package transparently set to "o.a.c.compid.alpha1"
> > > > and all the tools operate on that)?
> > > >
> > > >
> > > > Regards,
> > > > Gilles
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > >
> > >
> > > --
> > > Matt Sicker 
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [All] Alpha/beta releases

[sebb]

On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski  wrote:
>
> Le mer. 5 juin 2019 à 15:59, sebb  a écrit :
> >
> > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski  wrote:
> > >
> > > Le mer. 5 juin 2019 à 15:18, sebb  a écrit :
> > > >
> > > > I'm not sure what problem this is trying to solve.
> > > >
> > > > How is it intended to use the facility?
> > >
> > > Ideally:
> > > $ mvn -Pbetarelease [... other settings ...] -Dbetasubversion=alpha1
> > > where the latter profile would take care of changing the
> > > toplevel package name
> > > o.a.c.somecomp
> > > to
> > > o.a.c.somecomp.alpha1
> > >
> > > And, if the upcoming version is, say, "2.3", the generated
> > > artefact(s) would be:
> > >   commons-somecomp-2.3-alpha1
> >
> > That's not what I intended to ask.
> >
> > What problem does the ability to readily change the package name actually 
> > solve?
> > And how are the amended packages going to be used?
>
> Maybe, I don't understand the question.
> The purpose is to be able to quickly produce several beta releases that
> don't have to be compatible with other beta releases but that can coexist
> for the purpose of allowing users to compare the impact of the changes.

I don't understand how the user can actually test the release unless
they also produce code that is likewise shaded to invoke the
appropriate version of the package.

Surely it would be easier to test the code if it used the standard
package names, i.e. no need to change the user code?
i.e. take their app, and run it against the relevant alpha- or beta-release.
This is already possible if the user has the ability to compile the
component from source.

> Gilles
>
> >
> > > Regards,
> > > Gilles
> > >
> > > >
> > > > On Tue, 4 Jun 2019 at 17:35, Matt Sicker  wrote:
> > > > >
> > > > > This sounds like a shade feature, yes. However, in order to
> > > > > automatically extract the version extra data and detect a version
> > > > > keyword like "alpha" may require some additional code, though maybe
> > > > > the shade plugin already supports that.
> > > > >
> > > > > Alternatively, JUnit 5.x uses a tool called API Guardian for marking
> > > > > which APIs are stable or not:
> > > > > https://github.com/apiguardian-team/apiguardian
> > > > >
> > > > > On Tue, 4 Jun 2019 at 05:53, Gilles Sadowski  
> > > > > wrote:
> > > > > >
> > > > > > Hello.
> > > > > >
> > > > > > Does someone see a practical way to automate package names
> > > > > > and source files conversions so that each all alpha/beta releases
> > > > > > can be used together (e.g. to compare their behaviours).
> > > > > >
> > > > > > I mean, for release version "1.0-alpha1", the top-level package
> > > > > > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> > > > > >
> > > > > > This would also solve issues with compatibility checkers (with the
> > > > > > added bonus that JAR hell could never happen).
> > > > > >
> > > > > > Couldn't the "shade" plugin be put to use (so that all artefacts 
> > > > > > have
> > > > > > their top-level package transparently set to "o.a.c.compid.alpha1"
> > > > > > and all the tools operate on that)?
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Gilles
> > > > > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [All] Alpha/beta releases

[sebb]

On Wed, 5 Jun 2019 at 17:16, Gilles Sadowski  wrote:
>
> Le mer. 5 juin 2019 à 17:57, James Carman  a 
> écrit :
> >
> > I’m having a hard time understanding the comparing APIs use case.  If I
> > were to want to try that, I’d create a branch and import the new dependency
> > version and see what breaks.  The performance part I wouldn’t think I’d use
> > one code base either.  I’m not suggesting my way is the only or best way,
> > just explaining why I’m having a hard time understanding what you’re
> > doing.  Maybe this will be a learning opportunity for me! :)
>
> Case mainly in point is getting to the first release of new components.
> This is happening now for [Imaging], and will be soon (hopefully) for
> [Numbers], [Statistics] and [Geometry].
>
> IIUC, the former is going to release a beta version without modifying
> the top-level package name.  This will create the possibility of JAR
> hell (when 1.0 will be out).
>
> Since we don't have that much review/feedback on these new and/or
> refactored codes, I thought we could be on a safer ground if we first
> release beta version(s) that
>  * won't be subject to JAR hell and
>  * will be easy (i.e. just add the dependency in the POM file) to
>integrate for people kind enough to give it a try.
>[If it's not easy[1], they won't do it.]
>
> Regards,
> Gilles
>
> [1] Like: You "just" have to install "git", check out the source, install
> "maven", run the "package" goal, then move the "target/whatever.jar"
> file to where your code will look for it.

No need to install Git; can just download the source archive and unpack it.
I think we can assume they already have Maven, otherwise why are we
worried about releasing to Maven?

Note that the suggestion of using different package names will force
users to edit their code.
They will then have to compile their source, probably using Maven.

Seems to me the suggestion creates more work for end users.

> >
> > On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski 
> > wrote:
> >
> > > Le mer. 5 juin 2019 à 17:04, James Carman  a
> > > écrit :
> > > >
> > > > What sort of comparison are you looking to do within the same code?
> > > > Performance?
> > >
> > > Yes, that's one possibility; another is comparing different APIs.
> > >
> > > Gilles
> > >
> > >  [...]
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [All] Alpha/beta releases

[sebb]

On Wed, 5 Jun 2019 at 23:40, Gary Gregory  wrote:
>
> Hi All:
>
> I see two lines of usage IRL from people:
>
> - I use whatever is "released" on Maven Central. I quote the word released
> since that includes ANY artifacts, pre 1.0 like a 0.87 or -alpha, and
> -betas.

N.B. This by definition excludes SNAPSHOTs

> - I am not allowed to use alpha, beta, or SNAPSHOT versions.
>
> The reality ends up being that you see some stacks that have a mix of both
> of the above.
>
> We all know that Jar hell is created when breaking BC within the same
> package name (and Maven coordinates.)

Or changing Maven coordinates but not changing the package name.

> We have clear rules of engagement of major, minor and maintenance releases.
>
> The question for me is how should we treat other kinds of releases: alphas
> and betas. This is assuming that we want to keep on releasing alphas and
> betas.
>
> Jar hell is, well, hellish. I like to avoid it.

+1

> Since the very nature of alphas and betas is that changing APIs should be
> allowed, even encouraged in order to get the API in the right shape before
> a x.y.z release, I am warming to using alpha and beta in package names...

I thought API changes were restricted to alpha releases and beta for
behaviour changes?
But this is a minor detail.

> If you are to be so bold as to use such a thing, then reflecting that in
> the import states what you are doing clearly, and avoid any jar hell.

Agreed, it's clearly the user choice here since they have to change
their code (and POM) to use the new package.

Note: this would also require use of new Maven coordinates.

> That said, it should be left to each component to decide whether or not to
> opt in such naming.

+1

I think it would be worth documenting step by step how the proposal
works overall, to make sure that nothing has been overlooked.
One can then look at whether any additional tooling is needed, or if
it already exists.
> Gary
>
>
> On Wed, Jun 5, 2019 at 6:25 PM Gilles Sadowski  wrote:
>
> > Le mer. 5 juin 2019 à 23:14, sebb  a écrit :
> > >
> > > On Wed, 5 Jun 2019 at 17:16, Gilles Sadowski 
> > wrote:
> > > >
> > > > Le mer. 5 juin 2019 à 17:57, James Carman 
> > a écrit :
> > > > >
> > > > > I’m having a hard time understanding the comparing APIs use case.
> > If I
> > > > > were to want to try that, I’d create a branch and import the new
> > dependency
> > > > > version and see what breaks.  The performance part I wouldn’t think
> > I’d use
> > > > > one code base either.  I’m not suggesting my way is the only or best
> > way,
> > > > > just explaining why I’m having a hard time understanding what you’re
> > > > > doing.  Maybe this will be a learning opportunity for me! :)
> > > >
> > > > Case mainly in point is getting to the first release of new components.
> > > > This is happening now for [Imaging], and will be soon (hopefully) for
> > > > [Numbers], [Statistics] and [Geometry].
> > > >
> > > > IIUC, the former is going to release a beta version without modifying
> > > > the top-level package name.  This will create the possibility of JAR
> > > > hell (when 1.0 will be out).
> > > >
> > > > Since we don't have that much review/feedback on these new and/or
> > > > refactored codes, I thought we could be on a safer ground if we first
> > > > release beta version(s) that
> > > >  * won't be subject to JAR hell and
> > > >  * will be easy (i.e. just add the dependency in the POM file) to
> > > >integrate for people kind enough to give it a try.
> > > >[If it's not easy[1], they won't do it.]
> > > >
> > > > Regards,
> > > > Gilles
> > > >
> > > > [1] Like: You "just" have to install "git", check out the source,
> > install
> > > > "maven", run the "package" goal, then move the "target/whatever.jar"
> > > > file to where your code will look for it.
> > >
> > > No need to install Git; can just download the source archive and unpack
> > it.
> > > I think we can assume they already have Maven, otherwise why are we
> > > worried about releasing to Maven?
> > >
> > > Note that the suggestion of using different package names will force
> > > users to edit their code.
> >
> > So what; this is the purpose of beta-testing features that don't
> > exist in previous releases or

Re: [All] Alpha/beta releases

[sebb]

On Sun, 9 Jun 2019 at 12:01, James Carman  wrote:
>
> On Sun, Jun 9, 2019 at 5:40 AM Gilles Sadowski  wrote:
>
> >
> > Ultimately the PMC still needs to vote on the release, no?
> > Hence I don't see what advantage there is in allowing different
> > beta policies.  [Of course, no component is required to provide
> > a beta release...]
> > What the proposal aims to avoid is JAR hell because of beta
> > releases that did not change the maven coordinates.
> >
>
> JAR hell will not happen (if using maven) when you do not change the
> maven coordinates.  Maven will resolve to only one version of the
> given maven coordinates.

Huh?
That can still cause jar issues, *precisely because* only one jar will
reach the Java classpath.

Suppose there is jar1 with API-V1.
This is depended on by app1 and app2.

Then jar2 is produced with API-V2 (not BC-compatible with API-V1)
Update app2 to use jar2.

Assuming jar2 is a later version than jar1, the classpath will no
longer contain jar1.
However jar1 contains objects needed by app1.

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

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

Re: [All] Alpha/beta releases

[sebb]

On Sun, 9 Jun 2019 at 14:20, Gilles Sadowski  wrote:
>
> Hi.
>
> Le dim. 9 juin 2019 à 14:06, James Carman  a 
> écrit :
> >
> > On Sun, Jun 9, 2019 at 7:36 AM sebb  wrote:
> >
> > >
> > > Huh?
> > > That can still cause jar issues, *precisely because* only one jar will
> > > reach the Java classpath.
> > >
> > > Suppose there is jar1 with API-V1.
> > > This is depended on by app1 and app2.
> > >
> > > Then jar2 is produced with API-V2 (not BC-compatible with API-V1)
> > > Update app2 to use jar2.
> > >
> > > Assuming jar2 is a later version than jar1, the classpath will no
> > > longer contain jar1.
> > > However jar1 contains objects needed by app1.
> > >
> >
> > My "jar hell" I usually think of is when two different jars are on the
> > classpath at the same time and they expose the same class name.
> > You're talking about the transitive dependency "jar hell" which
> > definitely can happen.  Sorry for my confusion.
> >
> > So, in order to get two different jars on the classpath at the same
> > time (which I thought was what the original request was about in order
> > to compare APIs), you'd need to change the maven coordinates to allow
> > them to co-exist.  When you do that, you'll need to change the package
> > names in order to avoid collisions.
> >
> > If folks are publishing jars for others to consume with alpha/beta
> > dependencies (which may very well change), I'd think that's really not
> > a good idea and we should document our alpha/beta releases as such
> > (although that's a pretty standard understanding).
>
> Sure, it's not good to depend on "beta"; but it's still better than
> no code at all.  With such releases, developers can start to
> migrate away from obsolete CM codes, knowing that if all is
> well, adapting to the final release will only be matter of a trivial
> update of the "import" statements.

Or just recommend that developers download the current CM branch/tag
and compile+test against that.

This means no need to change the import statements.
Which BTW might have to be done multiple times if there are several
alphas/betas.

And if errors are found in the user code, they may have to update
multiple versions.

This all seems a lot of work.

I question whether releasing source-incompatible code is likely to
encourage more alpha/beta testers compared with requiring users to
compile the code from source.

> >  The other option
> > is to just keep with SNAPSHOTs and tell folks to point to our snapshot
> > repository.
>
> This is a step worse than "beta", as the artefacts can change
> without notice.

That is always the case with SNAPSHOTs.

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

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

Re: [ALL] Issues with Git repos: bad HEADs and unexpected refs - need Git guru

[sebb]

Ping - any comment on the unexpected HEAD references?
Should they be changed?

On Mon, 3 Jun 2019 at 15:15, Gary Gregory  wrote:
>
> Did we git guru ourselves out of all of these?
>
> Gary
>
> On Wed, May 29, 2019 at 9:39 AM sebb  wrote:
>
> > I noticed that JCS still has a trunk branch and that appears to be the
> > default, so I did a check of all the commons git repos.
> >
> > The command used is:
> >
> > git ls-remote #{repo} HEAD master trunk
> > where repo = https://gitbox.apache.org/repos/asf/{commons-???}.git
> >
> > I then compared the hashes for HEAD and refs/heads/master.
> > If different, then the HEAD is not master.
> >
> > Some of the repos have references other than HEAD, refs/heads/master
> > or refs/remotes/trunk (which I assume are OK?)
> >
> > The discrepancies are listed below.
> >
> > The most important ones are obviously the ones with bad heads - I
> > guess we should ask Infra to reset those. But what if changes have
> > been made to trunk?
> >
> > I don't know what to do about the additional references, if anything.
> >
> > Unexpected HEADs:
> >
> > https://gitbox.apache.org/repos/asf/commons-configuration.git
> > 61732d3c65cbfae58d71e2dd55caf8760a9aa642 HEAD **not master**
> > 61732d3c65cbfae58d71e2dd55caf8760a9aa642 refs/heads/trunk REF?
> > 61732d3c65cbfae58d71e2dd55caf8760a9aa642 refs/remotes/trunk
> > 96720ced6f263462aaae7217392399267b1d141f refs/heads/master
> >
> > https://gitbox.apache.org/repos/asf/commons-jcs.git
> > ad897014842fc830483f32fdfb903f3bb8f70289 HEAD **not master**
> > ad897014842fc830483f32fdfb903f3bb8f70289 refs/heads/trunk REF?
> > ad897014842fc830483f32fdfb903f3bb8f70289 refs/remotes/trunk
> > b59d43e64e3759dac71b4b68bf43f3ac32d484c3 refs/heads/master
> >
> >
> > Unexpected REFS (HEAD looks OK):
> >
> > https://gitbox.apache.org/repos/asf/commons-weaver.git
> > 141e820c70fa3a86d49b740076b11ba50dc8b456 refs/remotes/origin/master REF?
> > 9329b1486e28b4d7112dc30ba381892dccb924db refs/remotes/trunk
> > a88dbbbd76aed4ac98d94ceb2e1bc9bd2183aa84 HEAD
> > a88dbbbd76aed4ac98d94ceb2e1bc9bd2183aa84 refs/heads/master
> >
> > https://gitbox.apache.org/repos/asf/commons-logging.git
> > 0548efba5be8c7dd04f71d81e642488fec6f5472 HEAD
> > 0548efba5be8c7dd04f71d81e642488fec6f5472 refs/heads/master
> > 0548efba5be8c7dd04f71d81e642488fec6f5472 refs/heads/trunk REF?
> > 0548efba5be8c7dd04f71d81e642488fec6f5472 refs/remotes/trunk
> > e7f1bbad19cbd1f4ed3085b83d2866c9bc247815 refs/original/refs/remotes/trunk
> > REF?
> >
> > https://gitbox.apache.org/repos/asf/commons-codec.git
> > 163d643d1176e0dc9334ee83e21b9ce21d24fc1a refs/remotes/trunk
> > 3ee99ea6cabeee96d5dfbb45e43b1e8cf74a9929 refs/original/refs/heads/trunk
> > REF?
> > 3ee99ea6cabeee96d5dfbb45e43b1e8cf74a9929 refs/original/refs/remotes/trunk
> > REF?
> > 48b615756d1d770091ea3322eefc08011ee8b113 HEAD
> > 48b615756d1d770091ea3322eefc08011ee8b113 refs/heads/master
> >
> > https://gitbox.apache.org/repos/asf/commons-proxy.git
> > 838024d7d8193d181506568fec9e681b6e11e59a HEAD
> > 838024d7d8193d181506568fec9e681b6e11e59a refs/heads/master
> > 838024d7d8193d181506568fec9e681b6e11e59a refs/heads/trunk REF?
> > 838024d7d8193d181506568fec9e681b6e11e59a refs/remotes/trunk
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

Re: [lang] ArrayUtils.addFirst(T[], T)?

[sebb]

On Wed, 12 Jun 2019 at 22:11, Mark Dacek  wrote:
>
> I’d support adding both.

+1

How about overloading as follows:

ArrayUtils.add(T[], T, index)

It seems inconsistent to have add() and addFirst(); that suggests
there should be an addLast()

> On Wed, Jun 12, 2019 at 5:09 PM James Carman 
> wrote:
>
> > I like it.  Seems like a logical thing to do.  Another idea would be adding
> > at an arbitrary index.
> >
> > On Wed, Jun 12, 2019 at 5:04 PM Gary Gregory 
> > wrote:
> >
> > > Hi All:
> > >
> > > We have org.apache.commons.lang3.ArrayUtils.add(T[], T).
> > >
> > > WDYT about adding a method that adds the element at the beginning of the
> > > new array instead of the end?
> > >
> > > Gary
> > >
> >

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

Re: [lang] ArrayUtils.addFirst(T[], T)?

[sebb]

On Thu, 13 Jun 2019 at 13:43, Gary Gregory  wrote:
>
> On Thu, Jun 13, 2019 at 8:32 AM sebb  wrote:
>
> > On Wed, 12 Jun 2019 at 22:11, Mark Dacek  wrote:
> > >
> > > I’d support adding both.
> >
> > +1
> >
> > How about overloading as follows:
> >
> > ArrayUtils.add(T[], T, index)
> >
>
> Ah, I see we already deprecated an "add at index" method in favor of
> "insert at index":
>
> ...
>  * @deprecated this method has been superseded by {@link #insert(int,
> Object[], Object...) insert(int, T[], T...)} and
>  * may be removed in a future release. Please note the handling of
> {@code null} input arrays differs
>  * in the new method: inserting {@code X} into a {@code null} array
> results in {@code null} not {@code X}.
>  */
> @Deprecated
> public static  T[] add(final T[] array, final int index, final T
> element) {
> ...
>
> So the question becomes what should, ideally, be "add/insert first" and
> "add/insert last" methods be called. We can then deprecate old APIs if
> needed.

Indeed.

How about prepend/append ?

I think the pair has an obvious and unambiguous meaning.

Other languages use unshift/push, but unshift is not obvious, and
there is already a shift (which is actually a partial rotate AFAICT).

Also addFirst could just possibly be misread as 'add after first';
similarly addLast could be misread as 'add before last'.


> Gary
>
> >
> > It seems inconsistent to have add() and addFirst(); that suggests
> > there should be an addLast()
> >
> > > On Wed, Jun 12, 2019 at 5:09 PM James Carman  > >
> > > wrote:
> > >
> > > > I like it.  Seems like a logical thing to do.  Another idea would be
> > adding
> > > > at an arbitrary index.
> > > >
> > > > On Wed, Jun 12, 2019 at 5:04 PM Gary Gregory 
> > > > wrote:
> > > >
> > > > > Hi All:
> > > > >
> > > > > We have org.apache.commons.lang3.ArrayUtils.add(T[], T).
> > > > >
> > > > > WDYT about adding a method that adds the element at the beginning of
> > the
> > > > > new array instead of the end?
> > > > >
> > > > > Gary
> > > > >
> > > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

Re: [lang] ArrayUtils.addFirst(T[], T)?

[sebb]

On Thu, 13 Jun 2019 at 14:15, Gary Gregory  wrote:
>
> I like addFirst() and addLast() because these are the same kind of names as
> the existing java.util.List.add(int, E) which should be familiar to people.
>
> I feel that interpreting addFirst() as "add after first" breaks the
> principle of least surprise.

Huh? I think that is backwards.

I only said addFirst() *might perhaps* be interpreted that way, i.e.
it is potentially ambiguous.
Note that the existing add() method effectively means add AFTER, and
that is the general sense in which the word 'add' is used.

The 'principle of least surprise' cannot stop people from making a
incorrect interpretation.
However if there is a risk, then surely the principle means not
choosing the name?

I suggested prepend/append because I think they are unambiguous.

I won't object to addFirst/addLast but I'm not convinced it is the best choice.

The add() method should probably be deprecated whatever happens.

> Gary
>
> On Thu, Jun 13, 2019 at 9:03 AM Mark Dacek  wrote:
>
> > addFirst is commonly used with LinkedLists. I wouldn't think it to be
> > unintuitive.
> >
> > On Thu, Jun 13, 2019 at 8:56 AM sebb  wrote:
> >
> > > On Thu, 13 Jun 2019 at 13:43, Gary Gregory 
> > wrote:
> > > >
> > > > On Thu, Jun 13, 2019 at 8:32 AM sebb  wrote:
> > > >
> > > > > On Wed, 12 Jun 2019 at 22:11, Mark Dacek  wrote:
> > > > > >
> > > > > > I’d support adding both.
> > > > >
> > > > > +1
> > > > >
> > > > > How about overloading as follows:
> > > > >
> > > > > ArrayUtils.add(T[], T, index)
> > > > >
> > > >
> > > > Ah, I see we already deprecated an "add at index" method in favor of
> > > > "insert at index":
> > > >
> > > > ...
> > > >  * @deprecated this method has been superseded by {@link
> > #insert(int,
> > > > Object[], Object...) insert(int, T[], T...)} and
> > > >  * may be removed in a future release. Please note the handling of
> > > > {@code null} input arrays differs
> > > >  * in the new method: inserting {@code X} into a {@code null} array
> > > > results in {@code null} not {@code X}.
> > > >  */
> > > > @Deprecated
> > > > public static  T[] add(final T[] array, final int index, final T
> > > > element) {
> > > > ...
> > > >
> > > > So the question becomes what should, ideally, be "add/insert first" and
> > > > "add/insert last" methods be called. We can then deprecate old APIs if
> > > > needed.
> > >
> > > Indeed.
> > >
> > > How about prepend/append ?
> > >
> > > I think the pair has an obvious and unambiguous meaning.
> > >
> > > Other languages use unshift/push, but unshift is not obvious, and
> > > there is already a shift (which is actually a partial rotate AFAICT).
> > >
> > > Also addFirst could just possibly be misread as 'add after first';
> > > similarly addLast could be misread as 'add before last'.
> > >
> > >
> > > > Gary
> > > >
> > > > >
> > > > > It seems inconsistent to have add() and addFirst(); that suggests
> > > > > there should be an addLast()
> > > > >
> > > > > > On Wed, Jun 12, 2019 at 5:09 PM James Carman <
> > > ja...@carmanconsulting.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I like it.  Seems like a logical thing to do.  Another idea would
> > > be
> > > > > adding
> > > > > > > at an arbitrary index.
> > > > > > >
> > > > > > > On Wed, Jun 12, 2019 at 5:04 PM Gary Gregory <
> > > garydgreg...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi All:
> > > > > > > >
> > > > > > > > We have org.apache.commons.lang3.ArrayUtils.add(T[], T).
> > > > > > > >
> > > > > > > > WDYT about adding a method that adds the element at the
> > > beginning of
> > > > > the
> > > > > > > > new array instead of the end?
> > > > > > > >
> > > > > > > > Gary
> > > > > > > >
> > > > > > >
> > > > >
> > > > > -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > >
> > > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >

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

Re: [lang][rng] org.apache.commons.lang3.ArrayUtils.shuffle()

[sebb]

On Thu, 13 Jun 2019 at 16:35, Alex Herbert  wrote:
>
>
> On 13/06/2019 15:59, Gary Gregory wrote:
> > Now that RNG is up and going, it seems odd to still have:
> >
> > org.apache.commons.lang3.ArrayUtils.shuffle(double[], Random)
> >
> > Should we deprecate these APIs in favor of Commons RNG and if so which RNG
> > APIs?
> >
> > Gary
> Shuffling is in the commons-rng-sampling component.
>
> Shuffling for int[] primitive arrays is in the PermutationSampler [1].
>
> Shuffling for a List is in the ListSampler [2].
>
> Currently there are methods to shuffle the entire length, or part of the
> length starting from a position and shuffling to the start or end of the
> array / list.
>
> There is no method for:
>
> - Shuffling a subsequence within the array / list defined by either
> start and length or start and end.
>
> - Shuffling an array T[]
>
> - Shuffling primitive arrays other than int[] (This requires a bit of
> work [3])
>
>
> [Lang] ArrayUtils only shuffles the full array but supports all
> primitive array types and Object[]. It does not support a shuffle of T[].
>
> So there is only partial overlap between the libraries. There is not a
> like for like swap to deprecate ArrayUtils methods in favour of Commons
> RNG methods.
>
>
> I think it is quite a common use case to want to shuffle full length
> arrays. I'm not sure about sub-sequence shuffles but one is a super-set
> of the other.
>
> To deprecate ArrayUtils shuffle methods would require a new class in RNG
> to support this for all primitives and a generic type T following this
> prototype:
>
> ArrayUtils.shuffle(UniformRandomProvider rng, double[] data)
> ArrayUtils.shuffle(UniformRandomProvider rng, double[] data, int start,
> int length)
>
>
> I'm not opposed to adding the methods to Commons RNG. Either in the
> current sampling module or perhaps a new commons-rng-utils module
> instead since a shuffle is not really a sample unless you use a
> subsequence from the shuffled array.

Rather than shuffle etc in place, how about various
iterators/selectors to return entries in randomised order?
[Or does that already exist?]

>
> Alex
>
>
> [1]
> http://commons.apache.org/proper/commons-rng/commons-rng-sampling/javadocs/api-1.2/org/apache/commons/rng/sampling/PermutationSampler.html
>
>
> [2]
> http://commons.apache.org/proper/commons-rng/commons-rng-sampling/javadocs/api-1.2/org/apache/commons/rng/sampling/ListSampler.html
>
> [3] Supporting all the primitive avoids the currently usage to shuffle a
> non-integer array which requires:
>
> - Clone the input array
> - Shuffle a newly allocated int[] of ascending indices
> - Use the shuffled indices to copy data from the clone back to the input
> array
>
> This has unnecessary allocation overhead.
>
>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [lang][rng] org.apache.commons.lang3.ArrayUtils.shuffle()

[sebb]

I meant that the iterator would use the shuffled and/or selected
indices to return the appropriate entry from the original array.

No need to modify the original array.


On Thu, 13 Jun 2019 at 18:15, Eric Barnhill  wrote:
>
> An iterator that dynamically shuffles as you go along. That's really nice,
> I had never even thought of that. Thanks.
>
> On Thu, Jun 13, 2019 at 10:11 AM Alex Herbert 
> wrote:
>
> >
> > On 13/06/2019 17:56, Eric Barnhill wrote:
> > > On Thu, Jun 13, 2019 at 9:36 AM sebb  wrote:
> > >
> > >>
> > >> Rather than shuffle etc in place, how about various
> > >> iterators/selectors to return entries in randomised order?
> > >> [Or does that already exist?]
> > >>
> > > I am pretty sure random draws, and shuffling, are implemented with
> > > different algorithms. Though sampling without replacement the full length
> > > of the set would yield a shuffled set, I think there are more efficient
> > > ways to shuffle a set.
> >
> > Iterators to return a random draw *without* replacement over the full
> > length of the array? The iterator would dynamically shuffle the array on
> > each call to next() so could be stopped early or can be called
> > infinitely as if a continuous stream. Is that your idea?
> >
> > UniformRandomProvider rng = ...;
> > int[] big = new int[100];
> > //
> > // Fill big with lots of data
> > //
> > IntIterator iter = ShuffleIterators.create(rng, big);
> > int x = iter.next();
> > int y = iter.next();
> > int z = iter.next();
> >
> > This doesn't exist but it is easy to do. Memory requirements would
> > require a copy of the data, or it could be marked as destructive to the
> > input array order and shuffle in place.
> >
> > If you want a random draw *with* replacement then you can just call
> > nextInt(int) with the size of the array to pick something.
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

Re: [lang][rng] org.apache.commons.lang3.ArrayUtils.shuffle()

[sebb]

On Fri, 14 Jun 2019 at 12:57, Alex Herbert  wrote:
>
>
> On 14/06/2019 12:01, sebb wrote:
> > I meant that the iterator would use the shuffled and/or selected
> > indices to return the appropriate entry from the original array.
> >
> > No need to modify the original array.
>
> To shuffle an array requires storage as elements are swapped. Either
> store an index or store the data. So for primitive types with 4-bytes or
> less storage it is more efficient (memory wise) to copy the array and
> shuffle in place. For those with size of 8-bytes then you can create an
> int array of indices and shuffle that. The index can be used to take the
> sample from the original array.
>
> In terms of the RNG library the functionality to shuffle an entire array
> once (as per ArrayUtils) would be the same as the functions from [lang]
> ArrayUtils. So a decision should be made on whether to copy that
> functionality from [lang] and mark it as deprecated there.
>
> The idea of unlimited shuffling would be done as a sampler so this would
> go into the rng-sampling module. A single shuffle creates a permutation
> of the sequence. The sample would do this dynamically and repeatedly
> pass over the array.
>
> The sort of code would be:
>
> double[] array = { 1.1, 2.2, 3.3 };
> UniformRandomProvider rng = ...;
> DoubleContinuousPermutationSampler sampler = new
> DoubleContinuousPermutationSampler(rng, array);
> for (int i = 0; i < 100; i++) {
>  double sample = sampler.next();
> }
>
> The output would be the n values of the array in a random order without
> replacement. Once the entire set n is produced then the output would
> repeat in a new random order, and so on:
>
> 2.2, 1.1, 3.3, 3.3, 2.2, 1.1, 2.2, 3.3, 1.1, ...
>
> Currently the library does not specialise for primitives so a more
> generic sampler would only output a stream of int indices:
>
> double[] array = { 1.1, 2.2, 3.3 };
> UniformRandomProvider rng = ...;
> ContinuousPermutationSampler sampler = new
> ContinuousPermutationSampler(rng, array.length);
> for (int i = 0; i < 100; i++) {
>  double sample = array[sampler.next()];
> }
>
> If you are only interested in a complete single pass then creating a
> shuffled int[] of indices can be done using the existing
> PermutationSampler. This returns an int[] permutation from its sample
> method. The array can be used in place of an iterator:
>
> double[] array = { 1.1, 2.2, 3.3 };
> UniformRandomProvider rng = ...;
> for (int index : new PermutationSampler(rng, array.length,
> array.length).sample()) {
>  double sample = array[index];
> }

My proposal was basically to implement the above in wrapper methods
using an interface such as List or Iterator.

> I'm not opposed to the continuous permutation sampler idea. I just can't
> think of a use case not already satisfied by the existing
> PermutationSampler, i.e. when you want to sample permutations using each
> index one at a time and not in chunks of indices. This type of idea:
>
> double[] array = { 1.1, 2.2, 3.3 };
> UniformRandomProvider rng;
> // The PermutationSampler will validate the length is >0
> final PermutationSampler sampler = new PermutationSampler(rng,
> array.length, array.length);
> IntSupplier supplier = new IntSupplier() {
>  int i;
>  int[] sample;
>  @Override
>  public int getAsInt() {
>  if (i == 0) {
>  sample = sampler.sample();
>  i = sample.length;
>  }
>  return sample[--i];
>  }
> };
> for (;;) {
>  double sample = array[supplier.getAsInt()];
> }
>
>
> >
> > On Thu, 13 Jun 2019 at 18:15, Eric Barnhill  wrote:
> >> An iterator that dynamically shuffles as you go along. That's really nice,
> >> I had never even thought of that. Thanks.
> >>
> >> On Thu, Jun 13, 2019 at 10:11 AM Alex Herbert 
> >> wrote:
> >>
> >>> On 13/06/2019 17:56, Eric Barnhill wrote:
> >>>> On Thu, Jun 13, 2019 at 9:36 AM sebb  wrote:
> >>>>
> >>>>> Rather than shuffle etc in place, how about various
> >>>>> iterators/selectors to return entries in randomised order?
> >>>>> [Or does that already exist?]
> >>>>>
> >>>> I am pretty sure random draws, and shuffling, are implemented with
> >>>> different algorithms. Though sampling without replacement the full length
> >>>> of the set would yield a shuffled set, I think there are more efficient
> >>>> ways to shuffle a set.
> >>> Iterators to return a random draw *without* replacement ov

Re: [CSV] Broken build

[sebb]

On Sat, 15 Jun 2019 at 15:14, Gary Gregory  wrote:
>
> The current master build yields:
>
> [ERROR]   CSVFormatTest.testHashCodeAndWithIgnoreHeaderCase:523
> [ERROR]   CSVFormatTest.testWithHeaderComments:972
>
> I do not think it is OK to push fixes that break the build.

Already fixed.

> Gary

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

Re: [ALL] Issues with Git repos: bad HEADs and unexpected refs - need Git guru

[sebb]

https://issues.apache.org/jira/browse/INFRA-18616 raised to fix the
default branch.

Deletion of trunk can be done later

On Tue, 11 Jun 2019 at 20:09, Gary Gregory  wrote:
>
> The trunk branches should go away IMO.
>
> Is there any reason not to fix these?
>
> Gary
>
> On Sun, Jun 9, 2019, 09:54 sebb  wrote:
>
> > Ping - any comment on the unexpected HEAD references?
> > Should they be changed?
> >
> > On Mon, 3 Jun 2019 at 15:15, Gary Gregory  wrote:
> > >
> > > Did we git guru ourselves out of all of these?
> > >
> > > Gary
> > >
> > > On Wed, May 29, 2019 at 9:39 AM sebb  wrote:
> > >
> > > > I noticed that JCS still has a trunk branch and that appears to be the
> > > > default, so I did a check of all the commons git repos.
> > > >
> > > > The command used is:
> > > >
> > > > git ls-remote #{repo} HEAD master trunk
> > > > where repo = https://gitbox.apache.org/repos/asf/{commons-???}.git
> > > >
> > > > I then compared the hashes for HEAD and refs/heads/master.
> > > > If different, then the HEAD is not master.
> > > >
> > > > Some of the repos have references other than HEAD, refs/heads/master
> > > > or refs/remotes/trunk (which I assume are OK?)
> > > >
> > > > The discrepancies are listed below.
> > > >
> > > > The most important ones are obviously the ones with bad heads - I
> > > > guess we should ask Infra to reset those. But what if changes have
> > > > been made to trunk?
> > > >
> > > > I don't know what to do about the additional references, if anything.
> > > >
> > > > Unexpected HEADs:
> > > >
> > > > https://gitbox.apache.org/repos/asf/commons-configuration.git
> > > > 61732d3c65cbfae58d71e2dd55caf8760a9aa642 HEAD **not master**
> > > > 61732d3c65cbfae58d71e2dd55caf8760a9aa642 refs/heads/trunk REF?
> > > > 61732d3c65cbfae58d71e2dd55caf8760a9aa642 refs/remotes/trunk
> > > > 96720ced6f263462aaae7217392399267b1d141f refs/heads/master
> > > >
> > > > https://gitbox.apache.org/repos/asf/commons-jcs.git
> > > > ad897014842fc830483f32fdfb903f3bb8f70289 HEAD **not master**
> > > > ad897014842fc830483f32fdfb903f3bb8f70289 refs/heads/trunk REF?
> > > > ad897014842fc830483f32fdfb903f3bb8f70289 refs/remotes/trunk
> > > > b59d43e64e3759dac71b4b68bf43f3ac32d484c3 refs/heads/master
> > > >
> > > >
> > > > Unexpected REFS (HEAD looks OK):
> > > >
> > > > https://gitbox.apache.org/repos/asf/commons-weaver.git
> > > > 141e820c70fa3a86d49b740076b11ba50dc8b456 refs/remotes/origin/master
> > REF?
> > > > 9329b1486e28b4d7112dc30ba381892dccb924db refs/remotes/trunk
> > > > a88dbbbd76aed4ac98d94ceb2e1bc9bd2183aa84 HEAD
> > > > a88dbbbd76aed4ac98d94ceb2e1bc9bd2183aa84 refs/heads/master
> > > >
> > > > https://gitbox.apache.org/repos/asf/commons-logging.git
> > > > 0548efba5be8c7dd04f71d81e642488fec6f5472 HEAD
> > > > 0548efba5be8c7dd04f71d81e642488fec6f5472 refs/heads/master
> > > > 0548efba5be8c7dd04f71d81e642488fec6f5472 refs/heads/trunk REF?
> > > > 0548efba5be8c7dd04f71d81e642488fec6f5472 refs/remotes/trunk
> > > > e7f1bbad19cbd1f4ed3085b83d2866c9bc247815
> > refs/original/refs/remotes/trunk
> > > > REF?
> > > >
> > > > https://gitbox.apache.org/repos/asf/commons-codec.git
> > > > 163d643d1176e0dc9334ee83e21b9ce21d24fc1a refs/remotes/trunk
> > > > 3ee99ea6cabeee96d5dfbb45e43b1e8cf74a9929 refs/original/refs/heads/trunk
> > > > REF?
> > > > 3ee99ea6cabeee96d5dfbb45e43b1e8cf74a9929
> > refs/original/refs/remotes/trunk
> > > > REF?
> > > > 48b615756d1d770091ea3322eefc08011ee8b113 HEAD
> > > > 48b615756d1d770091ea3322eefc08011ee8b113 refs/heads/master
> > > >
> > > > https://gitbox.apache.org/repos/asf/commons-proxy.git
> > > > 838024d7d8193d181506568fec9e681b6e11e59a HEAD
> > > > 838024d7d8193d181506568fec9e681b6e11e59a refs/heads/master
> > > > 838024d7d8193d181506568fec9e681b6e11e59a refs/heads/trunk REF?
> > > > 838024d7d8193d181506568fec9e681b6e11e59a refs/remotes/trunk
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

Re: [ALL] Issues with Git repos: bad HEADs and unexpected refs - need Git guru

[sebb]

On Sat, 15 Jun 2019 at 17:36, Rob Tompkins  wrote:
>
>
>
> > On Jun 15, 2019, at 11:26 AM, sebb  wrote:
> >
> > https://issues.apache.org/jira/browse/INFRA-18616 raised to fix the
> > default branch.
> >
> > Deletion of trunk can be done later
>
> Unless trunk is protected for some reason, “git push  :trunk” will 
> delete the trunk branch, when we’re ready.

INFRA-18616 has been completed, and the default branches have been updated.
Infra found that proxy and logging were also incorrect.
(My checks looked for HEAD != master, but I did not consider that HEAD
== master == trunk could mean that the default was trunk)

I was also able to delete trunks using GitHub.

> >
> > On Tue, 11 Jun 2019 at 20:09, Gary Gregory  wrote:
> >>
> >> The trunk branches should go away IMO.
> >>
> >> Is there any reason not to fix these?
> >>
> >> Gary
> >>
> >> On Sun, Jun 9, 2019, 09:54 sebb  wrote:
> >>
> >>> Ping - any comment on the unexpected HEAD references?
> >>> Should they be changed?
> >>>
> >>> On Mon, 3 Jun 2019 at 15:15, Gary Gregory  wrote:
> >>>>
> >>>> Did we git guru ourselves out of all of these?
> >>>>
> >>>> Gary
> >>>>
> >>>> On Wed, May 29, 2019 at 9:39 AM sebb  wrote:
> >>>>
> >>>>> I noticed that JCS still has a trunk branch and that appears to be the
> >>>>> default, so I did a check of all the commons git repos.
> >>>>>
> >>>>> The command used is:
> >>>>>
> >>>>> git ls-remote #{repo} HEAD master trunk
> >>>>> where repo = https://gitbox.apache.org/repos/asf/{commons-???}.git
> >>>>>
> >>>>> I then compared the hashes for HEAD and refs/heads/master.
> >>>>> If different, then the HEAD is not master.
> >>>>>
> >>>>> Some of the repos have references other than HEAD, refs/heads/master
> >>>>> or refs/remotes/trunk (which I assume are OK?)
> >>>>>
> >>>>> The discrepancies are listed below.
> >>>>>
> >>>>> The most important ones are obviously the ones with bad heads - I
> >>>>> guess we should ask Infra to reset those. But what if changes have
> >>>>> been made to trunk?
> >>>>>
> >>>>> I don't know what to do about the additional references, if anything.
> >>>>>
> >>>>> Unexpected HEADs:
> >>>>>
> >>>>> https://gitbox.apache.org/repos/asf/commons-configuration.git
> >>>>> 61732d3c65cbfae58d71e2dd55caf8760a9aa642 HEAD **not master**
> >>>>> 61732d3c65cbfae58d71e2dd55caf8760a9aa642 refs/heads/trunk REF?
> >>>>> 61732d3c65cbfae58d71e2dd55caf8760a9aa642 refs/remotes/trunk
> >>>>> 96720ced6f263462aaae7217392399267b1d141f refs/heads/master
> >>>>>
> >>>>> https://gitbox.apache.org/repos/asf/commons-jcs.git
> >>>>> ad897014842fc830483f32fdfb903f3bb8f70289 HEAD **not master**
> >>>>> ad897014842fc830483f32fdfb903f3bb8f70289 refs/heads/trunk REF?
> >>>>> ad897014842fc830483f32fdfb903f3bb8f70289 refs/remotes/trunk
> >>>>> b59d43e64e3759dac71b4b68bf43f3ac32d484c3 refs/heads/master
> >>>>>
> >>>>>
> >>>>> Unexpected REFS (HEAD looks OK):
> >>>>>
> >>>>> https://gitbox.apache.org/repos/asf/commons-weaver.git
> >>>>> 141e820c70fa3a86d49b740076b11ba50dc8b456 refs/remotes/origin/master
> >>> REF?
> >>>>> 9329b1486e28b4d7112dc30ba381892dccb924db refs/remotes/trunk
> >>>>> a88dbbbd76aed4ac98d94ceb2e1bc9bd2183aa84 HEAD
> >>>>> a88dbbbd76aed4ac98d94ceb2e1bc9bd2183aa84 refs/heads/master
> >>>>>
> >>>>> https://gitbox.apache.org/repos/asf/commons-logging.git
> >>>>> 0548efba5be8c7dd04f71d81e642488fec6f5472 HEAD
> >>>>> 0548efba5be8c7dd04f71d81e642488fec6f5472 refs/heads/master
> >>>>> 0548efba5be8c7dd04f71d81e642488fec6f5472 refs/heads/trunk REF?
> >>>>> 0548efba5be8c7dd04f71d81e642488fec6f5472 refs/remotes/trunk
> >>>>> e7f1bbad19cbd1f4ed3085b83d2866c9bc247815
> >>> refs/original/refs/remotes/trunk
> >>>>> REF?
> >>>>>
> >>>>> https://gitbox

[CODEC] CRLF files in macOS checkout

[sebb]

Most of the files in my clone of codec have LF endings, however a few are CRLF:

./README.md
./src/assembly/bin.xml
./src/assembly/src.xml
./src/changes/changes.xml
./src/main/java/org/apache/commons/codec/cli/Digest.java
./src/main/java/org/apache/commons/codec/language/DaitchMokotoffSoundex.java
./src/main/resources/org/apache/commons/codec/language/bm/lang.txt
./src/test/java/org/apache/commons/codec/digest/HmacAlgorithmsTest.java
./src/test/java/org/apache/commons/codec/digest/MessageDigestAlgorithmsTest.java
./src/test/java/org/apache/commons/codec/digest/PureJavaCrc32Test.java
./src/test/java/org/apache/commons/codec/language/ColognePhoneticTest.java


This causes spurious differences when the files are updated.

Can these files be easily fixed without causing huge diffs to be generated?

Also, is there any way to prevent such files being committed to the repo?

S.

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

Re: [CODEC] CRLF files in macOS checkout

[sebb]

On Tue, 18 Jun 2019 at 08:15, Julian Reschke  wrote:
>
> On 17.06.2019 23:26, sebb wrote:
> > Most of the files in my clone of codec have LF endings, however a few are 
> > CRLF:
> >
> > ./README.md
> > ./src/assembly/bin.xml
> > ./src/assembly/src.xml
> > ./src/changes/changes.xml
> > ./src/main/java/org/apache/commons/codec/cli/Digest.java
> > ./src/main/java/org/apache/commons/codec/language/DaitchMokotoffSoundex.java
> > ./src/main/resources/org/apache/commons/codec/language/bm/lang.txt
> > ./src/test/java/org/apache/commons/codec/digest/HmacAlgorithmsTest.java
> > ./src/test/java/org/apache/commons/codec/digest/MessageDigestAlgorithmsTest.java
> > ./src/test/java/org/apache/commons/codec/digest/PureJavaCrc32Test.java
> > ./src/test/java/org/apache/commons/codec/language/ColognePhoneticTest.java
> >
> >
> > This causes spurious differences when the files are updated.
> >
> > Can these files be easily fixed without causing huge diffs to be generated?
> >
> > Also, is there any way to prevent such files being committed to the repo?
> >
> > S.
>
> If svn:eol-style is set to "native", it shouldn't matter. I think this
> can be defaulted for newly added files.

Thanks, but this is Git, not SVN.

> In Jackrabbit, I regularly run a script to spot new files missing the
> property.

Are you willing to share the script?

> Best regards, Julian

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

Re: [CODEC] CRLF files in macOS checkout

[sebb]

On Tue, 18 Jun 2019 at 10:40, Alex Herbert  wrote:
>
>
> On 18/06/2019 09:55, sebb wrote:
> > On Tue, 18 Jun 2019 at 08:15, Julian Reschke  wrote:
> >> On 17.06.2019 23:26, sebb wrote:
> >>> Most of the files in my clone of codec have LF endings, however a few are 
> >>> CRLF:
> >>>
> >>> ./README.md
> >>> ./src/assembly/bin.xml
> >>> ./src/assembly/src.xml
> >>> ./src/changes/changes.xml
> >>> ./src/main/java/org/apache/commons/codec/cli/Digest.java
> >>> ./src/main/java/org/apache/commons/codec/language/DaitchMokotoffSoundex.java
> >>> ./src/main/resources/org/apache/commons/codec/language/bm/lang.txt
> >>> ./src/test/java/org/apache/commons/codec/digest/HmacAlgorithmsTest.java
> >>> ./src/test/java/org/apache/commons/codec/digest/MessageDigestAlgorithmsTest.java
> >>> ./src/test/java/org/apache/commons/codec/digest/PureJavaCrc32Test.java
> >>> ./src/test/java/org/apache/commons/codec/language/ColognePhoneticTest.java
> >>>
> >>>
> >>> This causes spurious differences when the files are updated.
> >>>
> >>> Can these files be easily fixed without causing huge diffs to be 
> >>> generated?
> >>>
> >>> Also, is there any way to prevent such files being committed to the repo?
> >>>
> >>> S.
> >> If svn:eol-style is set to "native", it shouldn't matter. I think this
> >> can be defaulted for newly added files.
> > Thanks, but this is Git, not SVN.
> >
> >> In Jackrabbit, I regularly run a script to spot new files missing the
> >> property.
> > Are you willing to share the script?
>
> This was recently a problem in [statistics]. It was fixed using a
> .gitattributes file [1] containing:
>
> * text=auto
>
> You can fix all the existing files following the steps detailed on the
> git documentation:
>
> $ echo "* text=auto" >.gitattributes
>
> $ git add --renormalize .
>
> $ git status# Show files that will be normalized
>
> $ git commit -m "Introduce end-of-line normalization"

Thanks, though that did not pick up two of the files.

However it looks like the commit message will show huge diffs for each file.

Is that unavoidable?

> [1] https://git-scm.com/docs/gitattributes
>
>
> >
> >> Best regards, Julian
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >

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

Re: [CODEC] CRLF files in macOS checkout

[sebb]

On Tue, 18 Jun 2019 at 12:58, Alex Herbert  wrote:
>
>
> On 18/06/2019 11:00, sebb wrote:
> > On Tue, 18 Jun 2019 at 10:40, Alex Herbert  wrote:
> >>
> >> On 18/06/2019 09:55, sebb wrote:
> >>> On Tue, 18 Jun 2019 at 08:15, Julian Reschke  
> >>> wrote:
> >>>> On 17.06.2019 23:26, sebb wrote:
> >>>>> Most of the files in my clone of codec have LF endings, however a few 
> >>>>> are CRLF:
> >>>>>
> >>>>> ./README.md
> >>>>> ./src/assembly/bin.xml
> >>>>> ./src/assembly/src.xml
> >>>>> ./src/changes/changes.xml
> >>>>> ./src/main/java/org/apache/commons/codec/cli/Digest.java
> >>>>> ./src/main/java/org/apache/commons/codec/language/DaitchMokotoffSoundex.java
> >>>>> ./src/main/resources/org/apache/commons/codec/language/bm/lang.txt
> >>>>> ./src/test/java/org/apache/commons/codec/digest/HmacAlgorithmsTest.java
> >>>>> ./src/test/java/org/apache/commons/codec/digest/MessageDigestAlgorithmsTest.java
> >>>>> ./src/test/java/org/apache/commons/codec/digest/PureJavaCrc32Test.java
> >>>>> ./src/test/java/org/apache/commons/codec/language/ColognePhoneticTest.java
> >>>>>
> >>>>>
> >>>>> This causes spurious differences when the files are updated.
> >>>>>
> >>>>> Can these files be easily fixed without causing huge diffs to be 
> >>>>> generated?
> >>>>>
> >>>>> Also, is there any way to prevent such files being committed to the 
> >>>>> repo?
> >>>>>
> >>>>> S.
> >>>> If svn:eol-style is set to "native", it shouldn't matter. I think this
> >>>> can be defaulted for newly added files.
> >>> Thanks, but this is Git, not SVN.
> >>>
> >>>> In Jackrabbit, I regularly run a script to spot new files missing the
> >>>> property.
> >>> Are you willing to share the script?
> >> This was recently a problem in [statistics]. It was fixed using a
> >> .gitattributes file [1] containing:
> >>
> >> * text=auto
> >>
> >> You can fix all the existing files following the steps detailed on the
> >> git documentation:
> >>
> >> $ echo "* text=auto" >.gitattributes
> >>
> >> $ git add --renormalize .
> >>
> >> $ git status# Show files that will be normalized
> >>
> >> $ git commit -m "Introduce end-of-line normalization"
> > Thanks, though that did not pick up two of the files.
>
> Oh dear.
>
> When I tried this locally it misses from your list:
>
> ./src/changes/changes.xml
> ./src/test/java/org/apache/commons/codec/language/ColognePhoneticTest.java
>
> Those files are also ignored on my machine (linux) by dos2unix. They are
> not found by any of the following [1]:
>
> $ grep -IUr --color "^M" src
> $ find src -type f | xargs file | grep CRLF
> $ grep -IUlr $'\r' src
>
> So are they a problem?

I don't know if this causes an issue.

I used file on macOS to detect the problem files.
Also my editor (BBEdit) shows the EOL as CRLF for them.

> >
> > However it looks like the commit message will show huge diffs for each file.
> >
> > Is that unavoidable?
>
> The diff is done line-by-line. So if each line changes then it is a big
> diff. I don't know a way around that.
>
> The alternative would be to leave the .gitattributes file and not commit
> the normalised files. The next time someone commits each of the
> offending files the normalisation will occur as git sends it back to the
> repo. So this just delays the big diff. At least if it all done at once
> then it makes more sense and avoids the issue of a big diff occurring
> some time in the future and someone has to figure it out all over again.

Agreed it's best done all at once.

I remember fixing EOLs on SVN but as I recall it did not create the
huge diffs so long as it was done on the appropriate OS.
Maybe doing it on Windows won't cause the diffs to be created? I may
be able to try that later.

> [1]
> https://stackoverflow.com/questions/73833/how-do-you-search-for-files-containing-dos-line-endings-crlf-with-grep-on-linu
>
> >
> >> [1] https://git-scm.com/docs/gitattributes
> >>
> >>
> >>>> Best regards, Julian
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >

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

Re: [CODEC] CRLF files in macOS checkout

[sebb]

On Tue, 18 Jun 2019 at 16:01, Alex Herbert  wrote:
>
>
> On 18/06/2019 15:38, sebb wrote:
> > On Tue, 18 Jun 2019 at 12:58, Alex Herbert  wrote:
> >>
> >> On 18/06/2019 11:00, sebb wrote:
> >>> On Tue, 18 Jun 2019 at 10:40, Alex Herbert  
> >>> wrote:
> >>>> On 18/06/2019 09:55, sebb wrote:
> >>>>> On Tue, 18 Jun 2019 at 08:15, Julian Reschke  
> >>>>> wrote:
> >>>>>> On 17.06.2019 23:26, sebb wrote:
> >>>>>>> Most of the files in my clone of codec have LF endings, however a few 
> >>>>>>> are CRLF:
> >>>>>>>
> >>>>>>> ./README.md
> >>>>>>> ./src/assembly/bin.xml
> >>>>>>> ./src/assembly/src.xml
> >>>>>>> ./src/changes/changes.xml
> >>>>>>> ./src/main/java/org/apache/commons/codec/cli/Digest.java
> >>>>>>> ./src/main/java/org/apache/commons/codec/language/DaitchMokotoffSoundex.java
> >>>>>>> ./src/main/resources/org/apache/commons/codec/language/bm/lang.txt
> >>>>>>> ./src/test/java/org/apache/commons/codec/digest/HmacAlgorithmsTest.java
> >>>>>>> ./src/test/java/org/apache/commons/codec/digest/MessageDigestAlgorithmsTest.java
> >>>>>>> ./src/test/java/org/apache/commons/codec/digest/PureJavaCrc32Test.java
> >>>>>>> ./src/test/java/org/apache/commons/codec/language/ColognePhoneticTest.java
> >>>>>>>
> >>>>>>>
> >>>>>>> This causes spurious differences when the files are updated.
> >>>>>>>
> >>>>>>> Can these files be easily fixed without causing huge diffs to be 
> >>>>>>> generated?
> >>>>>>>
> >>>>>>> Also, is there any way to prevent such files being committed to the 
> >>>>>>> repo?
> >>>>>>>
> >>>>>>> S.
> >>>>>> If svn:eol-style is set to "native", it shouldn't matter. I think this
> >>>>>> can be defaulted for newly added files.
> >>>>> Thanks, but this is Git, not SVN.
> >>>>>
> >>>>>> In Jackrabbit, I regularly run a script to spot new files missing the
> >>>>>> property.
> >>>>> Are you willing to share the script?
> >>>> This was recently a problem in [statistics]. It was fixed using a
> >>>> .gitattributes file [1] containing:
> >>>>
> >>>> * text=auto
> >>>>
> >>>> You can fix all the existing files following the steps detailed on the
> >>>> git documentation:
> >>>>
> >>>> $ echo "* text=auto" >.gitattributes
> >>>>
> >>>> $ git add --renormalize .
> >>>>
> >>>> $ git status# Show files that will be normalized
> >>>>
> >>>> $ git commit -m "Introduce end-of-line normalization"
> >>> Thanks, though that did not pick up two of the files.
> >> Oh dear.
> >>
> >> When I tried this locally it misses from your list:
> >>
> >> ./src/changes/changes.xml
> >> ./src/test/java/org/apache/commons/codec/language/ColognePhoneticTest.java
> >>
> >> Those files are also ignored on my machine (linux) by dos2unix. They are
> >> not found by any of the following [1]:
> >>
> >> $ grep -IUr --color "^M" src
> >> $ find src -type f | xargs file | grep CRLF
> >> $ grep -IUlr $'\r' src
> >>
> >> So are they a problem?
> > I don't know if this causes an issue.
> >
> > I used file on macOS to detect the problem files.
> > Also my editor (BBEdit) shows the EOL as CRLF for them.

I've since recloned the repo, and those 2 files don't have CRLF endings.
Something must have been confused in my workspace.

> I am currently on linux. I don't have any settings for line endings
> configured for git [1], i.e. the core.autocrlf property. So if I am
> correct what I pulled from the master repo is unchanged on checkout. And
> the two spurious files seem OK for me and 9 require updating.
>
> I can try it again on MacOS later. Maybe something is different there
> and this is very platform specific.
>
> >
> >>> However it looks like the commit message will show huge

Re: [Rng] Jenkins JDK 1.6 failing

[sebb]

On Thu, 20 Jun 2019 at 13:06, Alex Herbert  wrote:
>
> On 20/06/2019 12:45, Apache Jenkins Server wrote:
> > The Apache Jenkins build system has built commons-rng (build #361)
> >
> > Status: Still Failing
> >
> > Check console output at https://builds.apache.org/job/commons-rng/361/ to 
> > view the results.
>
> Jenkins is failing the RAT check on JDK 1.6 with apparently 332
> unapproved licences.
>
> It passes on the JDK 1.9 build.
>
> A vanilla git clone of the repo builds fine with this many files
> included by rat:
>
> [INFO] 81 implicit excludes (use -debug for more details).
> [INFO] 19 explicit excludes (use -debug for more details).
> [INFO] 138 resources included (use -debug for more details)
>
> The same log output from Jenkins reads:
>
> [INFO] 80 implicit excludes (use -debug for more details).
> [INFO] 19 explicit excludes (use -debug for more details).
> [INFO] 627 resources included (use -debug for more details)
>
> The last successful build on Jenkins reads:
>
> [INFO] 81 implicit excludes (use -debug for more details).
> [INFO] 19 explicit excludes (use -debug for more details).
> [INFO] 136 resources included (use -debug for more details)
>
> Since this build I added two files so that matches with the 138
> resources in the vanilla build.
>
> So for some reason the latest builds have a lot more files in the
> working directory.
>
> Is there a way to see the working directory that Jenkins is using and
> the rat.txt report? There is something that should not be there.

https://builds.apache.org/job/commons-rng/ws/

However AFAIK this will be updated for each build, so you may need to
suspend builds temporarily.

> Is this something for INFRA to fix?

Unlikely, most likely the job does not tidy up properly.

> Alex
>
>

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

Re: [ANNOUNCEMENT] Apache Commons Collections 4.4

[sebb]

On Tue, 9 Jul 2019 at 15:34, Gary Gregory  wrote:
>
> The Apache Commons team released Apache Commons Collections 4.4.
>
> The Apache Commons Collections package contains types that extend and
> augment the Java Collections Framework.
>
> Maintenance release.
>
> Changes in this version include:
>
> New features:
> o COLLECTIONS-715:  Implement Collection's removeIf(). Thanks to
> morningmemo, Gary Gregory.
> o COLLECTIONS-719:  Create a PropertiesFactory and SortedPropertiesFactory.
> Thanks to Gary Gregory.
> o COLLECTIONS-719:  Support Transformer for LazyList #52. Thanks to Stephan
> Windmüller, Bruno P. Kinoshita.
> o COLLECTIONS-723:  Make use of FunctionalInterface #48. Thanks to Eitan
> Adler, SOC, Bruno P. Kinoshita.
>
> Fixed Bugs:
> o COLLECTIONS-710:  NullPointerExceptions in CompositeCollection,
> CompositeSet, and CompositeMap. Thanks to Yu Shi, Gary Gregory.
>
> Changes:
> o COLLECTIONS-718:  Fix LRUMap exception message. Thanks to Eitan Adler.
> o COLLECTIONS-716:  Don't include email address in Exception messages.
> Thanks to Sebb.
>
> For complete information on Apache Commons Collections, including
> instructions on how to submit bug reports,
> patches, or suggestions for improvement, see the Apache Apache Commons
> Collections website:
>
> https://commons.apache.org/proper/commons-collections/
>
> Download page:
> https://commons.apache.org/proper/commons-collections/download_pool.cgi

That should be:

https://commons.apache.org/proper/commons-collections/download_collections.cgi

> Gary Gregory
> for the Apache Commons Team

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

Re: [ANNOUNCEMENT] Apache Commons Collections 4.4

[sebb]

On Wed, 10 Jul 2019 at 13:39, Gary Gregory  wrote:
>
> [Updated download page below]
> The Apache Commons team released Apache Commons Collections 4.4.
>
> The Apache Commons Collections package contains types that extend and
> augment the Java Collections Framework.
>
> Maintenance release.
>
> Changes in this version include:
>
> New features:
> o COLLECTIONS-715:  Implement Collection's removeIf(). Thanks to
> morningmemo, Gary Gregory.
> o COLLECTIONS-719:  Create a PropertiesFactory and SortedPropertiesFactory.
> Thanks to Gary Gregory.
> o COLLECTIONS-719:  Support Transformer for LazyList #52. Thanks to Stephan
> Windmüller, Bruno P. Kinoshita.
> o COLLECTIONS-723:  Make use of FunctionalInterface #48. Thanks to Eitan
> Adler, SOC, Bruno P. Kinoshita.
>
> Fixed Bugs:
> o COLLECTIONS-710:  NullPointerExceptions in CompositeCollection,
> CompositeSet, and CompositeMap. Thanks to Yu Shi, Gary Gregory.
>
> Changes:
> o COLLECTIONS-718:  Fix LRUMap exception message. Thanks to Eitan Adler.
> o COLLECTIONS-716:  Don't include email address in Exception messages.
> Thanks to Sebb.
>
> For complete information on Apache Commons Collections, including
> instructions on how to submit bug reports,
> patches, or suggestions for improvement, see the Apache Apache Commons
> Collections website:
>
> https://commons.apache.org/proper/commons-collections/
>
> Download page:
> https://dist.apache.org/repos/dist/release/commons/collections

Please do *not* use the above URL. Instead please use:

https://commons.apache.org/proper/commons-collections/download_collections.cgi


> Gary Gregory
> for the Apache Commons Team

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

Re: [ANNOUNCEMENT] Apache Commons VFS 2.4

[sebb]

On Thu, 18 Jul 2019 at 14:25, Gary Gregory  wrote:
>
> The Apache Commons VFS Project team is pleased to announce the release of
> Apache Commons VFS Project 2.4.
>
> Apache Commons VFS is a Virtual File System library.
>
> New features and bug fix release.
>
> Changes in this version include:
>
> New features:
> o VFS-690:  Allow to set key exchange algorithm explicitly. GitHub #32.
> o VFS-497:  Ported filters from Commons IO #9. Thanks to Michael Schnell.
> o VFS-696:  More efficient comparison in FileExtensionSelector #44. Thanks
> to Robert DeRose.
> o VFS-660:  Expose workaround for connecting to FTP server from different
> subnets in PASV mode #35. Thanks to Liu Yubao.
> o VFS-699:  Add setting for FTP encoding auto-detection #58. Thanks to
> Boris Petrov.
> o VFS-706:  Add ability to specify buffer sizes #59. Thanks to Boris Petrov.
> o VFS-609:  SFTP provider doesn't support a private key as byte array #60.
> Thanks to stevezhuang, Rostislav, Gary Gregory.
> o VFS-707:  Update Apache HttpClient from 4.5.7 to 4.5.8. Thanks to Gary
> Gregory.
> o VFS-712:  Add null-safe
> org.apache.commons.vfs2.util.FileObjectUtils.exists(FileObject). Thanks to
> Gary Gregory.
> o VFS-713:  Add FileObjectUtils.readProperties(FileObject) method to read a
> .properties file. Thanks to Gary Gregory.
> o VFS-715:  Add org.apache.commons.vfs2.FileContent.getByteArray(). Thanks
> to Gary Gregory.
> o VFS-719:  Add methods to get the contents of file objects as strings.
> Thanks to Gary Gregory.
> o VFS-720:  Implement Closeable for RandomAccessContent #66. Thanks to
> Boris Petrov.
> o VFS-721:  Add support for symbolic links for the local file system and
> add FileObject#isSymbolicLink(). Thanks to Gary Gregory.
>
> Fixed Bugs:
> o VFS-694:  Fix inability to start the DefaultFileMonitor after it has been
> stopped. GitHub PR #55. Thanks to Boris Petrov.
> o VFS-696:  SFTP HTTP and SOCKS proxy authentication. GitHub PR #49. Thanks
> to rayzzed.
> o VFS-707:  [SFTP] SftpFileSystem.executeCommand(String, StringBuilder) can
> leak ChannelExec objects. Thanks to Gary Gregory.
> o VFS-709:  [SFTP] SftpFileSystem.getGroupsIds() can initialize underlying
> data more than once while multithreading. Thanks to Gary Gregory.
> o VFS-710:  [SFTP] SftpFileSystem.getUid() can initialize underlying data
> more than once while multithreading. Thanks to Gary Gregory.
> o VFS-711:  [SFTP] SftpFileSystem can initialize underlying Session more
> than once while multithreading. Thanks to Gary Gregory.
> o VFS-662:  [SFTP] SftpFileSystem has Thread-safe issue about idleChannel
> (#36). Thanks to qxo, Alexey Abashev, Gary Gregory.
> o VFS-700:  Some tests fail on Java 11 and above. Thanks to Gary Gregory,
> Matthias Krueger.
> o VFS-716:  Fix AbstractFileName.getURI returning unencoded #-sign #64.
> Thanks to Boris Petrov.
> o VFS-698:  SFTP file attributes are fetched multiple times leading to very
> slow directory listing; #65. Thanks to David Septimus, Bernd.
> o VFS-717:  Update org.apache.httpcomponents:httpclient from 4.5.8 to
> 4.5.9. Thanks to Gary Gregory.
> o VFS-718:  MonitorInputStream should not close the stream in "read" #67.
> Thanks to Boris Petrov.
>
> Changes:
> o VFS-692:  Update Apache Commons Collections from 4.2 to 4.3. Thanks to
> Gary Gregory.
> o VFS-693:  Add support for customizing FTP transfer aborted status codes.
> GitHub PR #51. Thanks to Boris Petrov, Gary Gregory.
> o VFS-702:  Simplify adding files to DefaultFileMonitor #57. Thanks to
> Boris Petrov.
> o VFS-703:  Update Apache Commons Lang from 3.8.1 to 3.9. Thanks to Gary
> Gregory.
> o VFS-722:  Update Apache Commons Collections from 4.3 to 4.4. Thanks to
> Gary Gregory.
> o   Source incompatibility:
> org.apache.commons.vfs2.FileFilter.accept(FileSelectInfo) now throws
> checked exception FileSystemException.
> o   Public API note: The overridden methods getURI() and
> getFriendlyURI() in org.apache.commons.vfs2.provider.local.LocalFileName
> where removed but are implemented in a superclass.
> o   Public API note: The overridden method
> org.apache.commons.vfs2.provider.sftp.SftpFileObject#refresh() was removed
> but is implemented in a superclass.
> o   Public API note: The overridden method
> org.apache.commons.vfs2.provider.sftp.SftpFileProvider#init() was removed
> but is implemented in a superclass.
>
>
> Historical list of changes:
> http://commons.apache.org/proper/commons-vfs/changes-report.html
>
> For complete information on Apache Commons VFS Project, including
> instructions on how to submit bug reports,
> patches, or suggestions for improvement, see the Apache Apache Commons VFS
> Project website:
>
> Visit http://commons.apache.org/proper/commons-vfs/
>
> Download it from
> http://commons.apache.org/proper/commons-vfs/download_vfs.cgi

The binary links are all broken.

e.g. 
https://www.apache.org/dist/commons/vfs/binaries/commons-vfs-2.4.tar.gz.sha512
does not exist.

> Gary Gregory
> On behalf of Apache Comm

Re: [ANNOUNCEMENT] Apache Commons VFS 2.4

[sebb]

On Thu, 18 Jul 2019 at 15:29, Gary Gregory  wrote:
>
> On Thu, Jul 18, 2019 at 10:06 AM sebb  wrote:
>
> > On Thu, 18 Jul 2019 at 14:25, Gary Gregory  wrote:
> > >
> > > The Apache Commons VFS Project team is pleased to announce the release of
> > > Apache Commons VFS Project 2.4.
> > >
> > > Apache Commons VFS is a Virtual File System library.
> > >
> > > New features and bug fix release.
> > >
> > > Changes in this version include:
> > >
> > > New features:
> > > o VFS-690:  Allow to set key exchange algorithm explicitly. GitHub #32.
> > > o VFS-497:  Ported filters from Commons IO #9. Thanks to Michael Schnell.
> > > o VFS-696:  More efficient comparison in FileExtensionSelector #44.
> > Thanks
> > > to Robert DeRose.
> > > o VFS-660:  Expose workaround for connecting to FTP server from different
> > > subnets in PASV mode #35. Thanks to Liu Yubao.
> > > o VFS-699:  Add setting for FTP encoding auto-detection #58. Thanks to
> > > Boris Petrov.
> > > o VFS-706:  Add ability to specify buffer sizes #59. Thanks to Boris
> > Petrov.
> > > o VFS-609:  SFTP provider doesn't support a private key as byte array
> > #60.
> > > Thanks to stevezhuang, Rostislav, Gary Gregory.
> > > o VFS-707:  Update Apache HttpClient from 4.5.7 to 4.5.8. Thanks to Gary
> > > Gregory.
> > > o VFS-712:  Add null-safe
> > > org.apache.commons.vfs2.util.FileObjectUtils.exists(FileObject). Thanks
> > to
> > > Gary Gregory.
> > > o VFS-713:  Add FileObjectUtils.readProperties(FileObject) method to
> > read a
> > > .properties file. Thanks to Gary Gregory.
> > > o VFS-715:  Add org.apache.commons.vfs2.FileContent.getByteArray().
> > Thanks
> > > to Gary Gregory.
> > > o VFS-719:  Add methods to get the contents of file objects as strings.
> > > Thanks to Gary Gregory.
> > > o VFS-720:  Implement Closeable for RandomAccessContent #66. Thanks to
> > > Boris Petrov.
> > > o VFS-721:  Add support for symbolic links for the local file system and
> > > add FileObject#isSymbolicLink(). Thanks to Gary Gregory.
> > >
> > > Fixed Bugs:
> > > o VFS-694:  Fix inability to start the DefaultFileMonitor after it has
> > been
> > > stopped. GitHub PR #55. Thanks to Boris Petrov.
> > > o VFS-696:  SFTP HTTP and SOCKS proxy authentication. GitHub PR #49.
> > Thanks
> > > to rayzzed.
> > > o VFS-707:  [SFTP] SftpFileSystem.executeCommand(String, StringBuilder)
> > can
> > > leak ChannelExec objects. Thanks to Gary Gregory.
> > > o VFS-709:  [SFTP] SftpFileSystem.getGroupsIds() can initialize
> > underlying
> > > data more than once while multithreading. Thanks to Gary Gregory.
> > > o VFS-710:  [SFTP] SftpFileSystem.getUid() can initialize underlying data
> > > more than once while multithreading. Thanks to Gary Gregory.
> > > o VFS-711:  [SFTP] SftpFileSystem can initialize underlying Session more
> > > than once while multithreading. Thanks to Gary Gregory.
> > > o VFS-662:  [SFTP] SftpFileSystem has Thread-safe issue about idleChannel
> > > (#36). Thanks to qxo, Alexey Abashev, Gary Gregory.
> > > o VFS-700:  Some tests fail on Java 11 and above. Thanks to Gary Gregory,
> > > Matthias Krueger.
> > > o VFS-716:  Fix AbstractFileName.getURI returning unencoded #-sign #64.
> > > Thanks to Boris Petrov.
> > > o VFS-698:  SFTP file attributes are fetched multiple times leading to
> > very
> > > slow directory listing; #65. Thanks to David Septimus, Bernd.
> > > o VFS-717:  Update org.apache.httpcomponents:httpclient from 4.5.8 to
> > > 4.5.9. Thanks to Gary Gregory.
> > > o VFS-718:  MonitorInputStream should not close the stream in "read" #67.
> > > Thanks to Boris Petrov.
> > >
> > > Changes:
> > > o VFS-692:  Update Apache Commons Collections from 4.2 to 4.3. Thanks to
> > > Gary Gregory.
> > > o VFS-693:  Add support for customizing FTP transfer aborted status
> > codes.
> > > GitHub PR #51. Thanks to Boris Petrov, Gary Gregory.
> > > o VFS-702:  Simplify adding files to DefaultFileMonitor #57. Thanks to
> > > Boris Petrov.
> > > o VFS-703:  Update Apache Commons Lang from 3.8.1 to 3.9. Thanks to Gary
> > > Gregory.
> > > o VFS-722:  Update Apache Commons Collections from 4.3 to 4.4. Thanks to
> > > Gary Gregory.
> > > o   Source incompatibility:
> > > org.a

Re: [ANNOUNCEMENT] Apache Commons VFS 2.4

[sebb]

On Fri, 19 Jul 2019 at 03:51, Gary Gregory  wrote:
>
> On Thu, Jul 18, 2019 at 11:09 AM sebb  wrote:
>
> > On Thu, 18 Jul 2019 at 15:29, Gary Gregory  wrote:
> > >
> > > On Thu, Jul 18, 2019 at 10:06 AM sebb  wrote:
> > >
> > > > On Thu, 18 Jul 2019 at 14:25, Gary Gregory 
> > wrote:
> > > > >
> > > > > The Apache Commons VFS Project team is pleased to announce the
> > release of
> > > > > Apache Commons VFS Project 2.4.
> > > > >
> > > > > Apache Commons VFS is a Virtual File System library.
> > > > >
> > > > > New features and bug fix release.
> > > > >
> > > > > Changes in this version include:
> > > > >
> > > > > New features:
> > > > > o VFS-690:  Allow to set key exchange algorithm explicitly. GitHub
> > #32.
> > > > > o VFS-497:  Ported filters from Commons IO #9. Thanks to Michael
> > Schnell.
> > > > > o VFS-696:  More efficient comparison in FileExtensionSelector #44.
> > > > Thanks
> > > > > to Robert DeRose.
> > > > > o VFS-660:  Expose workaround for connecting to FTP server from
> > different
> > > > > subnets in PASV mode #35. Thanks to Liu Yubao.
> > > > > o VFS-699:  Add setting for FTP encoding auto-detection #58. Thanks
> > to
> > > > > Boris Petrov.
> > > > > o VFS-706:  Add ability to specify buffer sizes #59. Thanks to Boris
> > > > Petrov.
> > > > > o VFS-609:  SFTP provider doesn't support a private key as byte array
> > > > #60.
> > > > > Thanks to stevezhuang, Rostislav, Gary Gregory.
> > > > > o VFS-707:  Update Apache HttpClient from 4.5.7 to 4.5.8. Thanks to
> > Gary
> > > > > Gregory.
> > > > > o VFS-712:  Add null-safe
> > > > > org.apache.commons.vfs2.util.FileObjectUtils.exists(FileObject).
> > Thanks
> > > > to
> > > > > Gary Gregory.
> > > > > o VFS-713:  Add FileObjectUtils.readProperties(FileObject) method to
> > > > read a
> > > > > .properties file. Thanks to Gary Gregory.
> > > > > o VFS-715:  Add org.apache.commons.vfs2.FileContent.getByteArray().
> > > > Thanks
> > > > > to Gary Gregory.
> > > > > o VFS-719:  Add methods to get the contents of file objects as
> > strings.
> > > > > Thanks to Gary Gregory.
> > > > > o VFS-720:  Implement Closeable for RandomAccessContent #66. Thanks
> > to
> > > > > Boris Petrov.
> > > > > o VFS-721:  Add support for symbolic links for the local file system
> > and
> > > > > add FileObject#isSymbolicLink(). Thanks to Gary Gregory.
> > > > >
> > > > > Fixed Bugs:
> > > > > o VFS-694:  Fix inability to start the DefaultFileMonitor after it
> > has
> > > > been
> > > > > stopped. GitHub PR #55. Thanks to Boris Petrov.
> > > > > o VFS-696:  SFTP HTTP and SOCKS proxy authentication. GitHub PR #49.
> > > > Thanks
> > > > > to rayzzed.
> > > > > o VFS-707:  [SFTP] SftpFileSystem.executeCommand(String,
> > StringBuilder)
> > > > can
> > > > > leak ChannelExec objects. Thanks to Gary Gregory.
> > > > > o VFS-709:  [SFTP] SftpFileSystem.getGroupsIds() can initialize
> > > > underlying
> > > > > data more than once while multithreading. Thanks to Gary Gregory.
> > > > > o VFS-710:  [SFTP] SftpFileSystem.getUid() can initialize underlying
> > data
> > > > > more than once while multithreading. Thanks to Gary Gregory.
> > > > > o VFS-711:  [SFTP] SftpFileSystem can initialize underlying Session
> > more
> > > > > than once while multithreading. Thanks to Gary Gregory.
> > > > > o VFS-662:  [SFTP] SftpFileSystem has Thread-safe issue about
> > idleChannel
> > > > > (#36). Thanks to qxo, Alexey Abashev, Gary Gregory.
> > > > > o VFS-700:  Some tests fail on Java 11 and above. Thanks to Gary
> > Gregory,
> > > > > Matthias Krueger.
> > > > > o VFS-716:  Fix AbstractFileName.getURI returning unencoded #-sign
> > #64.
> > > > > Thanks to Boris Petrov.
> > > > > o VFS-698:  SFTP file attributes are fetched multiple times leading
> > to
> > > > very
> > > > > slow directory 

[ALL] Checkstyle DTDs have moved

[sebb]

Further to NET-672 and https://github.com/apache/commons-net/pull/42,
it seems the location for the checkstyle DTDs has moved.

See also:

https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/suppressions-filter.html
and
https://github.com/checkstyle/checkstyle/blob/master/config/suppressions.xml

I've not looked into which version of the DTD goes with which
Checkstyle version.

AFAICT recent releases don't actually require the DTD for normal use,
so this is not an urgent fix.
But it should ideally be done when preparing for a new release.
As a minimum, I think the host name needs to be updated.

For additional kudos, work out which version of the DTD is needed (and
document it with a comment!)

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

Re: [commons-collections] branch master updated: Fix download page for 3.2.2.

[sebb]

On Fri, 2 Aug 2019 at 14:55,  wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> ggregory pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-collections.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 3927b6c  Fix download page for 3.2.2.
> 3927b6c is described below
>
> commit 3927b6ca1e4ce7db5df42c232856836169c4fcc5
> Author: Gary Gregory 
> AuthorDate: Fri Aug 2 09:54:52 2019 -0400
>
> Fix download page for 3.2.2.

The fix was incomplete as the pom also needs to be updated (since done).

Please always recreate the download page by using

$ mvn commons-build:download-page

rather than hand-editing, as that can result in errors (as below).


> ---
>  pom.xml|  2 +-
>  src/site/xdoc/download_collections.xml | 22 +++---
>  2 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/pom.xml b/pom.xml
> index c3a56ba..f2c634a 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -23,7 +23,7 @@
>
>4.0.0
>commons-collections4
> -  4.5-SNAPSHOT
> +  4.4
>Apache Commons Collections
>
>2001
> diff --git a/src/site/xdoc/download_collections.xml 
> b/src/site/xdoc/download_collections.xml
> index e7d58c5..e878961 100644
> --- a/src/site/xdoc/download_collections.xml
> +++ b/src/site/xdoc/download_collections.xml
> @@ -207,28 +207,28 @@ limitations under the License.
>
>  
>
> -   href="[preferred]/commons/collections/binaries/commons-collections-4.1${commons.release.4.binary.suffix}.tar.gz">commons-collections-4.1${commons.release.4.binary.suffix}.tar.gz
> -   href="https://www.apache.org/dist/commons/collections/binaries/commons-collections-4.1${commons.release.4.binary.suffix}.tar.gz.sha512";>sha512
> -   href="https://www.apache.org/dist/commons/collections/binaries/commons-collections-4.1${commons.release.4.binary.suffix}.tar.gz.asc";>pgp
> +   href="[preferred]/commons/collections/binaries/commons-collections-3.2.2-bin.tar.gz">commons-collections-3.2.2-bin.tar.gz
> +   href="https://www.apache.org/dist/commons/collections/binaries/commons-collections-3.2.2-bin.tar.gz.sha256";>sha256
> +   href="https://www.apache.org/dist/commons/collections/binaries/commons-collections-3.2.2-bin.tar.gz.asc";>pgp
>
>
> -   href="[preferred]/commons/collections/binaries/commons-collections-4.1${commons.release.4.binary.suffix}.zip">commons-collections-4.1${commons.release.4.binary.suffix}.zip
> -   href="https://www.apache.org/dist/commons/collections/binaries/commons-collections-4.1${commons.release.4.binary.suffix}.zip.sha512";>sha512
> -   href="https://www.apache.org/dist/commons/collections/binaries/commons-collections-4.1${commons.release.4.binary.suffix}.zip.asc";>pgp
> +   href="[preferred]/commons/collections/binaries/commons-collections-3.2.2-bin.zip">commons-collections-3.2.2-bin.zip
> +   href="https://www.apache.org/dist/commons/collections/binaries/commons-collections-3.2.2-bin.zip.sha256";>sha256
> +   href="https://www.apache.org/dist/commons/collections/binaries/commons-collections-3.2.2-bin.zip.asc";>pgp
>
>  
>
>
>  
>
> -   href="[preferred]/commons/collections/source/commons-collections-4.1-src.tar.gz">commons-collections-4.1-src.tar.gz
> -   href="https://www.apache.org/dist/commons/collections/source/commons-collections-4.1-src.tar.gz.sha512";>sha512
> +   href="[preferred]/commons/collections/source/commons-collections-3.2.2-src.tar.gz">commons-collections-3.2.2-src.tar.gz
> +   href="https://www.apache.org/dist/commons/collections/source/commons-collections-4.1-src.tar.gz.sha256";>sha256

Wrong version above

> href="https://www.apache.org/dist/commons/collections/source/commons-collections-4.1-src.tar.gz.asc";>pgp

Ditto

>
>
> -   href="[preferred]/commons/collections/source/commons-collections-4.1-src.zip">commons-collections-4.1-src.zip
> -   href="https://www.apache.org/dist/commons/collections/source/commons-collections-4.1-src.zip.sha512";>sha512
> -   href="https://www.apache.org/dist/commons/collections/source/commons-collections-4.1-src.zip.asc";>pgp
> +   href="[preferred]/commons/collections/source/commons-collections-3.2.2-src.zip">commons-collections-3.2.2-src.zip
> +   href="https://www.apache.org/dist/commons/collections/source/commons-collections-3.2.2-src.zip.sha256";>sha256
> +   href="https://www.apache.org/dist/commons/collections/source/commons-collections-3.2.2src.zip.asc";>pgp

Wrong suffx.

>
>  
>
>

Re: [IO] Build fails with 3 checkstyle errors

[sebb]

I think checkstyle is correct here.

It's confusing to see an import that is only used by Javadoc.

On Fri, 9 Aug 2019 at 21:50, Gary Gregory  wrote:
>
> Checkstyle is not perfect :-( I will hack that in a little bit...
>
> Gary
>
> On Fri, Aug 9, 2019, 15:22 Rob Spoor  wrote:
>
> > See https://travis-ci.org/apache/commons-io/jobs/569951808. Two of the
> > errors report an unused import which is in fact used in Javadoc. The
> > other is a protected method without Javadoc.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

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

Re: [All][parent] RAT check

[sebb]

On Sat, 10 Aug 2019 at 15:42, Gary Gregory  wrote:
>
> Hi all,
>
> It seems to me the commons-parent should cause the RAT check to run for all
> builds, say in the... validate phase?

I think that might quickly become annoying; the verify phase might be better.

> Gary

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

[ALL] Problems with default download page hash types

[sebb]

I have had to fix several download pages recently because they
referred to sha512 instead of sha256.

Please would RMs double-check that the pom has the correct setting and
that the generated download_xyz.xml file corresponds with the file
names?

In future, I think the hash setting should *always* be specified in
the pom, rather than relying on a default (*)
How does one know whether the setting is missing by accident or design?
(It does not help that the default has been changed twice fairly recently)


Sebb.
(*) IMO built-in defaults should only be used for values that are
almost always correct, i.e. where it is unusual to see a different
value. Defaults should never be changed.

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

[BEANUTILS] website still refers to SVN

[sebb]

It looks like the pom has not been updated to change the SCM.
There are various other issues, e.g. download hash types.

The tag obviously cannot/must not be updated, so I wonder if one
approach would be to create a branch from the tag and build the site
from that?

Sebb.

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

[ALL] POM file standardisation of layout

[sebb]

I think it might be useful to try to work towards standardising the
order of sections within POMs.

This will make it easier to compare them across components.
(e.g. to see why one pom works and another fails!)
And should be easier to maintain.

In particular, I would like to move the developer and contributor
sections to the end.
They can be quite long, so they make it harder to read the pom.

Also to move properties near the beginning, as they are the most
likely to need change.
i.e. the main custom elements should be near the start.

I'm hoping that many poms will have a similar layout (probably many
were copied from another component).

Maybe start by extracting layouts from existing poms to create a few
skeleton poms.
Once a suitable layout has been agreed, components can be updated as
they are worked on.

Poms have a very regular structure, so it should be possible to
automate a lot of the work.

Thoughts?

I have had a look at the Maven Model [1] and Maven Code Style [2],
however I don't think they are suitable. The developer/contributor
sections are in the middle, which makes navigation harder.
Also the customised sections are scattered throughout.

Sebb.
[1] https://maven.apache.org/ref/3.6.1/maven-model/maven.html
[2] http://maven.apache.org/developers/conventions/code.html#POM_Code_Convention

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