Re: [jexl] 3.1 release review

2017-03-13 Thread Matt Sicker 
Using interfaces and implementing them are two entirely separate things.
For instance, people use Logger instances, but we've added new APIs to that
interface in log4j-api while maintaining backwards compatibility (though we
do that by providing abstract base classes for implementations to use).

On 13 March 2017 at 21:08, sebb  wrote:

> On 14 March 2017 at 01:38, Matt Sicker  wrote:
> > If they're not user-implemented interfaces, then changing them isn't
> really
> > a backwards incompatible change.
>
> I agree, but since users asked for the changes to the interfaces that
> suggests that the interfaces are being used externally.
>
> > On 13 March 2017 at 17:50, sebb  wrote:
> >
> >> On 13 March 2017 at 20:12, henrib  wrote:
> >> >
> >> > The interface modifications are fixes to user enhancement requests:
> >> >
> >> > JEXL-211: Add callable method to JexlExpression interface
> >> > JEXL-198: JxltEngine Template deos not expose pragmas
> >> > JEXL-201: Allow Interpreter to use live values from JexlEngine.Option
> >> > interface implemented by JexlContext
> >> >
> >> > Note again that these interfaces are *not* expected to be implemented
> by
> >> > user code.
> >>
> >> I'm not sure I understand how that follows.
> >>
> >> If the JIRAs are enhancement requests for users, surely the intention
> >> is to allow the users to make use of the new methods?
> >>
> >> That suggests that the users are currently using the interfaces.
> >>
> >> > The likelihood of any user implementing those and not filling
> >> > enhancements requests or even asking questions in the Apache mailing
> >> lists
> >> > (or Stackoverflow) seems very small...
> >>
> >> Sorry, no idea what you mean by that.
> >>
> >> > Choice is please (the few) users using the library or stay true to a
> rule
> >> > that protects no real usage in this case. I wish this was seen as an
> easy
> >> > choice for the community.
> >>
> >> Nor that.
> >>
> >> > Cheers
> >> >
> >> >
> >> >
> >> > --
> >> > View this message in context: http://apache-commons.680414.
> >> n4.nabble.com/jexl-3-1-release-review-tp4691513p4696492.html
> >> > Sent from the Commons - Dev mailing list archive at Nabble.com.
> >> >
> >> > -
> >> > 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
>
>


-- 
Matt Sicker

Re: [jexl] 3.1 release review

2017-03-13 Thread sebb 
On 14 March 2017 at 01:38, Matt Sicker  wrote:
> If they're not user-implemented interfaces, then changing them isn't really
> a backwards incompatible change.

I agree, but since users asked for the changes to the interfaces that
suggests that the interfaces are being used externally.

> On 13 March 2017 at 17:50, sebb  wrote:
>
>> On 13 March 2017 at 20:12, henrib  wrote:
>> >
>> > The interface modifications are fixes to user enhancement requests:
>> >
>> > JEXL-211: Add callable method to JexlExpression interface
>> > JEXL-198: JxltEngine Template deos not expose pragmas
>> > JEXL-201: Allow Interpreter to use live values from JexlEngine.Option
>> > interface implemented by JexlContext
>> >
>> > Note again that these interfaces are *not* expected to be implemented by
>> > user code.
>>
>> I'm not sure I understand how that follows.
>>
>> If the JIRAs are enhancement requests for users, surely the intention
>> is to allow the users to make use of the new methods?
>>
>> That suggests that the users are currently using the interfaces.
>>
>> > The likelihood of any user implementing those and not filling
>> > enhancements requests or even asking questions in the Apache mailing
>> lists
>> > (or Stackoverflow) seems very small...
>>
>> Sorry, no idea what you mean by that.
>>
>> > Choice is please (the few) users using the library or stay true to a rule
>> > that protects no real usage in this case. I wish this was seen as an easy
>> > choice for the community.
>>
>> Nor that.
>>
>> > Cheers
>> >
>> >
>> >
>> > --
>> > View this message in context: http://apache-commons.680414.
>> n4.nabble.com/jexl-3-1-release-review-tp4691513p4696492.html
>> > Sent from the Commons - Dev mailing list archive at Nabble.com.
>> >
>> > -
>> > 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

Re: [jexl] 3.1 release review

2017-03-13 Thread Matt Sicker 
If they're not user-implemented interfaces, then changing them isn't really
a backwards incompatible change.

On 13 March 2017 at 17:50, sebb  wrote:

> On 13 March 2017 at 20:12, henrib  wrote:
> >
> > The interface modifications are fixes to user enhancement requests:
> >
> > JEXL-211: Add callable method to JexlExpression interface
> > JEXL-198: JxltEngine Template deos not expose pragmas
> > JEXL-201: Allow Interpreter to use live values from JexlEngine.Option
> > interface implemented by JexlContext
> >
> > Note again that these interfaces are *not* expected to be implemented by
> > user code.
>
> I'm not sure I understand how that follows.
>
> If the JIRAs are enhancement requests for users, surely the intention
> is to allow the users to make use of the new methods?
>
> That suggests that the users are currently using the interfaces.
>
> > The likelihood of any user implementing those and not filling
> > enhancements requests or even asking questions in the Apache mailing
> lists
> > (or Stackoverflow) seems very small...
>
> Sorry, no idea what you mean by that.
>
> > Choice is please (the few) users using the library or stay true to a rule
> > that protects no real usage in this case. I wish this was seen as an easy
> > choice for the community.
>
> Nor that.
>
> > Cheers
> >
> >
> >
> > --
> > View this message in context: http://apache-commons.680414.
> n4.nabble.com/jexl-3-1-release-review-tp4691513p4696492.html
> > Sent from the Commons - Dev mailing list archive at Nabble.com.
> >
> > -
> > 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

