Re: [RDF] Graduating Commons RDF to Commons PMC
Source code repository moved to https://git-wip-us.apache.org/repos/asf/commons-rdf.git Also the github mirror: https://github.com/apache/commons-rdf Please, change to the new remote. On Thu, Dec 1, 2016 at 1:23 AM, Stian Soiland-Reyes wrote: > On 30 November 2016 at 03:58, Matt Sicker wrote: > > Is there anything to be done for jira? Also, don't forget to update the > scm > > URLs in the pom file. > > Yes, I've now changed the permissions of COMMONSRDF in Jira (should > now match IO, all "Commons developers" are 'Admins'), and asked INFRA > to change it to the commons notification scheme (issues@commons). I > also put Apache Commons Developers (e.g. issues@commons) as the > "Lead". > > I also renamed the Jenkins build from incubator-commonsrdf to > commons-rdf (but did not change it's git repo setting yet). > > -- > Stian Soiland-Reyes > http://orcid.org/-0001-9842-9718 > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Sergio Fernández Partner Technology Manager Redlink GmbH m: +43 6602747925 e: sergio.fernan...@redlink.co w: http://redlink.co
Re: [complex][math-util] dependencies
On Tue, Nov 29, 2016 at 8:48 PM, Gilles
wrote:
> In "Commons RNG", I completely dropped all custom-made exceptions.
> I suggest you do the same here.
> IMO, "simple", low-level, components can do with just throwing
> runtime exceptions from the standard library (with a hard-coded
> _English_ message).
So, let's say three different methods in Quaternion throw a ZeroException
right now.
Are you happy with a coding practice of each method calling
throw new RuntimeException("Zero Exception");
or would it be preferable to write an additional method at the bottom,
private static void zeroException() {
throw new RuntimeException("Zero Exception");
}
and call it three times?
And if I do that, I should just tally up the different exceptions in the
complex methods and have one more class, ComplexRuntimeExceptions.
Barring any further objections, this is what I'll do.
Eric
Re: [complex][math-util] dependencies
Two bad code smells:
Do not use RuntimeException. Is IllegalArgumentException a possibility?
Don't throw the exception in the new method, you will loose the complier's
ability to warn you about certain code paths. You can create the exception
in a new method though.
Gary
On Dec 13, 2016 5:57 AM, "Eric Barnhill" wrote:
> On Tue, Nov 29, 2016 at 8:48 PM, Gilles
> wrote:
>
>
> > In "Commons RNG", I completely dropped all custom-made exceptions.
> > I suggest you do the same here.
> > IMO, "simple", low-level, components can do with just throwing
> > runtime exceptions from the standard library (with a hard-coded
> > _English_ message).
>
>
> So, let's say three different methods in Quaternion throw a ZeroException
> right now.
>
> Are you happy with a coding practice of each method calling
>
> throw new RuntimeException("Zero Exception");
>
> or would it be preferable to write an additional method at the bottom,
>
> private static void zeroException() {
> throw new RuntimeException("Zero Exception");
> }
>
> and call it three times?
>
> And if I do that, I should just tally up the different exceptions in the
> complex methods and have one more class, ComplexRuntimeExceptions.
>
> Barring any further objections, this is what I'll do.
>
> Eric
>
Re: [complex][math-util] dependencies
On Tue, 13 Dec 2016 08:01:35 -0800, Gary Gregory wrote:
Two bad code smells:
Do not use RuntimeException. Is IllegalArgumentException a
possibility?
Sure, the standard exception closest to the situation should be used.
Don't throw the exception in the new method, you will loose the
complier's
ability to warn you about certain code paths. You can create the
exception
in a new method though.
I don't quite follow.
Could you give a code example (do/don't)?
Gary
On Dec 13, 2016 5:57 AM, "Eric Barnhill"
wrote:
On Tue, Nov 29, 2016 at 8:48 PM, Gilles
wrote:
> In "Commons RNG", I completely dropped all custom-made exceptions.
> I suggest you do the same here.
> IMO, "simple", low-level, components can do with just throwing
> runtime exceptions from the standard library (with a hard-coded
> _English_ message).
So, let's say three different methods in Quaternion throw a
ZeroException
right now.
Are you happy with a coding practice of each method calling
throw new RuntimeException("Zero Exception");
No.
You'll get warnings from code checkers (about string duplication).
or would it be preferable to write an additional method at the
bottom,
private static void zeroException() {
throw new RuntimeException("Zero Exception");
}
and call it three times?
And if I do that, I should just tally up the different exceptions in
the
complex methods and have one more class, ComplexRuntimeExceptions.
I think that if the exact same exception is needed more than
once, it's worth creating a class.
But it will be local to the package, without parameters and
not "Localizable".
It could be package-private to benefit from encapsulation,
without extending the public API.
Barring any further objections, this is what I'll do.
I'd refrain from defining a utility class (unless it is also
package-private, and only used as syntactic sugar).
By the way, you don't need to refer to "Runtime" in the names;
all exceptions in such codes should be unchecked.
Regards,
Gilles
Eric
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [complex][math-util] dependencies
On Tue, Dec 13, 2016 at 9:59 AM, Gilles
wrote:
> On Tue, 13 Dec 2016 08:01:35 -0800, Gary Gregory wrote:
>
>> Two bad code smells:
>>
>> Do not use RuntimeException. Is IllegalArgumentException a possibility?
>>
>
> Sure, the standard exception closest to the situation should be used.
>
>
>> Don't throw the exception in the new method, you will loose the complier's
>> ability to warn you about certain code paths. You can create the exception
>> in a new method though.
>>
>
> I don't quite follow.
> Could you give a code example (do/don't)?
>
>
>> Gary
>>
>> On Dec 13, 2016 5:57 AM, "Eric Barnhill" wrote:
>>
>> On Tue, Nov 29, 2016 at 8:48 PM, Gilles
>>> wrote:
>>>
>>>
>>> > In "Commons RNG", I completely dropped all custom-made exceptions.
>>> > I suggest you do the same here.
>>> > IMO, "simple", low-level, components can do with just throwing
>>> > runtime exceptions from the standard library (with a hard-coded
>>> > _English_ message).
>>>
>>>
>>> So, let's say three different methods in Quaternion throw a ZeroException
>>> right now.
>>>
>>> Are you happy with a coding practice of each method calling
>>>
>>> throw new RuntimeException("Zero Exception");
>>>
>>
> No.
> You'll get warnings from code checkers (about string duplication).
>
>
>>> or would it be preferable to write an additional method at the bottom,
>>>
>>> private static void zeroException() {
>>> throw new RuntimeException("Zero Exception");
>>> }
>>>
>>> and call it three times?
>>>
>>> And if I do that, I should just tally up the different exceptions in the
>>> complex methods and have one more class, ComplexRuntimeExceptions.
>>>
>>
> I think that if the exact same exception is needed more than
> once, it's worth creating a class.
> But it will be local to the package, without parameters and
> not "Localizable".
>
> It could be package-private to benefit from encapsulation,
> without extending the public API.
>
>
>>> Barring any further objections, this is what I'll do.
>>>
>>
> I'd refrain from defining a utility class (unless it is also
> package-private, and only used as syntactic sugar).
>
> By the way, you don't need to refer to "Runtime" in the names;
> all exceptions in such codes should be unchecked.
>
I would say "it depends". An exception should be checked if it is
recoverable. You should only used an unchecked exception if the problem
discovered is unrecoverable.
Gary
>
> Regards,
>
> Gilles
>
>
>>> Eric
>>>
>>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [complex][math-util] dependencies
On Tue, Dec 13, 2016 at 9:59 AM, Gilles
wrote:
> On Tue, 13 Dec 2016 08:01:35 -0800, Gary Gregory wrote:
>
>> Two bad code smells:
>>
>> Do not use RuntimeException. Is IllegalArgumentException a possibility?
>>
>
> Sure, the standard exception closest to the situation should be used.
>
>
>> Don't throw the exception in the new method, you will loose the complier's
>> ability to warn you about certain code paths. You can create the exception
>> in a new method though.
>>
>
> I don't quite follow.
> Could you give a code example (do/don't)?
Do:
private static IllegalArgumentException createZeroException() {
return new IllegalArgumentException("Zero Exception");
}
Don't:
private static void zeroException() {
throw new RuntimeException("Zero Exception");
}
Gary
>
>
>
>> Gary
>>
>> On Dec 13, 2016 5:57 AM, "Eric Barnhill" wrote:
>>
>> On Tue, Nov 29, 2016 at 8:48 PM, Gilles
>>> wrote:
>>>
>>>
>>> > In "Commons RNG", I completely dropped all custom-made exceptions.
>>> > I suggest you do the same here.
>>> > IMO, "simple", low-level, components can do with just throwing
>>> > runtime exceptions from the standard library (with a hard-coded
>>> > _English_ message).
>>>
>>>
>>> So, let's say three different methods in Quaternion throw a ZeroException
>>> right now.
>>>
>>> Are you happy with a coding practice of each method calling
>>>
>>> throw new RuntimeException("Zero Exception");
>>>
>>
> No.
> You'll get warnings from code checkers (about string duplication).
>
>
>>> or would it be preferable to write an additional method at the bottom,
>>>
>>> private static void zeroException() {
>>> throw new RuntimeException("Zero Exception");
>>> }
>>>
>>> and call it three times?
>>>
>>> And if I do that, I should just tally up the different exceptions in the
>>> complex methods and have one more class, ComplexRuntimeExceptions.
>>>
>>
> I think that if the exact same exception is needed more than
> once, it's worth creating a class.
> But it will be local to the package, without parameters and
> not "Localizable".
>
> It could be package-private to benefit from encapsulation,
> without extending the public API.
>
>
>>> Barring any further objections, this is what I'll do.
>>>
>>
> I'd refrain from defining a utility class (unless it is also
> package-private, and only used as syntactic sugar).
>
> By the way, you don't need to refer to "Runtime" in the names;
> all exceptions in such codes should be unchecked.
>
> Regards,
>
> Gilles
>
>
>>> Eric
>>>
>>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Apache Commons RNG v1.0 is released
Hello. The Apache Commons Team is pleased to announce the availability of the first official release of "Apache Commons RNG". Apache Commons RNG provides Java implementations of pseudo-random numbers generators. The release notes can be reviewed at http://www.apache.org/dist/commons/rng/RELEASE-NOTES.txt Distribution packages can be downloaded from https://commons.apache.org/proper/commons-rng/download_rng.cgi When downloading, please verify signatures using the KEYS file available at http://www.apache.org/dist/commons Maven artifacts are also available in the central Maven repository: http://repo1.maven.org/maven2/org/apache/commons/ Best regards, The Apache Commons Team - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Apache Commons RNG v1.0 is released
On 14 December 2016 at 01:05, Gilles Sadowski wrote: > Hello. > > > The Apache Commons Team is pleased to announce the availability of > the first official release of "Apache Commons RNG". > > Apache Commons RNG provides Java implementations of pseudo-random > numbers generators. > > The release notes can be reviewed at > http://www.apache.org/dist/commons/rng/RELEASE-NOTES.txt > > Distribution packages can be downloaded from > https://commons.apache.org/proper/commons-rng/download_rng.cgi > > When downloading, please verify signatures using the KEYS file > available at > http://www.apache.org/dist/commons That should really be: https://www.apache.org/dist/commons/KEYS i.e. should use https: and the mail should specify the file itself (there are a lot of entries in that directory; make it as easy as poss.) > Maven artifacts are also available in the central Maven repository: > http://repo1.maven.org/maven2/org/apache/commons/ > > > Best regards, > The Apache Commons Team > > - > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
