Re: [compress] HasCharset is a bad name

2017-07-12 Thread Gary Gregory
On Wed, Jul 12, 2017 at 6:32 AM, Benedikt Ritter  wrote:

> Hello,
>
> > Am 11.07.2017 um 06:55 schrieb Simon Spero :
> >
> > Since it's an interface, I could change it to IHasACharset?
> >
> > Or If you prefer I  could rename it to YouGiveLove?  (Lucky Millenials-
> you
> > aren't headsonged)
>
> I recommend to leave this kind of irony out of mailing list communication.
> This is probably your personal style of communicating, but it is hard to
> understand in remote communication with people from other cultural
> backgrounds. It makes communication more boring to remove this kind of
> sugar, but it helps to avoid misunderstandings.
>

I suppose Slack would work...

G

>
> Cheers,
> Benedikt
>
> >
> > The name follows a pattern for interfaces of this sort, which are
> basically
> > retrofit markers for the presence of property, (with associated getters).
> > I've seen it used in other projects, but it might be bleed through from
> > some  OWL / RDF patterns.
> >
> > I'm not in love with the pattern but it required the least thought :)
> >
> > (java 8 makes this sort of interface moot, as the accessor can be added
> as
> > a default method. It is even be a candidate for the proper use of
> Optional.
> > )
> >
> > On Jul 5, 2017 1:14 PM, "Gary Gregory"  wrote:
> >
> > Hi All,
> >
> > The new interface name HasCharset is pretty bad IMO.
> >
> > CharsetProvider is the obvious (to me) better name even though there
> > already is a class called java.nio.charset.spi.CharsetProvider.
> >
> > Alternatives could be CharsetContainer, CharsetAccessor, CharsetGetter, ?
> >
> > Gary
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


[GitHub] commons-text issue #49: TEXT-89: WordUtils.initials support for UTF-16 surro...

2017-07-12 Thread ameyjadiye
Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-text/pull/49
  
@arunvinudss , amend commit comment as well.


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

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



Re: [daemon] moving to git ? and bump java version.

2017-07-12 Thread Amey Jadiye
Thanks for great insights Mark.

On Wed, Jul 12, 2017, 9:28 PM Mark Thomas  wrote:

> On 12 July 2017 16:33:01 CEST, Matt Sicker  wrote:
> >Are there plans to require 1.7 for Tomcat anytime? Otherwise, it might
> >be
> >necessary to make a new major version of daemon eventually for Java 8
> >or 9.
>
> Tomcat major versions are aligned with Java EE versions which in turn have
> a minimum Java version.
>
> Tomcat supports 3 current versions in parallel so we currently have:
>
> Tomcat 9 - Java EE 8 - Java 8
> Tomcat 8 - Java EE 7 - Java 7
> Tomcat 7 - Java EE 6 - Java 6
>
> Tomcat 7 support will continue until at least Java EE 9 is released. That
> is meant to be next year but there are no firm dates yet and experience
> suggests the Java EE 9 release date will slip.
>
> On that basis I expect Tomcat to need a Daemon that supports Java 6 for at
> least 2 more years.
>
> Is there a user requirement driving an increase in the minimum Java
> version? If not, I suggest we stick with 6 for now.
>

There is no user requirement , Commons daemon is still keeping minimum
dependency on java 1.5, we were thinking to move on minimum 1.6, nice to
hear there won't be any issue with tomcat since it's already on 1.6

For moving to much higher i.e. java 1.7 I'm sure daemon will take another
2-3 year for keeping stability across projects.

Regards,
Amey

Mark
>
>
> >
> >Anyways, 1.6 minimum makes sense to me mainly due to Java 9's compiler
> >not
> >supporting Java 5 targets anymore.
> >
> >On 12 July 2017 at 09:19, Mark Thomas  wrote:
> >
> >> On 11 July 2017 21:02:54 CEST, Amey Jadiye 
> >wrote:
> >> >Hi Daemon Maintainers / All,
> >> >
> >> >Daemon seems to be still being maintained on svn, do we have any
> >plan
> >> >moving code base to git ?
> >>
> >> No preference on this.
> >>
> >> >As fact there is low activity in daemon no one thought of bumping
> >> >version
> >> >from 1.5 to 1.6 OR we are keeping it purposefully to 1.5 ?
> >> >shall we bump it minimum to 1.6 ?
> >>
> >> 1.6 is OK for Tomcat. Anything higher will cause problems.
> >>
> >> Mark
> >>
> >> -
> >> 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: [daemon] moving to git ? and bump java version.

2017-07-12 Thread Mark Thomas
On 12 July 2017 16:33:01 CEST, Matt Sicker  wrote:
>Are there plans to require 1.7 for Tomcat anytime? Otherwise, it might
>be
>necessary to make a new major version of daemon eventually for Java 8
>or 9.

Tomcat major versions are aligned with Java EE versions which in turn have a 
minimum Java version.

Tomcat supports 3 current versions in parallel so we currently have:

Tomcat 9 - Java EE 8 - Java 8
Tomcat 8 - Java EE 7 - Java 7
Tomcat 7 - Java EE 6 - Java 6

Tomcat 7 support will continue until at least Java EE 9 is released. That is 
meant to be next year but there are no firm dates yet and experience suggests 
the Java EE 9 release date will slip.

On that basis I expect Tomcat to need a Daemon that supports Java 6 for at 
least 2 more years.

Is there a user requirement driving an increase in the minimum Java version? If 
not, I suggest we stick with 6 for now.

Mark


>
>Anyways, 1.6 minimum makes sense to me mainly due to Java 9's compiler
>not
>supporting Java 5 targets anymore.
>
>On 12 July 2017 at 09:19, Mark Thomas  wrote:
>
>> On 11 July 2017 21:02:54 CEST, Amey Jadiye 
>wrote:
>> >Hi Daemon Maintainers / All,
>> >
>> >Daemon seems to be still being maintained on svn, do we have any
>plan
>> >moving code base to git ?
>>
>> No preference on this.
>>
>> >As fact there is low activity in daemon no one thought of bumping
>> >version
>> >from 1.5 to 1.6 OR we are keeping it purposefully to 1.5 ?
>> >shall we bump it minimum to 1.6 ?
>>
>> 1.6 is OK for Tomcat. Anything higher will cause problems.
>>
>> Mark
>>
>> -
>> 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: [daemon] moving to git ? and bump java version.

2017-07-12 Thread Matt Sicker
Are there plans to require 1.7 for Tomcat anytime? Otherwise, it might be
necessary to make a new major version of daemon eventually for Java 8 or 9.

Anyways, 1.6 minimum makes sense to me mainly due to Java 9's compiler not
supporting Java 5 targets anymore.

On 12 July 2017 at 09:19, Mark Thomas  wrote:

> On 11 July 2017 21:02:54 CEST, Amey Jadiye  wrote:
> >Hi Daemon Maintainers / All,
> >
> >Daemon seems to be still being maintained on svn, do we have any plan
> >moving code base to git ?
>
> No preference on this.
>
> >As fact there is low activity in daemon no one thought of bumping
> >version
> >from 1.5 to 1.6 OR we are keeping it purposefully to 1.5 ?
> >shall we bump it minimum to 1.6 ?
>
> 1.6 is OK for Tomcat. Anything higher will cause problems.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Matt Sicker 


Re: [daemon] moving to git ? and bump java version.

2017-07-12 Thread Mark Thomas
On 11 July 2017 21:02:54 CEST, Amey Jadiye  wrote:
>Hi Daemon Maintainers / All,
>
>Daemon seems to be still being maintained on svn, do we have any plan
>moving code base to git ?

No preference on this.

>As fact there is low activity in daemon no one thought of bumping
>version
>from 1.5 to 1.6 OR we are keeping it purposefully to 1.5 ?
>shall we bump it minimum to 1.6 ?

1.6 is OK for Tomcat. Anything higher will cause problems.

Mark

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



Re: [compress] HasCharset is a bad name

2017-07-12 Thread Benedikt Ritter
Hello,

> Am 11.07.2017 um 06:55 schrieb Simon Spero :
> 
> Since it's an interface, I could change it to IHasACharset?
> 
> Or If you prefer I  could rename it to YouGiveLove?  (Lucky Millenials- you
> aren't headsonged)

I recommend to leave this kind of irony out of mailing list communication. This 
is probably your personal style of communicating, but it is hard to understand 
in remote communication with people from other cultural backgrounds. It makes 
communication more boring to remove this kind of sugar, but it helps to avoid 
misunderstandings.

Cheers,
Benedikt

> 
> The name follows a pattern for interfaces of this sort, which are basically
> retrofit markers for the presence of property, (with associated getters).
> I've seen it used in other projects, but it might be bleed through from
> some  OWL / RDF patterns.
> 
> I'm not in love with the pattern but it required the least thought :)
> 
> (java 8 makes this sort of interface moot, as the accessor can be added as
> a default method. It is even be a candidate for the proper use of Optional.
> )
> 
> On Jul 5, 2017 1:14 PM, "Gary Gregory"  wrote:
> 
> Hi All,
> 
> The new interface name HasCharset is pretty bad IMO.
> 
> CharsetProvider is the obvious (to me) better name even though there
> already is a class called java.nio.charset.spi.CharsetProvider.
> 
> Alternatives could be CharsetContainer, CharsetAccessor, CharsetGetter, ?
> 
> Gary


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



Re: [dbutils] Preparing for Release; Questions

2017-07-12 Thread Benedikt Ritter

> Am 11.07.2017 um 21:45 schrieb Gary Gregory :
> 
> Are they in sync now? Make sure you have you Maven settings set up just so.
> I think Maven has some docs on how to encrypted and save your passwords.

Maybe it is still syncing with the old svn mirror repository. We probably need 
to create an INFRA issue to change the synchronization.

Benedikt

> 
> Gary
> 
> On Mon, Jul 10, 2017 at 8:57 PM, Carl Hall  wrote:
> 
>> Hey Gary,
>> 
>> Thanks for adding me, but I'm getting the same error message as before.  I
>> checked my profile in whimsy and I appear to be a committer on commons and
>> part of the "committers" group.
>> It might be completely unrelated, but Github and git.a.o aren't in sync
>> with git-wip-us.a.o.  Maybe some weirdo setup thing somewhere?
>> 
>> On Sun, Jul 9, 2017 at 2:48 PM, Gary Gregory 
>> wrote:
>> 
>>> Hi Carl,
>>> 
>>> As you already are an Apache Committer, I've added you to the Commons
>>> Committers group, please try again in a few minutes.
>>> 
>>> Gary
>>> 
>>> On Sun, Jul 9, 2017 at 2:08 PM, Carl Hall  wrote:
>>> 
 Hi all,
 
 I'd like to make a release of dbutils.  I've worked through the release
 preparation guide[1] up to deploying the RC.  Rather expectedly, since
>>> this
 is my first attempt at releasing, I'm not able to complete the `mvn
>>> deploy`
 step.
 
 ```
 Failed to transfer file:
 https://repository.apache.org/service/local/staging/deploy/
 maven2/commons-dbutils/commons-dbutils/1.7/commons-dbutils-1.7.jar.
 Return code is: 401, ReasonPhrase: Unauthorized.
 ```
 
 Should I ask for write permission or should I ask someone else to
>> manage
 the release?
 
 Thanks,
 Carl
 
 1 https://commons.apache.org/releases/prepare.html
 
>>> 
>> 


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



[GitHub] commons-text issue #49: TEXT-89: UTF-32 support for WordUtils.initials using...

2017-07-12 Thread ameyjadiye
Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-text/pull/49
  
For detailed explanation.


https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/


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

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



[GitHub] commons-text issue #49: TEXT-89: UTF-32 support for WordUtils.initials using...

2017-07-12 Thread ecki
Github user ecki commented on the issue:

https://github.com/apache/commons-text/pull/49
  
Not sure I understand the question, surrogate Pairs only exist in UTF-16. 
UTF-8 uses a multi byte encoding for code points outside the BMP and UTF-32 
uses 4 bytes (and skips the high/low surrogate regions)


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

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



[GitHub] commons-text issue #49: TEXT-89: UTF-32 support for WordUtils.initials using...

2017-07-12 Thread arunvinudss
Github user arunvinudss commented on the issue:

https://github.com/apache/commons-text/pull/49
  
Okay I don't mind to change but what does UTF-16 with surrogate pairs 
support? Why did we do this refactoring?


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

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



[GitHub] commons-text issue #49: TEXT-89: UTF-32 support for WordUtils.initials using...

2017-07-12 Thread ecki
Github user ecki commented on the issue:

https://github.com/apache/commons-text/pull/49
  
It does not provide support for UTF-32 (which is a 4 byte encoding not 
implemented in the patch) but it provides support for UTF-16 surrogate pairs 
(1..2 x 2bytes). The both encodings are not compatible.


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

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



[GitHub] commons-text issue #49: TEXT-89: UTF-32 support for WordUtils.initials using...

2017-07-12 Thread ameyjadiye
Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-text/pull/49
  
probably just because utf-32 it could be confusing, @ecki can explain more.


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

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



[GitHub] commons-text issue #49: TEXT-89: UTF-32 support for WordUtils.initials using...

2017-07-12 Thread arunvinudss
Github user arunvinudss commented on the issue:

https://github.com/apache/commons-text/pull/49
  
Not sure why I should change the PR name? I never mentioned it provides 
native support for UTF-32 and it clearly states support using surrogate pairs .


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

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



[GitHub] commons-text issue #49: TEXT-89: UTF-32 support for WordUtils.initials using...

2017-07-12 Thread ameyjadiye
Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-text/pull/49
  
@arunvinudss , can you please rename PR saying character processing 
switched with codepoints and  change commit comment as well, that you can do 
with ```rebase``` or ```git commit --amend``` and then force push. with this we 
can accept and close this PR.


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

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



[GitHub] commons-imaging pull request #26: (doc) Update sample usage example links fr...

2017-07-12 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/commons-imaging/pull/26


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

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