Jenkins build is unstable: commons-email #7

2017-03-13 Thread Apache Jenkins Server 
See 


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

Jenkins build is unstable: commons-email » Apache Commons Email #7

2017-03-13 Thread Apache Jenkins Server 
See 



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

Build failed in Jenkins: commons-email #6

2017-03-13 Thread Apache Jenkins Server 
See 


Changes:

[sebb] Unused imports

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on beam8 (beam) in workspace 

Checking out a fresh workspace because there's no workspace at 

Cleaning local Directory .
Checking out https://svn.apache.org/repos/asf/commons/proper/email/trunk at 
revision '2017-03-14T01:23:23.470 +'
AUNOTICE.txt
AULICENSE.txt
AURELEASE-NOTES.txt
A .gitignore
A conf
AUconf/checkstyle.xml
AUconf/HEADER.txt
AUconf/findbugs-exclude-filter.xml
A .travis.yml
A src
A src/main
A src/main/java
A src/main/java/org
A src/main/java/org/apache
A src/main/java/org/apache/commons
A src/main/java/org/apache/commons/mail
AUsrc/main/java/org/apache/commons/mail/DefaultAuthenticator.java
AUsrc/main/java/org/apache/commons/mail/ImageHtmlEmail.java
AUsrc/main/java/org/apache/commons/mail/EmailAttachment.java
AUsrc/main/java/org/apache/commons/mail/SimpleEmail.java
A src/main/java/org/apache/commons/mail/resolver
AU
src/main/java/org/apache/commons/mail/resolver/DataSourceFileResolver.java
AU
src/main/java/org/apache/commons/mail/resolver/DataSourceClassPathResolver.java
AU
src/main/java/org/apache/commons/mail/resolver/DataSourceCompositeResolver.java
AU
src/main/java/org/apache/commons/mail/resolver/DataSourceUrlResolver.java
AUsrc/main/java/org/apache/commons/mail/resolver/package-info.java
AU
src/main/java/org/apache/commons/mail/resolver/DataSourceBaseResolver.java
AUsrc/main/java/org/apache/commons/mail/EmailConstants.java
AUsrc/main/java/org/apache/commons/mail/package-info.java
AUsrc/main/java/org/apache/commons/mail/EmailException.java
AUsrc/main/java/org/apache/commons/mail/Email.java
AUsrc/main/java/org/apache/commons/mail/EmailUtils.java
AUsrc/main/java/org/apache/commons/mail/MultiPartEmail.java
AUsrc/main/java/org/apache/commons/mail/DataSourceResolver.java
AUsrc/main/java/org/apache/commons/mail/HtmlEmail.java
AUsrc/main/java/org/apache/commons/mail/ByteArrayDataSource.java
A src/main/java/org/apache/commons/mail/util
AUsrc/main/java/org/apache/commons/mail/util/MimeMessageUtils.java
A 
src/main/java/org/apache/commons/mail/util/IDNEmailAddressConverter.java
AUsrc/main/java/org/apache/commons/mail/util/package-info.java
AUsrc/main/java/org/apache/commons/mail/util/MimeMessageParser.java
A src/main/resources
A src/main/resources/META-INF
A src/main/resources/META-INF/mime.types
A src/site
AUsrc/site/site.xml
A src/site/resources
A src/site/resources/profile.jacoco
AUsrc/site/resources/download_email.cgi
A src/site/resources/images
AUsrc/site/resources/images/email-logo-white.xcf
AUsrc/site/resources/images/email-logo-white.png
A src/site/xdoc
AUsrc/site/xdoc/index.xml
AUsrc/site/xdoc/issue-tracking.xml
AUsrc/site/xdoc/userguide.xml
AUsrc/site/xdoc/building.xml
AUsrc/site/xdoc/download_email.xml
AUsrc/site/xdoc/mail-lists.xml
AUsrc/site/xdoc/release_1_0.xml
AUsrc/site/xdoc/release_1_1.xml
A src/changes
AUsrc/changes/changes.xml
A src/assembly
AUsrc/assembly/src.xml
AUsrc/assembly/bin.xml
A src/test
A src/test/resources
A src/test/resources/eml
A src/test/resources/eml/multipart-text-attachment.eml
A src/test/resources/eml/simple.eml
A src/test/resources/eml/html-attachment.eml
A src/test/resources/eml/multipart-report.eml
A src/test/resources/eml/outofmemory-no-header-seperation.eml
A src/test/resources/eml/simple-reply.eml
A src/test/resources/eml/html-attachment-content-disposition.eml
A src/test/resources/eml/attachment-only.eml
A src/test/resources/eml/html-attachment-encoded-filename.eml
A src/test/resources/eml/multipart-text-attachment-only.eml
A src/test/resources/html
AUsrc/test/resources/html/www.apache.org.html
A src/test/resources/images
AUsrc/test/resources/images/contentTypeTest.jpg
AUsrc/test/resources/images/contentTypeTest.png
AUsrc/test/resources/images/contentTypeTest.gif
A src/test/resources/images/logos
AUsrc/test/resources/images/logos/maven-feather.png
AUsrc/test/resources/images/asf_logo_wide.gif
A src/test/resources/attachments
AUsrc/test/resources/attachments/autoloadertest.html
AU

Re: [ANNOUNCE] Apache Commons Text 1.0 released!

2017-03-13 Thread Gary Gregory 
+1

Gary

On Mar 13, 2017 6:55 PM, "Benedikt Ritter"  wrote:

> Kudos to Rob for getting this release out of the door!
>
> > Am 13.03.2017 um 13:27 schrieb Rob Tompkins :
> >
> > The Apache Commons Team is pleased to announce the release of
> > Apache Commons Text 1.0.
> >
> > The Apache Commons Text open source software library provides a host of
> > algorithms focused on working with strings and blocks of text.
> >
> > Notes.
> > (a) In 1.0 the package names are the expected
> "org.apache.commons.text.*";
> >   whereas, in 1.0-beta-1 they were "org.apache.commons.text.beta.*."
> > (b) The source and binary distributions' RELEASE-NOTES.txt contains a
> >   typographical error on line 29, where "1.0-beta-1" should be replaced
> >   by "1.0." We have fixed this in all locations other than inside the
> >   distributions.
> >
> > Source and binary distributions are available for download from the
> Apache
> > Commons download site:
> >  http://commons.apache.org/proper/commons-text/download_text.cgi
> >
> > When downloading, please verify signatures using the KEYS file available
> at
> > the above location when downloading the release.
> >
> > Alternatively the release can be pulled via maven:
> >  org.apache.commons
> >  commons-text
> >  1.0
> >
> > The corrected release notes can be reviewed at:
> >  http://www.apache.org/dist/commons/text/RELEASE-NOTES.txt
> >
> > For complete information on Commons Text, including instructions on how
> to
> > submit bug reports, patches, or suggestions for improvement, see the
> Apache
> > Commons Text website:
> >
> > http://commons.apache.org/proper/commons-text/
> >
> > Best regards,
> > Rob Tompkins
> > on behalf of the Apache Commons community
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [jexl] 3.1 release review

2017-03-13 Thread sebb 
On 13 March 2017 at 20:12, henrib  wrote:
>
> The interface modifications are fixes to user enhancement requests:
>
> JEXL-211: Add callable method to JexlExpression interface
> JEXL-198: JxltEngine Template deos not expose pragmas
> JEXL-201: Allow Interpreter to use live values from JexlEngine.Option
> interface implemented by JexlContext
>
> Note again that these interfaces are *not* expected to be implemented by
> user code.

I'm not sure I understand how that follows.

If the JIRAs are enhancement requests for users, surely the intention
is to allow the users to make use of the new methods?

That suggests that the users are currently using the interfaces.

> The likelihood of any user implementing those and not filling
> enhancements requests or even asking questions in the Apache mailing lists
> (or Stackoverflow) seems very small...

Sorry, no idea what you mean by that.

> Choice is please (the few) users using the library or stay true to a rule
> that protects no real usage in this case. I wish this was seen as an easy
> choice for the community.

Nor that.

> Cheers
>
>
>
> --
> View this message in context: 
> http://apache-commons.680414.n4.nabble.com/jexl-3-1-release-review-tp4691513p4696492.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
>
> -
> 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: [ANNOUNCE] Apache Commons Text 1.0 released!

2017-03-13 Thread Bruno P. Kinoshita 
Indeed! Impressive work. Thanks a lot Rob! Time to have fun using some edit 
distances now :-)




From: Benedikt Ritter 
To: Commons Developers List  
Sent: Tuesday, 14 March 2017 7:55 AM
Subject: Re: [ANNOUNCE] Apache Commons Text 1.0 released!


Kudos to Rob for getting this release out of the door!


> Am 13.03.2017 um 13:27 schrieb Rob Tompkins :
> 
> The Apache Commons Team is pleased to announce the release of
> Apache Commons Text 1.0.
> 
> The Apache Commons Text open source software library provides a host of
> algorithms focused on working with strings and blocks of text.
> 
> Notes.
> (a) In 1.0 the package names are the expected "org.apache.commons.text.*";
>   whereas, in 1.0-beta-1 they were "org.apache.commons.text.beta.*."
> (b) The source and binary distributions' RELEASE-NOTES.txt contains a
>   typographical error on line 29, where "1.0-beta-1" should be replaced
>   by "1.0." We have fixed this in all locations other than inside the
>   distributions.
> 
> Source and binary distributions are available for download from the Apache
> Commons download site:
>  http://commons.apache.org/proper/commons-text/download_text.cgi
> 
> When downloading, please verify signatures using the KEYS file available at
> the above location when downloading the release.
> 
> Alternatively the release can be pulled via maven:
>  org.apache.commons
>  commons-text
>  1.0
> 
> The corrected release notes can be reviewed at:
>  http://www.apache.org/dist/commons/text/RELEASE-NOTES.txt
> 
> For complete information on Commons Text, including instructions on how to
> submit bug reports, patches, or suggestions for improvement, see the Apache
> Commons Text website:
> 
> http://commons.apache.org/proper/commons-text/
> 
> Best regards,
> Rob Tompkins
> on behalf of the Apache Commons community


-
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: [jexl] 3.1 release review

2017-03-13 Thread henrib 

The interface modifications are fixes to user enhancement requests:

JEXL-211: Add callable method to JexlExpression interface
JEXL-198: JxltEngine Template deos not expose pragmas
JEXL-201: Allow Interpreter to use live values from JexlEngine.Option
interface implemented by JexlContext

Note again that these interfaces are *not* expected to be implemented by
user code. The likelihood of any user implementing those and not filling
enhancements requests or even asking questions in the Apache mailing lists
(or Stackoverflow) seems very small...

Choice is please (the few) users using the library or stay true to a rule
that protects no real usage in this case. I wish this was seen as an easy
choice for the community.
Cheers



--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/jexl-3-1-release-review-tp4691513p4696492.html
Sent from the Commons - Dev mailing list archive at Nabble.com.

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

Re: [ANNOUNCE] Apache Commons Text 1.0 released!

2017-03-13 Thread Benedikt Ritter 
Kudos to Rob for getting this release out of the door!

> Am 13.03.2017 um 13:27 schrieb Rob Tompkins :
> 
> The Apache Commons Team is pleased to announce the release of
> Apache Commons Text 1.0.
> 
> The Apache Commons Text open source software library provides a host of
> algorithms focused on working with strings and blocks of text.
> 
> Notes.
> (a) In 1.0 the package names are the expected "org.apache.commons.text.*";
>   whereas, in 1.0-beta-1 they were "org.apache.commons.text.beta.*."
> (b) The source and binary distributions' RELEASE-NOTES.txt contains a
>   typographical error on line 29, where "1.0-beta-1" should be replaced
>   by "1.0." We have fixed this in all locations other than inside the
>   distributions.
> 
> Source and binary distributions are available for download from the Apache
> Commons download site:
>  http://commons.apache.org/proper/commons-text/download_text.cgi
> 
> When downloading, please verify signatures using the KEYS file available at
> the above location when downloading the release.
> 
> Alternatively the release can be pulled via maven:
>  org.apache.commons
>  commons-text
>  1.0
> 
> The corrected release notes can be reviewed at:
>  http://www.apache.org/dist/commons/text/RELEASE-NOTES.txt
> 
> For complete information on Commons Text, including instructions on how to
> submit bug reports, patches, or suggestions for improvement, see the Apache
> Commons Text website:
> 
> http://commons.apache.org/proper/commons-text/
> 
> Best regards,
> Rob Tompkins
> on behalf of the Apache Commons community


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

Re: [LANG] Next release

2017-03-13 Thread Benedikt Ritter 
Hi,

> Am 13.03.2017 um 12:54 schrieb Rob Tompkins :
> 
> 
>> On Mar 13, 2017, at 5:22 AM, Benedikt Ritter  wrote:
>> 
>> Hello,
>> 
>> I’m going to start work on the next [lang] release tonight. If there is 
>> anything you would like to add, please do it now. If you want to help me 
>> with the release process, please review the various project reports and make 
>> sure they look good. Most importantly make sure RAT is clean and Clirr does 
>> not show breaking changes.
> 
> I might try to get in LANG-1300 today. We’re trying to decide if we want 
> “lastIndexOf” and “indexOf” to return the preceding number of “code points” 
> or “code units.” The javadoc states, "Finds the first index within a 
> CharSequence, handling null,” seemingly implying that we should return the 
> number of “code units” up to and including the matched character of that 
> which was supplied.
> 
> Thoughts?

To be honest, Text processing is not my area of expertise :-) I’m not even sure 
I know the difference between "code point“ and „code unit“…

Benedikt

> 
> -Rob
> 
>> 
>> Thank you!
>> Benedikt
>> -
>> 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: [jexl] 3.1 release review

2017-03-13 Thread Matt Sicker 
It's more of an issue for downstream users who implement the interface as
they'd now have an illegally declared class not implementing all abstract
methods.

On 13 March 2017 at 07:13, sebb  wrote:

> AFAICT two of the interface changes are not needed:
>
> JexlExpression#Callable can be dropped; AFAICT no other changes are needed.
> JxltEngine$Template#getPragmas() can be dropped if the test is
> modified to use TemplateScript and TS drops the @Override marker
>
> It's probably not easy to drop JexlEngine$Options#isCancellable() from
> the interface.
> Nor does it look very easy to interpose an Abstract implementation method.
> I don't know if one could add an extended Options interface.
>
> Is there a different way to implement isCancellable?
> Does it really belong in Options, or could it be added to JexlEngine
> instead?
>
> Adding methods to an interface does not break binary compatibility,
> however AIUI many downstream consumers rely on source builds so
> compatibility breaks of any kind should be avoided in the public API.
>
>
> On 12 March 2017 at 17:09, Matt Sicker  wrote:
> > BC can be handled a couple ways here besides renaming:
> >
> > * Are there already abstract classes that implementations are meant to
> > extend? If so, that limits the possibility of problems here without using
> > default methods in Java 8.
> > * If these are truly public interfaces for users to implement, then you
> can
> > extend the interface with an extended version which adds new methods. Try
> > not to name them Options31 if you can help it.
> >
> > On 12 March 2017 at 05:16, henrib  wrote:
> >
> >>
> >> I've reworded the warning about the source compatibility break in the
> >> release notes:
> >>
> >>
> >>
> >> If this source compatibility break is not 'permitted' despite its
> >> improbability, what option should we take:
> >> - move to another (jexl31) package ?
> >> - add 'extended' interfaces (Options31, JexlExpression31, Template31) ?
> >> - add a utility helper class (Jexl31Helper?) to put the 3 methods as
> >> functions ( boolean isCancellable(JExlEngine.Options opt) ?
> >>
> >>
> >> Comments welcome,
> >> Thanks
> >>
> >>
> >>
> >> --
> >> View this message in context: http://apache-commons.680414.
> >> n4.nabble.com/jexl-3-1-release-review-tp4691513p4696416.html
> >> Sent from the Commons - Dev mailing list archive at Nabble.com.
> >>
> >> -
> >> 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
>
>


-- 
Matt Sicker

[ANNOUNCE] Apache Commons Text 1.0 released!

2017-03-13 Thread Rob Tompkins 
The Apache Commons Team is pleased to announce the release of
Apache Commons Text 1.0.

The Apache Commons Text open source software library provides a host of
algorithms focused on working with strings and blocks of text.

Notes.
(a) In 1.0 the package names are the expected "org.apache.commons.text.*";
   whereas, in 1.0-beta-1 they were "org.apache.commons.text.beta.*."
(b) The source and binary distributions' RELEASE-NOTES.txt contains a
   typographical error on line 29, where "1.0-beta-1" should be replaced
   by "1.0." We have fixed this in all locations other than inside the
   distributions.

Source and binary distributions are available for download from the Apache
Commons download site:
  http://commons.apache.org/proper/commons-text/download_text.cgi

When downloading, please verify signatures using the KEYS file available at
the above location when downloading the release.

Alternatively the release can be pulled via maven:
  org.apache.commons
  commons-text
  1.0

The corrected release notes can be reviewed at:
  http://www.apache.org/dist/commons/text/RELEASE-NOTES.txt

For complete information on Commons Text, including instructions on how to
submit bug reports, patches, or suggestions for improvement, see the Apache
Commons Text website:

http://commons.apache.org/proper/commons-text/

Best regards,
Rob Tompkins
on behalf of the Apache Commons community

Re: [jexl] 3.1 release review

2017-03-13 Thread sebb 
AFAICT two of the interface changes are not needed:

JexlExpression#Callable can be dropped; AFAICT no other changes are needed.
JxltEngine$Template#getPragmas() can be dropped if the test is
modified to use TemplateScript and TS drops the @Override marker

It's probably not easy to drop JexlEngine$Options#isCancellable() from
the interface.
Nor does it look very easy to interpose an Abstract implementation method.
I don't know if one could add an extended Options interface.

Is there a different way to implement isCancellable?
Does it really belong in Options, or could it be added to JexlEngine instead?

Adding methods to an interface does not break binary compatibility,
however AIUI many downstream consumers rely on source builds so
compatibility breaks of any kind should be avoided in the public API.


On 12 March 2017 at 17:09, Matt Sicker  wrote:
> BC can be handled a couple ways here besides renaming:
>
> * Are there already abstract classes that implementations are meant to
> extend? If so, that limits the possibility of problems here without using
> default methods in Java 8.
> * If these are truly public interfaces for users to implement, then you can
> extend the interface with an extended version which adds new methods. Try
> not to name them Options31 if you can help it.
>
> On 12 March 2017 at 05:16, henrib  wrote:
>
>>
>> I've reworded the warning about the source compatibility break in the
>> release notes:
>>
>>
>>
>> If this source compatibility break is not 'permitted' despite its
>> improbability, what option should we take:
>> - move to another (jexl31) package ?
>> - add 'extended' interfaces (Options31, JexlExpression31, Template31) ?
>> - add a utility helper class (Jexl31Helper?) to put the 3 methods as
>> functions ( boolean isCancellable(JExlEngine.Options opt) ?
>>
>>
>> Comments welcome,
>> Thanks
>>
>>
>>
>> --
>> View this message in context: http://apache-commons.680414.
>> n4.nabble.com/jexl-3-1-release-review-tp4691513p4696416.html
>> Sent from the Commons - Dev mailing list archive at Nabble.com.
>>
>> -
>> 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

Re: [LANG] Next release

2017-03-13 Thread Rob Tompkins 

> On Mar 13, 2017, at 5:22 AM, Benedikt Ritter  wrote:
> 
> Hello,
> 
> I’m going to start work on the next [lang] release tonight. If there is 
> anything you would like to add, please do it now. If you want to help me with 
> the release process, please review the various project reports and make sure 
> they look good. Most importantly make sure RAT is clean and Clirr does not 
> show breaking changes.

I might try to get in LANG-1300 today. We’re trying to decide if we want 
“lastIndexOf” and “indexOf” to return the preceding number of “code points” or 
“code units.” The javadoc states, "Finds the first index within a CharSequence, 
handling null,” seemingly implying that we should return the number of “code 
units” up to and including the matched character of that which was supplied.

Thoughts?

-Rob

> 
> Thank you!
> Benedikt
> -
> 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

[VOTE][LAZY] Move Apache Commons Modeler to dormant

2017-03-13 Thread Benedikt Ritter 
Hi,

The Apache Commons Modeler component provides mechanisms to create Model MBeans 
compatible with JMX specification.

The last release dates back to 2007 and there hasn’t been any development 
activity since. Further more there has not been any discussion on our mailing 
lists about Modeler.

I think it is okay to assume that the component is not needed anymore and can 
therefor be moved to dormant.

So I’m calling a vote by lazy consensus for moving the Apache Commons Modeler 
component to dormant. This vote will close no sooner that 72 hours from now, 
i.e. sometime after 11:00 UTC 16-March 2017. This vote by lazy consensus will 
pass if nobody raises objections - no explicit +1 votes are required.

Regards,
Benedikt


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

Re: [LANG] Next release

2017-03-13 Thread Pascal Schumacher 
Hello Benedikt,

great news! :)

The reports should be fine/green.

Cheers,
Pascal

Am 13. März 2017 10:22:43 MEZ schrieb Benedikt Ritter :
>Hello,
>
>I’m going to start work on the next [lang] release tonight. If there is
>anything you would like to add, please do it now. If you want to help
>me with the release process, please review the various project reports
>and make sure they look good. Most importantly make sure RAT is clean
>and Clirr does not show breaking changes.
>
>Thank you!
>Benedikt
>-
>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>For additional commands, e-mail: dev-h...@commons.apache.org

[LANG] Next release

2017-03-13 Thread Benedikt Ritter 
Hello,

I’m going to start work on the next [lang] release tonight. If there is 
anything you would like to add, please do it now. If you want to help me with 
the release process, please review the various project reports and make sure 
they look good. Most importantly make sure RAT is clean and Clirr does not show 
breaking changes.

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

[RESULT][VOTE] Release Apache Commons CLI 1.4 based on RC1

2017-03-13 Thread Benedikt Ritter 
Resending the result mail with adjusted subject...

> Hello,
> 
> this vote passes with following votes:
> 
> Paul King: +1 (non-binding)
> Bruno P. Kinoshita: +1
> Robert Scholte: +1 (non-binding)
> Oliver Heger: +1
> Benedikt Ritter: +1
> 
> Thank you to all who have reviewed this RC.
> 
> Benedikt
> 
>> Am 09.03.2017 um 14:30 schrieb Benedikt Ritter :
>> 
>> Hi,
>> 
>> We have fixed some bugs and added two new features since CLI 1.3.1 was 
>> released,
>> so I would like to release CLI 1.4.
>> 
>> CLI 1.4 RC1 is available for review here:
>>   https://dist.apache.org/repos/dist/dev/commons/cli/cli-1.4-RC1/ (svn 
>> revision 18640)
>> 
>> The tag is here:
>>   http://svn.apache.org/repos/asf/commons/proper/cli/tags/cli-1.4-RC1/ (svn 
>> revision 1786159)
>>   N.B. the SVN revision is required because SVN tags are not immutable.
>> 
>> Maven artifacts are here:
>> https://repository.apache.org/content/repositories/orgapachecommons-1240
>> 
>> These are the Maven Artifacts and their hashes:
>> 
>> commons-cli-1.4.pom.asc
>> (SHA1: 94f01d5c45d00d7cfda8f7d0b8e16f57318b02a3)
>> commons-cli-1.4-test-sources.jar
>> (SHA1: 98e1c62e29f0c86c0bd8361cf6fdb59c8a106ff4)
>> commons-cli-1.4.jar
>> (SHA1: c51c00206bb913cd8612b24abd9fa98ae89719b1)
>> commons-cli-1.4-sources.jar.asc
>> (SHA1: 80a7676aba577faafd8278e9b321abaa426f3b45)
>> commons-cli-1.4-tests.jar
>> (SHA1: 1e39d7027793ce92342b10abb4d6437826211534)
>> commons-cli-1.4-tests.jar.asc
>> (SHA1: a558a4e58802af24ce58404df98b8c5737297bc9)
>> commons-cli-1.4-javadoc.jar.asc
>> (SHA1: d67ed3fea7b0346fcfa2a3c9c4092741ce6a84a7)
>> commons-cli-1.4-sources.jar
>> (SHA1: 40dfd9fdef125e19136135e68d54af6d9b0cfbb8)
>> commons-cli-1.4-javadoc.jar
>> (SHA1: 60090d1d137b0dd7a0c293d04fb2280a7eec3860)
>> commons-cli-1.4-test-sources.jar.asc
>> (SHA1: 180e61b1fba50d93291e4cbf35bbdfc0ba04a43f)
>> commons-cli-1.4.jar.asc
>> (SHA1: d6a040cbdc4789aeabe74f8e9f9602c7bd430541)
>> commons-cli-1.4.pom
>> (SHA1: c5aed4264ff37247043f6dcb6613d994ea7f8473)
>> 
>> I have tested this with JDK 1.7 and JDK 1.8 using Maven 3.3.9. Note that CLI 
>> required at least Java 5 and I haven’t tested this release with 1.5 or 1.6. 
>> If anybody has such old JDKs installed, I would appreciate some feedback on 
>> this.
>> 
>> Details of changes since 1.3.1 are in the release notes:
>> https://dist.apache.org/repos/dist/dev/commons/cli/cli-1.4-RC1/RELEASE-NOTES.txt
>> http://home.apache.org/~britter/commons/cli/1.4-RC1/changes-report.html
>> 
>> Site:
>> http://home.apache.org/~britter/commons/cli/1.4-RC1/
>> (note some *relative* links are broken and the 1.4 directories are not yet 
>> created - these will be OK once the site is deployed)
>> 
>> Clirr Report (compared to 1.3.1):
>> http://home.apache.org/~britter/commons/cli/1.4-RC1/clirr-report.html
>> (Sorry, after updating to commons-parent 42 the clirr report was not 
>> generated anymore. I had to do it by hand, that’s why it has a different 
>> style)
>> 
>> RAT Report:
>> http://home.apache.org/~britter/commons/cli/1.4-RC1/rat-report.html
>> 
>> KEYS:
>> https://www.apache.org/dist/commons/KEYS
>> 
>> Please review the release candidate and vote.
>> This vote will close no sooner that 72 hours from now,
>> i.e. sometime after 13:30 UTC 12-March 2017
>> 
>> [ ] +1 Release these artifacts
>> [ ] +0 OK, but...
>> [ ] -0 OK, but really should fix...
>> [ ] -1 I oppose this release because...
>> 
>> Thanks!
>> 
>> Benedikt
>> 
>> 
>> 
>> 
>> -
>> 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: [VOTE] Release Apache Commons CLI 1.4 based on RC1

2017-03-13 Thread Benedikt Ritter 
Hello,

this vote passes with following votes:

Paul King: +1 (non-binding)
Bruno P. Kinoshita: +1
Robert Scholte: +1 (non-binding)
Oliver Heger: +1
Benedikt Ritter: +1

Thank you to all who have reviewed this RC.

Benedikt

> Am 09.03.2017 um 14:30 schrieb Benedikt Ritter :
> 
> Hi,
> 
> We have fixed some bugs and added two new features since CLI 1.3.1 was 
> released,
> so I would like to release CLI 1.4.
> 
> CLI 1.4 RC1 is available for review here:
>https://dist.apache.org/repos/dist/dev/commons/cli/cli-1.4-RC1/ (svn 
> revision 18640)
> 
> The tag is here:
>http://svn.apache.org/repos/asf/commons/proper/cli/tags/cli-1.4-RC1/ (svn 
> revision 1786159)
>N.B. the SVN revision is required because SVN tags are not immutable.
> 
> Maven artifacts are here:
>  https://repository.apache.org/content/repositories/orgapachecommons-1240
> 
> These are the Maven Artifacts and their hashes:
> 
> commons-cli-1.4.pom.asc
> (SHA1: 94f01d5c45d00d7cfda8f7d0b8e16f57318b02a3)
> commons-cli-1.4-test-sources.jar
> (SHA1: 98e1c62e29f0c86c0bd8361cf6fdb59c8a106ff4)
> commons-cli-1.4.jar
> (SHA1: c51c00206bb913cd8612b24abd9fa98ae89719b1)
> commons-cli-1.4-sources.jar.asc
> (SHA1: 80a7676aba577faafd8278e9b321abaa426f3b45)
> commons-cli-1.4-tests.jar
> (SHA1: 1e39d7027793ce92342b10abb4d6437826211534)
> commons-cli-1.4-tests.jar.asc
> (SHA1: a558a4e58802af24ce58404df98b8c5737297bc9)
> commons-cli-1.4-javadoc.jar.asc
> (SHA1: d67ed3fea7b0346fcfa2a3c9c4092741ce6a84a7)
> commons-cli-1.4-sources.jar
> (SHA1: 40dfd9fdef125e19136135e68d54af6d9b0cfbb8)
> commons-cli-1.4-javadoc.jar
> (SHA1: 60090d1d137b0dd7a0c293d04fb2280a7eec3860)
> commons-cli-1.4-test-sources.jar.asc
> (SHA1: 180e61b1fba50d93291e4cbf35bbdfc0ba04a43f)
> commons-cli-1.4.jar.asc
> (SHA1: d6a040cbdc4789aeabe74f8e9f9602c7bd430541)
> commons-cli-1.4.pom
> (SHA1: c5aed4264ff37247043f6dcb6613d994ea7f8473)
> 
> I have tested this with JDK 1.7 and JDK 1.8 using Maven 3.3.9. Note that CLI 
> required at least Java 5 and I haven’t tested this release with 1.5 or 1.6. 
> If anybody has such old JDKs installed, I would appreciate some feedback on 
> this.
> 
> Details of changes since 1.3.1 are in the release notes:
>  
> https://dist.apache.org/repos/dist/dev/commons/cli/cli-1.4-RC1/RELEASE-NOTES.txt
>  http://home.apache.org/~britter/commons/cli/1.4-RC1/changes-report.html
> 
> Site:
>  http://home.apache.org/~britter/commons/cli/1.4-RC1/
>  (note some *relative* links are broken and the 1.4 directories are not yet 
> created - these will be OK once the site is deployed)
> 
> Clirr Report (compared to 1.3.1):
>  http://home.apache.org/~britter/commons/cli/1.4-RC1/clirr-report.html
> (Sorry, after updating to commons-parent 42 the clirr report was not 
> generated anymore. I had to do it by hand, that’s why it has a different 
> style)
> 
> RAT Report:
>  http://home.apache.org/~britter/commons/cli/1.4-RC1/rat-report.html
> 
> KEYS:
>  https://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now,
> i.e. sometime after 13:30 UTC 12-March 2017
> 
>  [ ] +1 Release these artifacts
>  [ ] +0 OK, but...
>  [ ] -0 OK, but really should fix...
>  [ ] -1 I oppose this release because...
> 
> Thanks!
> 
> Benedikt
> 
> 
> 
> 
> -
> 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: [VOTE] Release Apache Commons CLI 1.4 based on RC1

2017-03-13 Thread Benedikt Ritter 

> Am 09.03.2017 um 14:30 schrieb Benedikt Ritter :
> 
> Hi,
> 
> We have fixed some bugs and added two new features since CLI 1.3.1 was 
> released,
> so I would like to release CLI 1.4.
> 
> CLI 1.4 RC1 is available for review here:
>https://dist.apache.org/repos/dist/dev/commons/cli/cli-1.4-RC1/ (svn 
> revision 18640)
> 
> The tag is here:
>http://svn.apache.org/repos/asf/commons/proper/cli/tags/cli-1.4-RC1/ (svn 
> revision 1786159)
>N.B. the SVN revision is required because SVN tags are not immutable.
> 
> Maven artifacts are here:
>  https://repository.apache.org/content/repositories/orgapachecommons-1240
> 
> These are the Maven Artifacts and their hashes:
> 
> commons-cli-1.4.pom.asc
> (SHA1: 94f01d5c45d00d7cfda8f7d0b8e16f57318b02a3)
> commons-cli-1.4-test-sources.jar
> (SHA1: 98e1c62e29f0c86c0bd8361cf6fdb59c8a106ff4)
> commons-cli-1.4.jar
> (SHA1: c51c00206bb913cd8612b24abd9fa98ae89719b1)
> commons-cli-1.4-sources.jar.asc
> (SHA1: 80a7676aba577faafd8278e9b321abaa426f3b45)
> commons-cli-1.4-tests.jar
> (SHA1: 1e39d7027793ce92342b10abb4d6437826211534)
> commons-cli-1.4-tests.jar.asc
> (SHA1: a558a4e58802af24ce58404df98b8c5737297bc9)
> commons-cli-1.4-javadoc.jar.asc
> (SHA1: d67ed3fea7b0346fcfa2a3c9c4092741ce6a84a7)
> commons-cli-1.4-sources.jar
> (SHA1: 40dfd9fdef125e19136135e68d54af6d9b0cfbb8)
> commons-cli-1.4-javadoc.jar
> (SHA1: 60090d1d137b0dd7a0c293d04fb2280a7eec3860)
> commons-cli-1.4-test-sources.jar.asc
> (SHA1: 180e61b1fba50d93291e4cbf35bbdfc0ba04a43f)
> commons-cli-1.4.jar.asc
> (SHA1: d6a040cbdc4789aeabe74f8e9f9602c7bd430541)
> commons-cli-1.4.pom
> (SHA1: c5aed4264ff37247043f6dcb6613d994ea7f8473)
> 
> I have tested this with JDK 1.7 and JDK 1.8 using Maven 3.3.9. Note that CLI 
> required at least Java 5 and I haven’t tested this release with 1.5 or 1.6. 
> If anybody has such old JDKs installed, I would appreciate some feedback on 
> this.
> 
> Details of changes since 1.3.1 are in the release notes:
>  
> https://dist.apache.org/repos/dist/dev/commons/cli/cli-1.4-RC1/RELEASE-NOTES.txt
>  http://home.apache.org/~britter/commons/cli/1.4-RC1/changes-report.html
> 
> Site:
>  http://home.apache.org/~britter/commons/cli/1.4-RC1/
>  (note some *relative* links are broken and the 1.4 directories are not yet 
> created - these will be OK once the site is deployed)
> 
> Clirr Report (compared to 1.3.1):
>  http://home.apache.org/~britter/commons/cli/1.4-RC1/clirr-report.html
> (Sorry, after updating to commons-parent 42 the clirr report was not 
> generated anymore. I had to do it by hand, that’s why it has a different 
> style)
> 
> RAT Report:
>  http://home.apache.org/~britter/commons/cli/1.4-RC1/rat-report.html
> 
> KEYS:
>  https://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now,
> i.e. sometime after 13:30 UTC 12-March 2017
> 
>  [ ] +1 Release these artifacts
>  [ ] +0 OK, but...
>  [ ] -0 OK, but really should fix...
>  [ ] -1 I oppose this release because…

Here is my +1

> 
> Thanks!
> 
> Benedikt
> 
> 
> 
> 
> -
> 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