[VALIDATOR] Ready for 1.4.1 RC3?

[Benedikt Ritter]

Hi all,

there have been some fixes in the last few days (mostly thanks to sebb) and
my feeling is, that we're ready to cut 1.4.1 RC3.
If there is something left you would like to add, then please let me know.
Otherwise I'll cut RC3 tonight or tomorrow.

Regards,
Benedikt

-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [dbcp] Preparing 2.1

[Phil Steitz]

On 1/4/15 2:15 PM, Thomas Neidhart wrote:
> On 01/04/2015 01:28 AM, Phil Steitz wrote:
>> There are just a few issues open for 2.1.  I have DBCP-424 about
>> done using the approach on the last comment on that ticket. 
>> Patches, comments or commits for DBCP-423, 427 are welcome.  One
>> other thing that would be nice to clean up for this release if
>> someone is motivated to do it is to change the tests to use @Test
>> and to improve test coverage in general.  Not a blocker for release
>> and I probably won't get to it myself before 2.1, but nice to clean
>> up if someone has the time and interest.  There are some TODOs in
>> the docs as well that would be good to get in.
> I have changed the tests to use annotations.

Thanks, Thomas!

Phil
>
> Will probably look at the mentioned issues if I have time, but do not
> rely on it.
>
> 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: [math][dbcp][pool] Apachecon NA (Austin)

[Phil Steitz]

On 1/4/15 5:58 AM, Gilles wrote:
> Hello.
>
> On Sun, 04 Jan 2015 12:09:35 +0100, Luc Maisonobe wrote:
>> Hi all,
>>
>> Le 04/01/2015 02:07, Gilles a écrit :
>>> On Fri, 02 Jan 2015 14:45:15 -0700, Phil Steitz wrote:
 I am thinking about submitting a proposal or two for Austin.  I
 could update / extend the pool/dbcp talk I did last year or try a
 [math] talk.  I would love to have company developing and / or
 presenting either of these.  Is anyone else interested in
 working on
 a talk on either of these?  Any suggestions on content?

 For [math] I have always wanted to do a high level overview
 followed
 by some real world examples.  It would be great to make the
 examples
 part a community effort.
>>>
>>> It reminded me that I had yet to improve one toy example in the
>>> "src/userguide/java/org/apache/commons/math3/userguide" section
>>> of the repository.
>>> It also occurred to me that I don't know how to compile and run
>>> the applications stored there. :(
>>> Is there a maven incantation to do so?
>>
>> No as maven does not know about this directory (and should not
>> IMHO).
>
> I think that we should have some way to
> 1. automatically compile its content (so that we can ensure that the
>source tree does not contain any non-compilable stuff) and
> 2. run selected classes (so that users easily see CM code at work)
>
> It looks like it should not be too difficult (for an experienced
> maven user, which I'm not) to create a profile for doing just that.
> [I've seen there is an "exec" plugin that could do (2), but I
> couldn't find where one can specifytan alternate source for
> compilation.]
>
>>>

 For [pool] / [dbcp] I did the boring part last year - summary of
 changes in the 2.x versions, migration, etc. - so this year I
 could
 focus on examples and best practices.  Again, a great thing to
 work
 together on.

 Another crazy idea I have had is a talk on how hard it is to
 design
 stable APIs, using [math] as an example.
>>>
>>> Is it really hard?  Isn't it rather that some developers just lack
>>> the willpower to support less than ideal APIs? :-}
>>
>> Yes, it is hard.
>
> I wanted to stress exactly what you expand below, i.e. that needs are
> changing, and that if we want to combine all the qualities of good
> code (a.o. code that evolves with the developers' community, with
> the users' community, with the language's state-of-the-art, with the
> computers' power, etc.) we have to modify the APIs; it is a never
> ending, but creative, task.
> The alternative is, as I wrote above, to stick with less-than-ideal
> APIs, and _that_ is not hard; but it is a dead end.

If you make good choices initially, it does not have to be a dead
end.  That's the challenge.  Some of our APIs have been pretty
stable.  The problem with constantly changing APIs is they become
effectively worthless for real world use.  Even for me, as a *math
developer*, I have some of my own hacked / forked / semi-patched
versions of [math] things because I don't have time to refactor and
retest all of the code that uses now compat-broken stuff.   I am not
advocating that we don't ever change APIs - just that we be
conservative in doing so so that users can count on some level of
stability.  Somehow R does this pretty well.

The last comment is what I was thinking about exploring when I said
that modeling math algorithms using OO constructs is tricky.  Maybe
they are just much smarter than us (to some extent, I am sure that
is true); but I think R also has the advantage that it is really a
pretty much procedural setup (I know, R is weirdly OO in its own
way; but the public API is really pretty flat, procedural). 

The other thing that I was thinking about in this area is basically
what the whole field of numerical analysis is about - the difference
between naive modelling of mathematical objects in the "natural" way
and what you need to do to get stable and accurate results.  Also,
the tradeoff between "correctly" handling corner cases and
extensions beyond what is well-defined mathematically and
performance.  The Complex class illustrates all of these things.
>
>>>
 That talk would also call
 out some of the special challenges that you run into modelling
 mathematical objects using OO constructs.
>>>
>>> That would be interesting.
>>> Are mathematical concepts really more special to model than other
>>> concepts?
>>
>> No, the problem is that low level reusable components intended to be
>> used by lots of different users for lots of different needs are
>> difficult to set up. You have to meet conflicting needs and the
>> developers do not know in advance how their code will be used.

That is the core problem of API design, which we all three agree is
"hard."  As mentioned above, I really think that math presents some
special challenges, mostly having to do with the fact that "natural"
representations of things sometimes lea

[VOTE][JCS] release [jcs] 2.0-beta-1 (take 3)

[Romain Manni-Bucau]

Hi

Another try with license/notice files

- here is the maven repo:
https://repository.apache.org/content/repositories/orgapachecommons-1074/
- assemblies can be found here
https://repository.apache.org/content/repositories/orgapachecommons-1074/org/apache/commons/commons-jcs-dist/2.0-beta-1/
- tag is here: 
http://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.0-beta-1/
- KEYS:  https://www.apache.org/dist/commons/KEYS
- Site staging is: http://people.apache.org/~rmannibucau/commons-jcs-2.0-beta-1/
- rat report is (not I delete LICENSE.xerox and zipcodes.txt from this
report directly cause I didn't find a way - didnt look again to be
honest - to configure apache-rat
correctly with maven site):
http://people.apache.org/~rmannibucau/commons-jcs-2.0-beta-1/rat-report.html

About last vote: I changed parent pom to include readme/license to let
jar include it - even javadoc and sources - hope it is enough.

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now or until we get
3 PMC votes.

[ ] +1 Release these artifacts
[ ] +-0 OK, but...
[ ] -1 I oppose this release because...


Here is my +1


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau

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

Re: [dbcp] Preparing 2.1

[Thomas Neidhart]

On 01/04/2015 01:28 AM, Phil Steitz wrote:
> There are just a few issues open for 2.1.  I have DBCP-424 about
> done using the approach on the last comment on that ticket. 
> Patches, comments or commits for DBCP-423, 427 are welcome.  One
> other thing that would be nice to clean up for this release if
> someone is motivated to do it is to change the tests to use @Test
> and to improve test coverage in general.  Not a blocker for release
> and I probably won't get to it myself before 2.1, but nice to clean
> up if someone has the time and interest.  There are some TODOs in
> the docs as well that would be good to get in.

I have changed the tests to use annotations.

Will probably look at the mentioned issues if I have time, but do not
rely on it.

Thomas

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

Re: [Math] Maven profile for running the examples?

[sebb]

Did you see my mail from earlier today titled as below ?

Compiling and running examples

This explains how Commons NET examples are built and used.

On 4 January 2015 at 18:21, Gilles  wrote:
> Hi.
>
> In the "src/userguide/java" directory, there are a few
> self-contained usage examples.
>
> I think that we should have some way to
> 1. automatically compile its content (so that we can ensure that the
>source tree does not contain any non-compilable stuff) and
> 2. run selected classes (so that users easily see CM code at work)
>
> It looks like it should not be too difficult (for an experienced
> maven user, which I'm not) to create a profile for doing just that.
> [I've seen there is an "exec" plugin that could do (2), but I
> didn't find where, in the "pom.xml", one can specify an alternate
> directory for indicating which sources to compile.]
>
>
> Thanks for any hint,
> 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: [Math] Maven profile for running the examples?

[Luc Maisonobe]

Le 04/01/2015 21:05, Phil Steitz a écrit :
> 
> 
> 
> 
>> On Jan 4, 2015, at 11:21 AM, Gilles  wrote:
>>
>> Hi.
>>
>> In the "src/userguide/java" directory, there are a few
>> self-contained usage examples.
>>
>> I think that we should have some way to
>> 1. automatically compile its content (so that we can ensure that the
>>   source tree does not contain any non-compilable stuff) and
>> 2. run selected classes (so that users easily see CM code at work)
>>
>> It looks like it should not be too difficult (for an experienced
>> maven user, which I'm not) to create a profile for doing just that.
>> [I've seen there is an "exec" plugin that could do (2), but I
>> didn't find where, in the "pom.xml", one can specify an alternate
>> directory for indicating which sources to compile.]
> 
> This kind of thing is pretty easy in Ant.  I would be +1 on just adding a 
> build.xml to the directory where the examples live.

It seems the tools jar is created in our pom by using
maven-antrun-plugin. It contains the PerfTestUtils class from the tests.
I don't
remember what is is for. This may be a way to do what you want.

best regards,
Luc


> 
> Phil 
>>
>>
>> Thanks for any hint,
>> 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

Jenkins build is still unstable: commons-jcs » Apache Commons JCS :: Core #73

[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 still unstable: commons-jcs #73

[Apache Jenkins Server]

See 


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

Re: [IMAGING] Constant interfaces vs. constant classes

[sebb]

+1

On 4 January 2015 at 19:15, Gary Gregory  wrote:
> +1: Interfaces should be used to define contracts, not constants. I like
> using classes to define constants.
>
> Gary
>
> On Sun, Jan 4, 2015 at 1:58 PM, Benedikt Ritter  wrote:
>
>> Hi all,
>>
>> imaging has a lot of constant interfaces and even the
>> org.apache.commons.imaging.formats.tiff.constants.AllTagConstants interface
>> which combine several interfaces.
>>
>> I'm in the "no constant interfaces" group. An interface should be used to,
>> well, define an interface. Defining interfaces only for the purpose of
>> holding constants doesn't really make sense imho. I would like to use
>> constant classes instead. Using static imports, the use of constants in the
>> code will look the same as before.
>> Further more, logic that is currently contained in the TagConstantUtils
>> class (for example mergeTagLists, can be moved to the corresponding
>> Constant class as private static method, which will also remove it from the
>> public API.
>>
>> I'd like to here what others think about this, since I expect this to be
>> partly a question of taste.
>>
>> Regards,
>> Benedikt
>>
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>>
>
>
>
> --
> 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

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

Re: [Math] Maven profile for running the examples?

[Phil Steitz]

> On Jan 4, 2015, at 11:21 AM, Gilles  wrote:
> 
> Hi.
> 
> In the "src/userguide/java" directory, there are a few
> self-contained usage examples.
> 
> I think that we should have some way to
> 1. automatically compile its content (so that we can ensure that the
>   source tree does not contain any non-compilable stuff) and
> 2. run selected classes (so that users easily see CM code at work)
> 
> It looks like it should not be too difficult (for an experienced
> maven user, which I'm not) to create a profile for doing just that.
> [I've seen there is an "exec" plugin that could do (2), but I
> didn't find where, in the "pom.xml", one can specify an alternate
> directory for indicating which sources to compile.]

This kind of thing is pretty easy in Ant.  I would be +1 on just adding a 
build.xml to the directory where the examples live.

Phil 
> 
> 
> Thanks for any hint,
> 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

[IMAGING] Interfaces vs. abstract classes without logic (Was: Re: svn commit: r1649362 - /commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/)

[Benedikt Ritter]

*bringing this to a wider audience*

Hi All,

today I've committed some changes, that should probably have been discussed
before. There were a few abstract classes in [imaging], which had no logic
at all. They just defined abstract methods.

I've changed this and replaced these abstract classes with interfaces.
Following my commits, Thomas has pointed out, that abstract classes without
logic may in some cases make sense from an "evolving API" POV.
My point here is, that a class can only extend one class, but can implement
several interfaces.

Since we're working on the 1.0 API, I would like to give others the
opportunity to chime in on this. The respective commits are:

http://svn.apache.org/r1649358
http://svn.apache.org/r1649360
http://svn.apache.org/r1649364
http://svn.apache.org/r1649366
http://svn.apache.org/r1649367
http://svn.apache.org/r1649362

Please let me know if you feel like any (or all) of this commits should
better be reverted.

Thanks!
Benedikt


2015-01-04 20:54 GMT+01:00 Thomas Neidhart :

> On 01/04/2015 08:27 PM, Benedikt Ritter wrote:
> > 2015-01-04 19:56 GMT+01:00 Thomas Neidhart :
> >
> >> On 01/04/2015 07:48 PM, Benedikt Ritter wrote:
> >>> Hello Thomas,
> >>>
> >>> 2015-01-04 18:37 GMT+01:00 Thomas Neidhart  >:
> >>>
>  On 01/04/2015 06:07 PM, brit...@apache.org wrote:
> > Author: britter
> > Date: Sun Jan  4 17:07:51 2015
> > New Revision: 1649362
> >
> > URL: http://svn.apache.org/r1649362
> > Log:
> > ScanlineFilter really is an interface
> 
>  there is usually a good reason to use an abstract class instead of an
>  interface in case the type is public.
> 
> >>>
> >>> Yes, if the abstract class has some logic, which subclasses can
> leverage.
> >>> This was not the case here.
> >>>
> >>>
> 
>  This makes it possible to extend the interface even in minor
> interfaces.
> 
> >>>
> >>> I don't understand what you mean. Can you give an example?
> >>
> >> If you define a public interface that classes implement, you can not
> >> change the interface during minor releases as this would potentially
> >> break client code.
> >>
> >> Thus there are cases where it is better to use an abstract base class
> >> instead of an interface, especially if it is highly unlikely that
> >> implementing classes will extend or implement other types.
> >>
> >> In math we have several examples of this pattern, as it is much easier
> >> to add new features considering the release policy in commons.
> >>
> >> The pattern is more or less obsolete with java 8, as there you have the
> >> possibility of default methods in interfaces, but as long as the minimum
> >> required version is < java 8 you have to keep this in mind.
> >>
> 
>  Maybe this is not necessary in this case, but should be kept in mind
>  when doing such changes.
> 
> >>>
> >>> As long as an abstract class does not define logic, it doesn't make any
> >>> sense to define it as a class, rather than as an interface. Using
> >>> interfaces has an important advantage: you can only extend one class,
> but
> >>> can implement more than one interface. So we should really only define
> >>> abstract classes, if they have logic that justifies their existence.
> >>
> >> well it depends on your use-case imho. From a clean object-oriented POV,
> >> you are totally right, but you also have to consider the maintainability
> >> aspect.
> >>
> >
> > I understand your point now. I've never thought about it this way and
> your
> > right from an "evolving API" POV. Since we're currently designing the 1.0
> > API, I'd like to leave it this way for now. Or would you rather like to
> see
> > this commit reverted?
>
> I think changes like these should at least be discussed on the ml so
> that developers who worked on it for a longer time can comment. The 1.0
> release is actually quite critical, as it will most likely remain the
> stable branch for quite some time.
>
> Thomas
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: svn commit: r1649362 - /commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/

[Thomas Neidhart]

On 01/04/2015 08:27 PM, Benedikt Ritter wrote:
> 2015-01-04 19:56 GMT+01:00 Thomas Neidhart :
> 
>> On 01/04/2015 07:48 PM, Benedikt Ritter wrote:
>>> Hello Thomas,
>>>
>>> 2015-01-04 18:37 GMT+01:00 Thomas Neidhart :
>>>
 On 01/04/2015 06:07 PM, brit...@apache.org wrote:
> Author: britter
> Date: Sun Jan  4 17:07:51 2015
> New Revision: 1649362
>
> URL: http://svn.apache.org/r1649362
> Log:
> ScanlineFilter really is an interface

 there is usually a good reason to use an abstract class instead of an
 interface in case the type is public.

>>>
>>> Yes, if the abstract class has some logic, which subclasses can leverage.
>>> This was not the case here.
>>>
>>>

 This makes it possible to extend the interface even in minor interfaces.

>>>
>>> I don't understand what you mean. Can you give an example?
>>
>> If you define a public interface that classes implement, you can not
>> change the interface during minor releases as this would potentially
>> break client code.
>>
>> Thus there are cases where it is better to use an abstract base class
>> instead of an interface, especially if it is highly unlikely that
>> implementing classes will extend or implement other types.
>>
>> In math we have several examples of this pattern, as it is much easier
>> to add new features considering the release policy in commons.
>>
>> The pattern is more or less obsolete with java 8, as there you have the
>> possibility of default methods in interfaces, but as long as the minimum
>> required version is < java 8 you have to keep this in mind.
>>

 Maybe this is not necessary in this case, but should be kept in mind
 when doing such changes.

>>>
>>> As long as an abstract class does not define logic, it doesn't make any
>>> sense to define it as a class, rather than as an interface. Using
>>> interfaces has an important advantage: you can only extend one class, but
>>> can implement more than one interface. So we should really only define
>>> abstract classes, if they have logic that justifies their existence.
>>
>> well it depends on your use-case imho. From a clean object-oriented POV,
>> you are totally right, but you also have to consider the maintainability
>> aspect.
>>
> 
> I understand your point now. I've never thought about it this way and your
> right from an "evolving API" POV. Since we're currently designing the 1.0
> API, I'd like to leave it this way for now. Or would you rather like to see
> this commit reverted?

I think changes like these should at least be discussed on the ml so
that developers who worked on it for a longer time can comment. The 1.0
release is actually quite critical, as it will most likely remain the
stable branch for quite some time.

Thomas

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

Re: svn commit: r1649362 - /commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/

[Benedikt Ritter]

2015-01-04 19:56 GMT+01:00 Thomas Neidhart :

> On 01/04/2015 07:48 PM, Benedikt Ritter wrote:
> > Hello Thomas,
> >
> > 2015-01-04 18:37 GMT+01:00 Thomas Neidhart :
> >
> >> On 01/04/2015 06:07 PM, brit...@apache.org wrote:
> >>> Author: britter
> >>> Date: Sun Jan  4 17:07:51 2015
> >>> New Revision: 1649362
> >>>
> >>> URL: http://svn.apache.org/r1649362
> >>> Log:
> >>> ScanlineFilter really is an interface
> >>
> >> there is usually a good reason to use an abstract class instead of an
> >> interface in case the type is public.
> >>
> >
> > Yes, if the abstract class has some logic, which subclasses can leverage.
> > This was not the case here.
> >
> >
> >>
> >> This makes it possible to extend the interface even in minor interfaces.
> >>
> >
> > I don't understand what you mean. Can you give an example?
>
> If you define a public interface that classes implement, you can not
> change the interface during minor releases as this would potentially
> break client code.
>
> Thus there are cases where it is better to use an abstract base class
> instead of an interface, especially if it is highly unlikely that
> implementing classes will extend or implement other types.
>
> In math we have several examples of this pattern, as it is much easier
> to add new features considering the release policy in commons.
>
> The pattern is more or less obsolete with java 8, as there you have the
> possibility of default methods in interfaces, but as long as the minimum
> required version is < java 8 you have to keep this in mind.
>
> >>
> >> Maybe this is not necessary in this case, but should be kept in mind
> >> when doing such changes.
> >>
> >
> > As long as an abstract class does not define logic, it doesn't make any
> > sense to define it as a class, rather than as an interface. Using
> > interfaces has an important advantage: you can only extend one class, but
> > can implement more than one interface. So we should really only define
> > abstract classes, if they have logic that justifies their existence.
>
> well it depends on your use-case imho. From a clean object-oriented POV,
> you are totally right, but you also have to consider the maintainability
> aspect.
>

I understand your point now. I've never thought about it this way and your
right from an "evolving API" POV. Since we're currently designing the 1.0
API, I'd like to leave it this way for now. Or would you rather like to see
this commit reverted?

Benedikt


>
> > Benedikt
> >
> > P.S.: Nice to know, that someone is reviewing my commits in [imaging] :-)
>
> Usually I am quiet but I read a lot ;-).
>
> Thomas
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: Announce: Commons Inject

[Benedikt Ritter]

2015-01-04 20:00 GMT+01:00 Mark Struberg :

> >>
> http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-atinject_1.0_spec/1.0/
> >
> > why? (just out of curiosity :-)
>
> dogfooding? :)
>
> The main reason why I always favour those geronimo-spec jar artifacts over
> their javax counterparts is that I can be 100% sure that they are IP clean
> and do have a 'nice' license. No CDDL, No LGPL, etc.
>
> With javax.inject that is of course not an issue as it is ALv2. But once
> you mix in other EE specs then you might get into license troubles (without
> noticing).
>

Thank you for the explanation. Never thought about the IP issues before.

Benedikt


>
>
> LieGrue,
> strub
>
>
>
>
>
> > On Sunday, 4 January 2015, 18:01, Benedikt Ritter 
> wrote:
> > > 2015-01-04 17:57 GMT+01:00 Mark Struberg :
> >
> >>  Hi Jochen!
> >>
> >>
> >>  The code is now indeed self-contained. I did not really look at the
> code
> >>  but like to start with just a few small observations:
> >>
> >>  1.) the repo contains the whole eclipse project files. I'd rather
> > remove
> >>  those from the repos and add them (+ idea files) to svn:ignore.
> >>
> >>  2.) javax-inject.api. I'd probably replace this via our own impl:
> >>
> >>
> >
> http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-atinject_1.0_spec/1.0/
> >
> >
> > why? (just out of curiosity :-)
> >
> >
> >>
> >>
> >>  3.) the atinject (JSR-330) TCK. I compiled the project and it only
> said it
> >>  passes 2 tests. I double checked with OpenWebBeans and over there we
> run
> >>  (and pass of course) 50 tests. Maybe there is something wrong with the
> >>  integration?
> >>
> >>  4.) the Scopes.
> >>  You currently have a Enum for this. I guess it would be pretty easy to
> >>  switch this to using scope annotations which are meta-annotated with
> @Scope
> >>  instead? And also implement the @Singleton scope based on that approach
> >>  instead of rolling your own?
> >>
> >>
> >>  Just a few ideas.
> >>
> >>
> >>  LieGrue,
> >>  strub
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>  > On Wednesday, 17 December 2014, 13:56, Jochen Wiedmann <
> >>  jochen.wiedm...@gmail.com> wrote:
> >>  > > Well spotted. I had added Guice as a Maven dependency so as to
> >>  > validate certain things while implementing. It's now removed. This
> >>  > should eliminate your concerns. Also, please note that the remaining
> >>  > dependencies are all provided, with the exception of
> >>  > javax.inject-1.jar and javax.inject-tck-1.jar, which are required for
> >>  > obvious reasons. (After all, this is the implemented standard.)
> >>  >
> >>  >
> >>  >
> >>  > On Wed, Dec 17, 2014 at 11:52 AM, Benedikt Ritter
> > 
> >>  > wrote:
> >>  >>  2014-11-19 8:44 GMT+01:00 Mark Struberg
> > :
> >>  >>>
> >>  >>>  Jochen, I might have done something wrong so please help me.
> >>  >>>
> >>  >>>  I've checked out your svn link and built it.
> >>  >>>
> >>  >>>  Then I did a
> >>  >>>
> >>  >>>  $> mvn clean -DincludeScope=runtime
> > dependency:copy-dependencies
> >>  >>>  -rw-r--r--+ 1 struberg staff4467 19. Nov 08:41
> > aopalliance-1.0.jar
> >>  >>>  -rw-r--r--+ 1 struberg staff 2228009 19. Nov 08:41
> > guava-16.0.1.jar
> >>  >>>  -rw-r--r--+ 1 struberg staff  642741 19. Nov 08:41
> > guice-4.0-beta5.jar
> >>  >>>  -rw-r--r--+ 1 struberg staff2497 19. Nov 08:41
> > javax.inject-1.jar
> >>  >>>
> >>  >>>
> >>  >>>  $> du -hs target/dependencies
> >>  >>>
> >>  >>>  show me 2.8 MB
> >>  >>>
> >>  >>>
> >>  >>>  Plus your own jar which is 76k.
> >>  >>>  Is there something wrong? What are you using guice and guava
> > for?
> >>  >>>  Also there is an own ASF package for atinject [1].
> >>  >>>
> >>  >>
> >>  >>  Jochen, can you please comment?
> >>  >>
> >>  >>  Benedikt
> >>  >>
> >>  >>
> >>  >>>
> >>  >>>  LieGrue,
> >>  >>>  strub
> >>  >>>
> >>  >>>
> >>  >>>
> >>  >>>  [1]
> >>  >>>
> >>  >
> >>
> >
> http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-atinject_1.0_spec/1.0/
> >>  >>>
> >>  >>>
> >>  >>>
> >>  >>>
> >>  >>>  On Wednesday, 19 November 2014, 8:34, Mark Struberg
> >>  > 
> >>  >>>  wrote:
> >>  >>>  >> Sorry, did not mean to step on somebody's toes.
> >>  >>>  >
> >>  >>>  >No worries you didn't. It's most probably our
> > fault as our
> >>  > (OpenWebBeans)
> >>  >>>  documentation sucks and we did not properly document all this
> > stuff ;)
> >>  >>>  >
> >>  >>>  >If one of you guys is at ApacheCon in Budapest right now,
> > then
> >>  > I'd love
> >>  >>>  to give you a quick rush through our code an see if there is
> > something
> >>  > you
> >>  >>>  could use and also if we could improve something in OWB.
> >>  >>>  >
> >>  >>>  >LieGrue,
> >>  >>>  >strub
> >>  >>>  >
> >>  >>>  >
> >>  >>>  >
> >>  >>>  >
> >>  >>>  >- Original Message -
> >>  >>>  >> From: Oliver Heger
> > 
> >>  >>>  >> To: Commons Developers List
> > 
> >>  >>>  >> Cc:
> >>  >>>  >> Sent: Sunday, 9 November 2014, 11:45
> >>  >>>  >> Subject: Re: Announce: Commons Inject
> >

Re: [IMAGING] Constant interfaces vs. constant classes

[Gary Gregory]

+1: Interfaces should be used to define contracts, not constants. I like
using classes to define constants.

Gary

On Sun, Jan 4, 2015 at 1:58 PM, Benedikt Ritter  wrote:

> Hi all,
>
> imaging has a lot of constant interfaces and even the
> org.apache.commons.imaging.formats.tiff.constants.AllTagConstants interface
> which combine several interfaces.
>
> I'm in the "no constant interfaces" group. An interface should be used to,
> well, define an interface. Defining interfaces only for the purpose of
> holding constants doesn't really make sense imho. I would like to use
> constant classes instead. Using static imports, the use of constants in the
> code will look the same as before.
> Further more, logic that is currently contained in the TagConstantUtils
> class (for example mergeTagLists, can be moved to the corresponding
> Constant class as private static method, which will also remove it from the
> public API.
>
> I'd like to here what others think about this, since I expect this to be
> partly a question of taste.
>
> Regards,
> Benedikt
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>



-- 
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: Announce: Commons Inject

[Mark Struberg]

>> http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-atinject_1.0_spec/1.0/
>
> why? (just out of curiosity :-)

dogfooding? :)

The main reason why I always favour those geronimo-spec jar artifacts over 
their javax counterparts is that I can be 100% sure that they are IP clean and 
do have a 'nice' license. No CDDL, No LGPL, etc.

With javax.inject that is of course not an issue as it is ALv2. But once you 
mix in other EE specs then you might get into license troubles (without 
noticing).


LieGrue,
strub





> On Sunday, 4 January 2015, 18:01, Benedikt Ritter  wrote:
> > 2015-01-04 17:57 GMT+01:00 Mark Struberg :
> 
>>  Hi Jochen!
>> 
>> 
>>  The code is now indeed self-contained. I did not really look at the code
>>  but like to start with just a few small observations:
>> 
>>  1.) the repo contains the whole eclipse project files. I'd rather 
> remove
>>  those from the repos and add them (+ idea files) to svn:ignore.
>> 
>>  2.) javax-inject.api. I'd probably replace this via our own impl:
>> 
>> 
> http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-atinject_1.0_spec/1.0/
> 
> 
> why? (just out of curiosity :-)
> 
> 
>> 
>> 
>>  3.) the atinject (JSR-330) TCK. I compiled the project and it only said it
>>  passes 2 tests. I double checked with OpenWebBeans and over there we run
>>  (and pass of course) 50 tests. Maybe there is something wrong with the
>>  integration?
>> 
>>  4.) the Scopes.
>>  You currently have a Enum for this. I guess it would be pretty easy to
>>  switch this to using scope annotations which are meta-annotated with @Scope
>>  instead? And also implement the @Singleton scope based on that approach
>>  instead of rolling your own?
>> 
>> 
>>  Just a few ideas.
>> 
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  > On Wednesday, 17 December 2014, 13:56, Jochen Wiedmann <
>>  jochen.wiedm...@gmail.com> wrote:
>>  > > Well spotted. I had added Guice as a Maven dependency so as to
>>  > validate certain things while implementing. It's now removed. This
>>  > should eliminate your concerns. Also, please note that the remaining
>>  > dependencies are all provided, with the exception of
>>  > javax.inject-1.jar and javax.inject-tck-1.jar, which are required for
>>  > obvious reasons. (After all, this is the implemented standard.)
>>  >
>>  >
>>  >
>>  > On Wed, Dec 17, 2014 at 11:52 AM, Benedikt Ritter 
> 
>>  > wrote:
>>  >>  2014-11-19 8:44 GMT+01:00 Mark Struberg 
> :
>>  >>>
>>  >>>  Jochen, I might have done something wrong so please help me.
>>  >>>
>>  >>>  I've checked out your svn link and built it.
>>  >>>
>>  >>>  Then I did a
>>  >>>
>>  >>>  $> mvn clean -DincludeScope=runtime 
> dependency:copy-dependencies
>>  >>>  -rw-r--r--+ 1 struberg staff4467 19. Nov 08:41 
> aopalliance-1.0.jar
>>  >>>  -rw-r--r--+ 1 struberg staff 2228009 19. Nov 08:41 
> guava-16.0.1.jar
>>  >>>  -rw-r--r--+ 1 struberg staff  642741 19. Nov 08:41 
> guice-4.0-beta5.jar
>>  >>>  -rw-r--r--+ 1 struberg staff2497 19. Nov 08:41 
> javax.inject-1.jar
>>  >>>
>>  >>>
>>  >>>  $> du -hs target/dependencies
>>  >>>
>>  >>>  show me 2.8 MB
>>  >>>
>>  >>>
>>  >>>  Plus your own jar which is 76k.
>>  >>>  Is there something wrong? What are you using guice and guava 
> for?
>>  >>>  Also there is an own ASF package for atinject [1].
>>  >>>
>>  >>
>>  >>  Jochen, can you please comment?
>>  >>
>>  >>  Benedikt
>>  >>
>>  >>
>>  >>>
>>  >>>  LieGrue,
>>  >>>  strub
>>  >>>
>>  >>>
>>  >>>
>>  >>>  [1]
>>  >>>
>>  >
>> 
> http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-atinject_1.0_spec/1.0/
>>  >>>
>>  >>>
>>  >>>
>>  >>>
>>  >>>  On Wednesday, 19 November 2014, 8:34, Mark Struberg
>>  > 
>>  >>>  wrote:
>>  >>>  >> Sorry, did not mean to step on somebody's toes.
>>  >>>  >
>>  >>>  >No worries you didn't. It's most probably our 
> fault as our
>>  > (OpenWebBeans)
>>  >>>  documentation sucks and we did not properly document all this 
> stuff ;)
>>  >>>  >
>>  >>>  >If one of you guys is at ApacheCon in Budapest right now, 
> then
>>  > I'd love
>>  >>>  to give you a quick rush through our code an see if there is 
> something
>>  > you
>>  >>>  could use and also if we could improve something in OWB.
>>  >>>  >
>>  >>>  >LieGrue,
>>  >>>  >strub
>>  >>>  >
>>  >>>  >
>>  >>>  >
>>  >>>  >
>>  >>>  >- Original Message -
>>  >>>  >> From: Oliver Heger 
> 
>>  >>>  >> To: Commons Developers List 
> 
>>  >>>  >> Cc:
>>  >>>  >> Sent: Sunday, 9 November 2014, 11:45
>>  >>>  >> Subject: Re: Announce: Commons Inject
>>  >>>  >>
>>  >>>  >>
>>  >>>  >>
>>  >>>  >> On 08.11.2014 21:51, Romain Manni-Bucau wrote:
>>  >>>  >>>  Le 8 nov. 2014 19:51, "Oliver Heger"
>>  >>>  >>  a écrit
>>  >>>  >>>  :
>>  >>>  
>>  >>>    Hi Jochen,
>>  >>>  
>>  >>>    do you intend to position this framework 
> for specific
>>  > use cases? In
>>  >>>    which way is it different or special from 
> other
>>  > implementations?
>>  >>>  
>>

[IMAGING] Constant interfaces vs. constant classes

[Benedikt Ritter]

Hi all,

imaging has a lot of constant interfaces and even the
org.apache.commons.imaging.formats.tiff.constants.AllTagConstants interface
which combine several interfaces.

I'm in the "no constant interfaces" group. An interface should be used to,
well, define an interface. Defining interfaces only for the purpose of
holding constants doesn't really make sense imho. I would like to use
constant classes instead. Using static imports, the use of constants in the
code will look the same as before.
Further more, logic that is currently contained in the TagConstantUtils
class (for example mergeTagLists, can be moved to the corresponding
Constant class as private static method, which will also remove it from the
public API.

I'd like to here what others think about this, since I expect this to be
partly a question of taste.

Regards,
Benedikt

-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: svn commit: r1649362 - /commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/

[Thomas Neidhart]

On 01/04/2015 07:48 PM, Benedikt Ritter wrote:
> Hello Thomas,
> 
> 2015-01-04 18:37 GMT+01:00 Thomas Neidhart :
> 
>> On 01/04/2015 06:07 PM, brit...@apache.org wrote:
>>> Author: britter
>>> Date: Sun Jan  4 17:07:51 2015
>>> New Revision: 1649362
>>>
>>> URL: http://svn.apache.org/r1649362
>>> Log:
>>> ScanlineFilter really is an interface
>>
>> there is usually a good reason to use an abstract class instead of an
>> interface in case the type is public.
>>
> 
> Yes, if the abstract class has some logic, which subclasses can leverage.
> This was not the case here.
> 
> 
>>
>> This makes it possible to extend the interface even in minor interfaces.
>>
> 
> I don't understand what you mean. Can you give an example?

If you define a public interface that classes implement, you can not
change the interface during minor releases as this would potentially
break client code.

Thus there are cases where it is better to use an abstract base class
instead of an interface, especially if it is highly unlikely that
implementing classes will extend or implement other types.

In math we have several examples of this pattern, as it is much easier
to add new features considering the release policy in commons.

The pattern is more or less obsolete with java 8, as there you have the
possibility of default methods in interfaces, but as long as the minimum
required version is < java 8 you have to keep this in mind.

>>
>> Maybe this is not necessary in this case, but should be kept in mind
>> when doing such changes.
>>
> 
> As long as an abstract class does not define logic, it doesn't make any
> sense to define it as a class, rather than as an interface. Using
> interfaces has an important advantage: you can only extend one class, but
> can implement more than one interface. So we should really only define
> abstract classes, if they have logic that justifies their existence.

well it depends on your use-case imho. From a clean object-oriented POV,
you are totally right, but you also have to consider the maintainability
aspect.

> Benedikt
> 
> P.S.: Nice to know, that someone is reviewing my commits in [imaging] :-)

Usually I am quiet but I read a lot ;-).

Thomas

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

Re: svn commit: r1649362 - /commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/

[Benedikt Ritter]

Hello Thomas,

2015-01-04 18:37 GMT+01:00 Thomas Neidhart :

> On 01/04/2015 06:07 PM, brit...@apache.org wrote:
> > Author: britter
> > Date: Sun Jan  4 17:07:51 2015
> > New Revision: 1649362
> >
> > URL: http://svn.apache.org/r1649362
> > Log:
> > ScanlineFilter really is an interface
>
> there is usually a good reason to use an abstract class instead of an
> interface in case the type is public.
>

Yes, if the abstract class has some logic, which subclasses can leverage.
This was not the case here.


>
> This makes it possible to extend the interface even in minor interfaces.
>

I don't understand what you mean. Can you give an example?


>
> Maybe this is not necessary in this case, but should be kept in mind
> when doing such changes.
>

As long as an abstract class does not define logic, it doesn't make any
sense to define it as a class, rather than as an interface. Using
interfaces has an important advantage: you can only extend one class, but
can implement more than one interface. So we should really only define
abstract classes, if they have logic that justifies their existence.

Benedikt

P.S.: Nice to know, that someone is reviewing my commits in [imaging] :-)


>
> Thomas
>
> > Modified:
> >
>  
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilter.java
> >
>  
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterAverage.java
> >
>  
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterNone.java
> >
>  
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterPaeth.java
> >
>  
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterSub.java
> >
>  
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterUp.java
> >
> > Modified:
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilter.java
> > URL:
> http://svn.apache.org/viewvc/commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilter.java?rev=1649362&r1=1649361&r2=1649362&view=diff
> >
> ==
> > ---
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilter.java
> (original)
> > +++
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilter.java
> Sun Jan  4 17:07:51 2015
> > @@ -20,7 +20,9 @@ import java.io.IOException;
> >
> >  import org.apache.commons.imaging.ImageReadException;
> >
> > -public abstract class ScanlineFilter {
> > -public abstract void unfilter(byte[] src, byte[] dst, byte[] up)
> > +public interface ScanlineFilter {
> > +
> > +void unfilter(byte[] src, byte[] dst, byte[] up)
> >  throws ImageReadException, IOException;
> > +
> >  }
> >
> > Modified:
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterAverage.java
> > URL:
> http://svn.apache.org/viewvc/commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterAverage.java?rev=1649362&r1=1649361&r2=1649362&view=diff
> >
> ==
> > ---
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterAverage.java
> (original)
> > +++
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterAverage.java
> Sun Jan  4 17:07:51 2015
> > @@ -20,14 +20,13 @@ import java.io.IOException;
> >
> >  import org.apache.commons.imaging.ImageReadException;
> >
> > -public class ScanlineFilterAverage extends ScanlineFilter {
> > +public class ScanlineFilterAverage implements ScanlineFilter {
> >  private final int bytesPerPixel;
> >
> >  public ScanlineFilterAverage(final int bytesPerPixel) {
> >  this.bytesPerPixel = bytesPerPixel;
> >  }
> >
> > -@Override
> >  public void unfilter(final byte[] src, final byte[] dst, final
> byte[] up)
> >  throws ImageReadException, IOException {
> >  for (int i = 0; i < src.length; i++) {
> >
> > Modified:
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterNone.java
> > URL:
> http://svn.apache.org/viewvc/commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterNone.java?rev=1649362&r1=1649361&r2=1649362&view=diff
> >
> ==
> > ---
> commons/proper/imaging/trunk

[Math] Maven profile for running the examples?

[Gilles]

Hi.

In the "src/userguide/java" directory, there are a few
self-contained usage examples.

I think that we should have some way to
1. automatically compile its content (so that we can ensure that the
   source tree does not contain any non-compilable stuff) and
2. run selected classes (so that users easily see CM code at work)

It looks like it should not be too difficult (for an experienced
maven user, which I'm not) to create a profile for doing just that.
[I've seen there is an "exec" plugin that could do (2), but I
didn't find where, in the "pom.xml", one can specify an alternate
directory for indicating which sources to compile.]


Thanks for any hint,
Gilles


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

Jenkins build became unstable: commons-jcs #72

[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 became unstable: commons-jcs » Apache Commons JCS :: Core #72

[Apache Jenkins Server]

See 



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

Re: [compress] zip64 writing seems to be broken

[Kristian Rosenvold]

Great stuff !

> getBytesWritten vs getTotalBytesWritten - svn revision 1649322
>
> Maybe we should rename getBytesWritten to something like
> getBytesWrittenForLastEntry to make the difference more obvious?

I had  hard time keeping those "written" counters correct - which you
found out :) I renamed to
getBytesWrittenForLastEntry in  r1649374.

Functionally speaking, all the maven testcases now pass with the
parallel zip algorithm.

I have been studying the performance of the gather phase for the last
days and I have a few interesting finds. Currently it manages to
gather right below 200 megabytes/s on my SSD MBP. Using various small
tweaks I seem to be able to at least double that.

Most surprising to me is that it seems like the overhead of lots of
small calls to RandomAccessFile.write seems to be a lot costlier than
I thought it would be. It seems like consolidating to a larger byte
array before calling write is a *lot* faster. So in some places where
the upper memory constraint is known (like writing the central
directory), it seems to make a lot of sense to do it in a single/a few
writes.

I'm also looking at modifications to write the full file single pass
(without seek operations for sizes), it's reasonably expensive to do
all that seeking to establish information we already have.

I'm hoping to finish all this in a few days.

Kristian

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

Re: svn commit: r1649362 - /commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/

[Thomas Neidhart]

On 01/04/2015 06:07 PM, brit...@apache.org wrote:
> Author: britter
> Date: Sun Jan  4 17:07:51 2015
> New Revision: 1649362
> 
> URL: http://svn.apache.org/r1649362
> Log:
> ScanlineFilter really is an interface

there is usually a good reason to use an abstract class instead of an
interface in case the type is public.

This makes it possible to extend the interface even in minor interfaces.

Maybe this is not necessary in this case, but should be kept in mind
when doing such changes.

Thomas

> Modified:
> 
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilter.java
> 
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterAverage.java
> 
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterNone.java
> 
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterPaeth.java
> 
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterSub.java
> 
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterUp.java
> 
> Modified: 
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilter.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilter.java?rev=1649362&r1=1649361&r2=1649362&view=diff
> ==
> --- 
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilter.java
>  (original)
> +++ 
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilter.java
>  Sun Jan  4 17:07:51 2015
> @@ -20,7 +20,9 @@ import java.io.IOException;
>  
>  import org.apache.commons.imaging.ImageReadException;
>  
> -public abstract class ScanlineFilter {
> -public abstract void unfilter(byte[] src, byte[] dst, byte[] up)
> +public interface ScanlineFilter {
> +
> +void unfilter(byte[] src, byte[] dst, byte[] up)
>  throws ImageReadException, IOException;
> +
>  }
> 
> Modified: 
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterAverage.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterAverage.java?rev=1649362&r1=1649361&r2=1649362&view=diff
> ==
> --- 
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterAverage.java
>  (original)
> +++ 
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterAverage.java
>  Sun Jan  4 17:07:51 2015
> @@ -20,14 +20,13 @@ import java.io.IOException;
>  
>  import org.apache.commons.imaging.ImageReadException;
>  
> -public class ScanlineFilterAverage extends ScanlineFilter {
> +public class ScanlineFilterAverage implements ScanlineFilter {
>  private final int bytesPerPixel;
>  
>  public ScanlineFilterAverage(final int bytesPerPixel) {
>  this.bytesPerPixel = bytesPerPixel;
>  }
>  
> -@Override
>  public void unfilter(final byte[] src, final byte[] dst, final byte[] up)
>  throws ImageReadException, IOException {
>  for (int i = 0; i < src.length; i++) {
> 
> Modified: 
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterNone.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterNone.java?rev=1649362&r1=1649361&r2=1649362&view=diff
> ==
> --- 
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterNone.java
>  (original)
> +++ 
> commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/ScanlineFilterNone.java
>  Sun Jan  4 17:07:51 2015
> @@ -20,8 +20,8 @@ import java.io.IOException;
>  
>  import org.apache.commons.imaging.ImageReadException;
>  
> -public class ScanlineFilterNone extends ScanlineFilter {
> -@Override
> +public class ScanlineFilterNone implements ScanlineFilter {
> +
>  public void unfilter(final byte[] src, final byte[] dst, final byte[] up)
>  throws ImageReadException, IOException {
>  System.arraycopy(src, 0, dst, 0, src.length);
> 
> Modified: 
> commons/proper/imaging/trunk/src/main/java/org

Re: help to setup license/notice files for JCS

[Romain Manni-Bucau]

looked weaver but it basically redefines/skips what is done in pom.
Wondered if I missed a way to not do it myself again.

I'll go this way short term but if anyone has some time to have a look
and find a shorter/better solution it is still welcomed!


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-04 17:46 GMT+01:00 Benedikt Ritter :
> Hi Romain,
>
>
> 2014-12-31 18:14 GMT+01:00 Romain Manni-Bucau :
>
>> Hi guys,
>>
>> anyone with a knowledge of [parent] pom could help me to setup
>> license/notice files in binaries/sources/javadoc jars?
>>
>> I added LICENSE.txt and NOTICE.txt in submodules but it doesnt pop up
>> in built jar. What do I miss?
>>
>
> I've tried to run mvn package to see what is happening, but the build fails
> for me with a test failure in JCS Core:
>
> Failed tests:
>
> BasicRemoteCacheClientServerUnitTest.testLocalHost:331->Assert.assertTrue:41->Assert.fail:88
> Expected localhost (192.168.2.101) to be a loopback address
>
> I don't have time to loop deeper into that. I would suggest you to have a
> looks at the [vfs] or [weaver] builds, which are multi module builds as
> well.
>
> Benedikt
>
>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter

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

Re: Announce: Commons Inject

[Benedikt Ritter]

2015-01-04 17:57 GMT+01:00 Mark Struberg :

> Hi Jochen!
>
>
> The code is now indeed self-contained. I did not really look at the code
> but like to start with just a few small observations:
>
> 1.) the repo contains the whole eclipse project files. I'd rather remove
> those from the repos and add them (+ idea files) to svn:ignore.
>
> 2.) javax-inject.api. I'd probably replace this via our own impl:
>
> http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-atinject_1.0_spec/1.0/


why? (just out of curiosity :-)


>
>
> 3.) the atinject (JSR-330) TCK. I compiled the project and it only said it
> passes 2 tests. I double checked with OpenWebBeans and over there we run
> (and pass of course) 50 tests. Maybe there is something wrong with the
> integration?
>
> 4.) the Scopes.
> You currently have a Enum for this. I guess it would be pretty easy to
> switch this to using scope annotations which are meta-annotated with @Scope
> instead? And also implement the @Singleton scope based on that approach
> instead of rolling your own?
>
>
> Just a few ideas.
>
>
> LieGrue,
> strub
>
>
>
>
>
>
>
> > On Wednesday, 17 December 2014, 13:56, Jochen Wiedmann <
> jochen.wiedm...@gmail.com> wrote:
> > > Well spotted. I had added Guice as a Maven dependency so as to
> > validate certain things while implementing. It's now removed. This
> > should eliminate your concerns. Also, please note that the remaining
> > dependencies are all provided, with the exception of
> > javax.inject-1.jar and javax.inject-tck-1.jar, which are required for
> > obvious reasons. (After all, this is the implemented standard.)
> >
> >
> >
> > On Wed, Dec 17, 2014 at 11:52 AM, Benedikt Ritter 
> > wrote:
> >>  2014-11-19 8:44 GMT+01:00 Mark Struberg :
> >>>
> >>>  Jochen, I might have done something wrong so please help me.
> >>>
> >>>  I've checked out your svn link and built it.
> >>>
> >>>  Then I did a
> >>>
> >>>  $> mvn clean -DincludeScope=runtime dependency:copy-dependencies
> >>>  -rw-r--r--+ 1 struberg staff4467 19. Nov 08:41 aopalliance-1.0.jar
> >>>  -rw-r--r--+ 1 struberg staff 2228009 19. Nov 08:41 guava-16.0.1.jar
> >>>  -rw-r--r--+ 1 struberg staff  642741 19. Nov 08:41 guice-4.0-beta5.jar
> >>>  -rw-r--r--+ 1 struberg staff2497 19. Nov 08:41 javax.inject-1.jar
> >>>
> >>>
> >>>  $> du -hs target/dependencies
> >>>
> >>>  show me 2.8 MB
> >>>
> >>>
> >>>  Plus your own jar which is 76k.
> >>>  Is there something wrong? What are you using guice and guava for?
> >>>  Also there is an own ASF package for atinject [1].
> >>>
> >>
> >>  Jochen, can you please comment?
> >>
> >>  Benedikt
> >>
> >>
> >>>
> >>>  LieGrue,
> >>>  strub
> >>>
> >>>
> >>>
> >>>  [1]
> >>>
> >
> http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-atinject_1.0_spec/1.0/
> >>>
> >>>
> >>>
> >>>
> >>>  On Wednesday, 19 November 2014, 8:34, Mark Struberg
> > 
> >>>  wrote:
> >>>  >> Sorry, did not mean to step on somebody's toes.
> >>>  >
> >>>  >No worries you didn't. It's most probably our fault as our
> > (OpenWebBeans)
> >>>  documentation sucks and we did not properly document all this stuff ;)
> >>>  >
> >>>  >If one of you guys is at ApacheCon in Budapest right now, then
> > I'd love
> >>>  to give you a quick rush through our code an see if there is something
> > you
> >>>  could use and also if we could improve something in OWB.
> >>>  >
> >>>  >LieGrue,
> >>>  >strub
> >>>  >
> >>>  >
> >>>  >
> >>>  >
> >>>  >- Original Message -
> >>>  >> From: Oliver Heger 
> >>>  >> To: Commons Developers List 
> >>>  >> Cc:
> >>>  >> Sent: Sunday, 9 November 2014, 11:45
> >>>  >> Subject: Re: Announce: Commons Inject
> >>>  >>
> >>>  >>
> >>>  >>
> >>>  >> On 08.11.2014 21:51, Romain Manni-Bucau wrote:
> >>>  >>>  Le 8 nov. 2014 19:51, "Oliver Heger"
> >>>  >>  a écrit
> >>>  >>>  :
> >>>  
> >>>    Hi Jochen,
> >>>  
> >>>    do you intend to position this framework for specific
> > use cases? In
> >>>    which way is it different or special from other
> > implementations?
> >>>  
> >>>    Just as one example: In the company I am working for,
> > we are using
> >>>  CDI
> >>>    in a pretty large JSE application. Due to the huge
> > class path the
> >>>  setup
> >>>    of the CDI container takes a long time and consumes a
> > lot of memory
> >>>    (tested with both Weld SE and OpenWebBeans). So a
> > fast and
> >>>  lightweight
> >>>    implementation for this special purpose would be
> > interesting.
> >>>  
> >>>  >>>
> >>>  >>>  Surely a bad example since you can achieve it with owb,
> > just
> >>>  configure the
> >>>  >>>  scanner service
> >>>  >>
> >>>  >> Sorry, did not mean to step on somebody's toes.
> >>>  >>
> >>>  >> Oliver
> >>>  >>
> >>>  >>>
> >>>    Oliver
> >>>  
> >>>    Am 04.11.2014 um 15:55 schrieb Jochen Wiedmann:
> >>>  >  Hi,
> >>>  >
> >>>  >  As some of you (hopefulyl not all) may have
> > noticed, have added a
> >>>  >  proj

Re: Announce: Commons Inject

[Mark Struberg]

Hi Jochen!


The code is now indeed self-contained. I did not really look at the code but 
like to start with just a few small observations:

1.) the repo contains the whole eclipse project files. I'd rather remove those 
from the repos and add them (+ idea files) to svn:ignore.

2.) javax-inject.api. I'd probably replace this via our own impl:
http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-atinject_1.0_spec/1.0/

3.) the atinject (JSR-330) TCK. I compiled the project and it only said it 
passes 2 tests. I double checked with OpenWebBeans and over there we run (and 
pass of course) 50 tests. Maybe there is something wrong with the integration?

4.) the Scopes.
You currently have a Enum for this. I guess it would be pretty easy to switch 
this to using scope annotations which are meta-annotated with @Scope instead? 
And also implement the @Singleton scope based on that approach instead of 
rolling your own?


Just a few ideas. 


LieGrue,
strub







> On Wednesday, 17 December 2014, 13:56, Jochen Wiedmann 
>  wrote:
> > Well spotted. I had added Guice as a Maven dependency so as to
> validate certain things while implementing. It's now removed. This
> should eliminate your concerns. Also, please note that the remaining
> dependencies are all provided, with the exception of
> javax.inject-1.jar and javax.inject-tck-1.jar, which are required for
> obvious reasons. (After all, this is the implemented standard.)
> 
> 
> 
> On Wed, Dec 17, 2014 at 11:52 AM, Benedikt Ritter  
> wrote:
>>  2014-11-19 8:44 GMT+01:00 Mark Struberg :
>>> 
>>>  Jochen, I might have done something wrong so please help me.
>>> 
>>>  I've checked out your svn link and built it.
>>> 
>>>  Then I did a
>>> 
>>>  $> mvn clean -DincludeScope=runtime dependency:copy-dependencies
>>>  -rw-r--r--+ 1 struberg staff4467 19. Nov 08:41 aopalliance-1.0.jar
>>>  -rw-r--r--+ 1 struberg staff 2228009 19. Nov 08:41 guava-16.0.1.jar
>>>  -rw-r--r--+ 1 struberg staff  642741 19. Nov 08:41 guice-4.0-beta5.jar
>>>  -rw-r--r--+ 1 struberg staff2497 19. Nov 08:41 javax.inject-1.jar
>>> 
>>> 
>>>  $> du -hs target/dependencies
>>> 
>>>  show me 2.8 MB
>>> 
>>> 
>>>  Plus your own jar which is 76k.
>>>  Is there something wrong? What are you using guice and guava for?
>>>  Also there is an own ASF package for atinject [1].
>>> 
>> 
>>  Jochen, can you please comment?
>> 
>>  Benedikt
>> 
>> 
>>> 
>>>  LieGrue,
>>>  strub
>>> 
>>> 
>>> 
>>>  [1]
>>> 
> http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-atinject_1.0_spec/1.0/
>>> 
>>> 
>>> 
>>> 
>>>  On Wednesday, 19 November 2014, 8:34, Mark Struberg 
> 
>>>  wrote:
>>>  >> Sorry, did not mean to step on somebody's toes.
>>>  >
>>>  >No worries you didn't. It's most probably our fault as our 
> (OpenWebBeans)
>>>  documentation sucks and we did not properly document all this stuff ;)
>>>  >
>>>  >If one of you guys is at ApacheCon in Budapest right now, then 
> I'd love
>>>  to give you a quick rush through our code an see if there is something 
> you
>>>  could use and also if we could improve something in OWB.
>>>  >
>>>  >LieGrue,
>>>  >strub
>>>  >
>>>  >
>>>  >
>>>  >
>>>  >- Original Message -
>>>  >> From: Oliver Heger 
>>>  >> To: Commons Developers List 
>>>  >> Cc:
>>>  >> Sent: Sunday, 9 November 2014, 11:45
>>>  >> Subject: Re: Announce: Commons Inject
>>>  >>
>>>  >>
>>>  >>
>>>  >> On 08.11.2014 21:51, Romain Manni-Bucau wrote:
>>>  >>>  Le 8 nov. 2014 19:51, "Oliver Heger"
>>>  >>  a écrit
>>>  >>>  :
>>>  
>>>    Hi Jochen,
>>>  
>>>    do you intend to position this framework for specific 
> use cases? In
>>>    which way is it different or special from other 
> implementations?
>>>  
>>>    Just as one example: In the company I am working for, 
> we are using
>>>  CDI
>>>    in a pretty large JSE application. Due to the huge 
> class path the
>>>  setup
>>>    of the CDI container takes a long time and consumes a 
> lot of memory
>>>    (tested with both Weld SE and OpenWebBeans). So a 
> fast and
>>>  lightweight
>>>    implementation for this special purpose would be 
> interesting.
>>>  
>>>  >>>
>>>  >>>  Surely a bad example since you can achieve it with owb, 
> just
>>>  configure the
>>>  >>>  scanner service
>>>  >>
>>>  >> Sorry, did not mean to step on somebody's toes.
>>>  >>
>>>  >> Oliver
>>>  >>
>>>  >>>
>>>    Oliver
>>>  
>>>    Am 04.11.2014 um 15:55 schrieb Jochen Wiedmann:
>>>  >  Hi,
>>>  >
>>>  >  As some of you (hopefulyl not all) may have 
> noticed, have added a
>>>  >  project called Commons Inject to the Sandbox [1] 
> today. Commons
>>>  >> Inject
>>>  >  is a JSR 330 compliant dependency injection 
> framework. It is
>>>  >> something
>>>  >  I had in the works for quite some time, but now 
> it has reached a
>>>  >  decent state with my preliminary milestones 
> reached:
>>>  >
>>>  >  - Passes the JSR 330 TCK.
>>>  > 

Re: [VALIDATOR] Working on the TLD list (Was: Re: [CANCEL][VOTE] Release Apache Commons Validator 1.4.1 based on RC2)

[Benedikt Ritter]

2015-01-03 20:26 GMT+01:00 sebb :

> I've just noticed VALIDATOR-297, which points out that the punycode
> versions of the TLDs are not regarded as valid.
>
> I just added the Unicode versions, but perhaps I should have added the
> punycode ones as well or instead?
>
> DomainVal. does not currently support Unicode path segments
> (VALIDATOR-235).
> Is there any point supporting Unicode TLDs if Unicode path segments
> don't validate?
>

No, I don't think so.


>
> In the longer term (Java 6) I think we can use just the punycode TLDs,
> because we can translate Unicode TLDs to punycode in order to check
> the domain.
>
> So the question is: do we want to fix V-235 now?
> If not, we don't need the Unicode TLDs I just added.
>

No, this one is for 1.5 I think (which we can push right after 1.4.1).


>
> If we do fix V-235, it might be worth using reflection to call the
> converter if the code happens to be running under Java 6+
> i.e. we don't need to keep the Unicode TLDs unless we want to support
> Unicode validation under Java 4 & 5 and we are going to fix V-235 now.
>

Let's not complicate the implementation if we're planning to bump the Java
version right after 1.4.1. I just want to get this last Java 1.4 compatible
release out of the dort and then update to a more recent Java version.


>
> I'll replace the Unicode entries shortly.
>

Thank you!

Benedikt


>
>
>
> On 3 January 2015 at 18:32, sebb  wrote:
> > On 3 January 2015 at 12:34, Benedikt Ritter  wrote:
> >> Hello Sebb,
> >>
> >> 2015-01-03 4:35 GMT+01:00 sebb :
> >>
> >>> I've made quite a bit of progress.
> >>>
> >>> However the IANA text file merges all the TLDs into one file - there
> >>> is no indication of whether the TLD is a country code or not.
> >>> This does not matter for ASCII codes, because they are easy to
> recognise.
> >>> Unfortunately it looks as though the only way to distinguish them is
> >>> to scan the HTML version of the file and check the Type column.
> >>> Not sure it is possible to automate this without a lot of work, so it
> >>> may take a bit longer that I had hoped.
> >>>
> >>
> >> No problem. Is there anything we can do to help you?
> >
> > Turns out that the html format is not all that hard to parse, as it
> > appears to be auto generated.
> > I have now got it working so it creates separate sorted lists of
> > missing general and cc entries with comments.
> >
> > I will commit the missing entries shortly.
> >
> > There are still a couple of issues I think it would be good to resolve:
> > 1) root, um and yu are not in the txt list. I think they should be
> > dropped (VALIDATOR-350)
> > 2) lists are now already sorted, and there are unit tests to check
> > this, so I think we could drop the static{} block (VALIDATOR-349)
> >
> > WDYT?
> >
> >> Benedikt
> >>
> >>
> >>>
> >>>
> >>> On 2 January 2015 at 14:47, Benedikt Ritter 
> wrote:
> >>> > Hi,
> >>> >
> >>> > this vote in canceled to fix the problems discovered by sebb.
> >>> > I will waint until the XN-- entries are added before I roll out a
> new RC.
> >>> >
> >>> > Thanks!
> >>> > Benedikt
> >>> >
> >>> > 2015-01-01 19:02 GMT+01:00 Benedikt Ritter :
> >>> >
> >>> >> Hi all,
> >>> >>
> >>> >> we have fixed the issues which where found in RC1 so I'd like to
> call a
> >>> >> new vote to release Apache Commons Validator based on RC2.
> >>> >>
> >>> >> Changes from RC1:
> >>> >> - [VALIDATOR-307] - isValid checks if the given address is only IPV4
> >>> >> address and not IPV6
> >>> >> - [VALIDATOR-347] - toLowerCase() method is Locale-sensitive and
> should
> >>> >> not be used
> >>> >> - [VALIDATOR-348] - Update TLD list to latest version (Version
> >>> 2014123000)
> >>> >> - [VALIDATOR-336] - CUSIPCheckDigit thinks invalid CUSIP is valid.
> >>> >> - [VALIDATOR-345] - ISINCheckDigit fails to reject invalid
> (non-numeric)
> >>> >> check digits
> >>> >> - [VALIDATOR-346] - SedolCheckDigit fails to reject invalid
> >>> (non-numeric)
> >>> >> check digits
> >>> >> - Removed STATUS.html
> >>> >> - Added README.md to binary and source distribution
> >>> >> - Fixed encoding of source files in build by setting
> commons.encoding
> >>> >> property
> >>> >> - Fixed JIRA report to contain the issues of the project
> >>> >> - Reverted dependency to commons-beanutils to 1.8.3 since this is
> the
> >>> >> latest JDK 1.4 compatible release
> >>> >> - Added JDK requirements to release notes.
> >>> >>
> >>> >> Validator 1.4.1-RC2 is available for review here:
> >>> >>   https://dist.apache.org/repos/dist/dev/commons/validator/ (svn
> >>> revision
> >>> >> 7629)
> >>> >>
> >>> >> The tag is here:
> >>> >>
> >>> >>
> >>>
> http://svn.apache.org/repos/asf/commons/proper/validator/tags/VALIDATOR_1_4_1_RC2/
> >>> >> (svn revision 164)
> >>> >>
> >>> >> Maven artifacts are here:
> >>> >>
> >>> >>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1073/commons-validator/commons-validator/1.4.1/
> >>> >>
> >>> >> Details of changes since 1.4 are in the release 

Re: [VALIDATOR] Working on the TLD list (Was: Re: [CANCEL][VOTE] Release Apache Commons Validator 1.4.1 based on RC2)

[Benedikt Ritter]

2015-01-03 19:32 GMT+01:00 sebb :

> On 3 January 2015 at 12:34, Benedikt Ritter  wrote:
> > Hello Sebb,
> >
> > 2015-01-03 4:35 GMT+01:00 sebb :
> >
> >> I've made quite a bit of progress.
> >>
> >> However the IANA text file merges all the TLDs into one file - there
> >> is no indication of whether the TLD is a country code or not.
> >> This does not matter for ASCII codes, because they are easy to
> recognise.
> >> Unfortunately it looks as though the only way to distinguish them is
> >> to scan the HTML version of the file and check the Type column.
> >> Not sure it is possible to automate this without a lot of work, so it
> >> may take a bit longer that I had hoped.
> >>
> >
> > No problem. Is there anything we can do to help you?
>
> Turns out that the html format is not all that hard to parse, as it
> appears to be auto generated.
> I have now got it working so it creates separate sorted lists of
> missing general and cc entries with comments.
>
> I will commit the missing entries shortly.
>
> There are still a couple of issues I think it would be good to resolve:
> 1) root, um and yu are not in the txt list. I think they should be
> dropped (VALIDATOR-350)
>

Agreed


> 2) lists are now already sorted, and there are unit tests to check
> this, so I think we could drop the static{} block (VALIDATOR-349)
>

If they are sorted, yes we can drop the static block.


>
> WDYT?
>
> > Benedikt
> >
> >
> >>
> >>
> >> On 2 January 2015 at 14:47, Benedikt Ritter  wrote:
> >> > Hi,
> >> >
> >> > this vote in canceled to fix the problems discovered by sebb.
> >> > I will waint until the XN-- entries are added before I roll out a new
> RC.
> >> >
> >> > Thanks!
> >> > Benedikt
> >> >
> >> > 2015-01-01 19:02 GMT+01:00 Benedikt Ritter :
> >> >
> >> >> Hi all,
> >> >>
> >> >> we have fixed the issues which where found in RC1 so I'd like to
> call a
> >> >> new vote to release Apache Commons Validator based on RC2.
> >> >>
> >> >> Changes from RC1:
> >> >> - [VALIDATOR-307] - isValid checks if the given address is only IPV4
> >> >> address and not IPV6
> >> >> - [VALIDATOR-347] - toLowerCase() method is Locale-sensitive and
> should
> >> >> not be used
> >> >> - [VALIDATOR-348] - Update TLD list to latest version (Version
> >> 2014123000)
> >> >> - [VALIDATOR-336] - CUSIPCheckDigit thinks invalid CUSIP is valid.
> >> >> - [VALIDATOR-345] - ISINCheckDigit fails to reject invalid
> (non-numeric)
> >> >> check digits
> >> >> - [VALIDATOR-346] - SedolCheckDigit fails to reject invalid
> >> (non-numeric)
> >> >> check digits
> >> >> - Removed STATUS.html
> >> >> - Added README.md to binary and source distribution
> >> >> - Fixed encoding of source files in build by setting commons.encoding
> >> >> property
> >> >> - Fixed JIRA report to contain the issues of the project
> >> >> - Reverted dependency to commons-beanutils to 1.8.3 since this is the
> >> >> latest JDK 1.4 compatible release
> >> >> - Added JDK requirements to release notes.
> >> >>
> >> >> Validator 1.4.1-RC2 is available for review here:
> >> >>   https://dist.apache.org/repos/dist/dev/commons/validator/ (svn
> >> revision
> >> >> 7629)
> >> >>
> >> >> The tag is here:
> >> >>
> >> >>
> >>
> http://svn.apache.org/repos/asf/commons/proper/validator/tags/VALIDATOR_1_4_1_RC2/
> >> >> (svn revision 164)
> >> >>
> >> >> Maven artifacts are here:
> >> >>
> >> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1073/commons-validator/commons-validator/1.4.1/
> >> >>
> >> >> Details of changes since 1.4 are in the release notes:
> >> >>
> >> >>
> >>
> https://dist.apache.org/repos/dist/dev/commons/validator/RELEASE-NOTES.txt
> >> >>
> >> >> I have tested this with JDK 1.6, 1.7 and 1.8 using maven 3.2.5.
> >> >>
> >> >> Site (some links my be broken but will be fixed when the site is
> >> deployed):
> >> >>   http://people.apache.org/~britter/validator-1.4.1-RC2/
> >> >>
> >> >> Clirr Report:
> >> >>
> >> http://people.apache.org/~britter/validator-1.4.1-RC2/clirr-report.html
> >> >>
> >> >> RAT Report:
> >> >>
> http://people.apache.org/~britter/validator-1.4.1-RC2/rat-report.html
> >> >>
> >> >> Keys:
> >> >>   https://www.apache.org/dist/commons/KEYS
> >> >>
> >> >> Please review this release candidate and vote.
> >> >> This vote will close no sooner than 72 hours from now, i.e. after
> >> >> 2015/01/04 19:00CET
> >> >>
> >> >> [ ] +1 Release these artifacts
> >> >> [ ] +0 OK, but...
> >> >> [ ] -0 OK, but really should fix...
> >> >> [ ] -1 I oppose this release because...
> >> >>
> >> >> Thanks!
> >> >> Benedikt
> >> >>
> >> >>
> >> >> --
> >> >> http://people.apache.org/~britter/
> >> >> http://www.systemoutprintln.de/
> >> >> http://twitter.com/BenediktRitter
> >> >> http://github.com/britter
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > http://people.apache.org/~britter/
> >> > http://www.systemoutprintln.de/
> >> > http://twitter.com/BenediktRitter
> >> > http://github.com/britter
> >>
> >> -

Re: help to setup license/notice files for JCS

[Benedikt Ritter]

Hi Romain,


2014-12-31 18:14 GMT+01:00 Romain Manni-Bucau :

> Hi guys,
>
> anyone with a knowledge of [parent] pom could help me to setup
> license/notice files in binaries/sources/javadoc jars?
>
> I added LICENSE.txt and NOTICE.txt in submodules but it doesnt pop up
> in built jar. What do I miss?
>

I've tried to run mvn package to see what is happening, but the build fails
for me with a test failure in JCS Core:

Failed tests:

BasicRemoteCacheClientServerUnitTest.testLocalHost:331->Assert.assertTrue:41->Assert.fail:88
Expected localhost (192.168.2.101) to be a loopback address

I don't have time to loop deeper into that. I would suggest you to have a
looks at the [vfs] or [weaver] builds, which are multi module builds as
well.

Benedikt


>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Compiling and running examples [was [math][dbcp][pool] Apachecon NA (Austin))

[sebb]

On 4 January 2015 at 12:58, Gilles  wrote:
> Hello.
>
> On Sun, 04 Jan 2015 12:09:35 +0100, Luc Maisonobe wrote:
>>
>> Hi all,
>>
>> Le 04/01/2015 02:07, Gilles a écrit :
>>>
>>>
>>> It reminded me that I had yet to improve one toy example in the
>>> "src/userguide/java/org/apache/commons/math3/userguide" section
>>> of the repository.
>>> It also occurred to me that I don't know how to compile and run
>>> the applications stored there. :(
>>> Is there a maven incantation to do so?
>>
>>
>> No as maven does not know about this directory (and should not IMHO).
>
>
> I think that we should have some way to
> 1. automatically compile its content (so that we can ensure that the
>source tree does not contain any non-compilable stuff) and
> 2. run selected classes (so that users easily see CM code at work)
>
> It looks like it should not be too difficult (for an experienced
> maven user, which I'm not) to create a profile for doing just that.
> [I've seen there is an "exec" plugin that could do (2), but I
> couldn't find where one can specifytan alternate source for
> compilation.]

Commons NET has an examples/ tree which is compiled and released as a
separate bundle.

Note that this is under src/main/java, not under the userguide, but it
should be relatively easy to maintain the examples there and copy to
(or link from) the userguide.

The NET examples jar has a feature you might find useful.
It defines the Main-Class and the Class-Path.

This means it can be invoked using

java -jar commons-net-examples.jar ExampleName parameters.

This assumes that the user has put the examples and main net jars in
the same directory.

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

Re: [compress] zip64 writing seems to be broken

[Stefan Bodewig]

On 2015-01-04, Stefan Bodewig wrote:

> I'm just running all ITs again to be sure.

Tests run: 79, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
1,400.308 sec - in
org.apache.commons.compress.archivers.zip.Zip64SupportIT

Stefan

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

Re: [math][dbcp][pool] Apachecon NA (Austin)

[Gilles]

Hello.

On Sun, 04 Jan 2015 12:09:35 +0100, Luc Maisonobe wrote:

Hi all,

Le 04/01/2015 02:07, Gilles a écrit :

On Fri, 02 Jan 2015 14:45:15 -0700, Phil Steitz wrote:

I am thinking about submitting a proposal or two for Austin.  I
could update / extend the pool/dbcp talk I did last year or try a
[math] talk.  I would love to have company developing and / or
presenting either of these.  Is anyone else interested in working 
on

a talk on either of these?  Any suggestions on content?

For [math] I have always wanted to do a high level overview 
followed
by some real world examples.  It would be great to make the 
examples

part a community effort.


It reminded me that I had yet to improve one toy example in the
"src/userguide/java/org/apache/commons/math3/userguide" section
of the repository.
It also occurred to me that I don't know how to compile and run
the applications stored there. :(
Is there a maven incantation to do so?


No as maven does not know about this directory (and should not IMHO).


I think that we should have some way to
1. automatically compile its content (so that we can ensure that the
   source tree does not contain any non-compilable stuff) and
2. run selected classes (so that users easily see CM code at work)

It looks like it should not be too difficult (for an experienced
maven user, which I'm not) to create a profile for doing just that.
[I've seen there is an "exec" plugin that could do (2), but I
couldn't find where one can specifytan alternate source for
compilation.]





For [pool] / [dbcp] I did the boring part last year - summary of
changes in the 2.x versions, migration, etc. - so this year I could
focus on examples and best practices.  Again, a great thing to work
together on.

Another crazy idea I have had is a talk on how hard it is to design
stable APIs, using [math] as an example.


Is it really hard?  Isn't it rather that some developers just lack
the willpower to support less than ideal APIs? :-}


Yes, it is hard.


I wanted to stress exactly what you expand below, i.e. that needs are
changing, and that if we want to combine all the qualities of good
code (a.o. code that evolves with the developers' community, with
the users' community, with the language's state-of-the-art, with the
computers' power, etc.) we have to modify the APIs; it is a never
ending, but creative, task.
The alternative is, as I wrote above, to stick with less-than-ideal
APIs, and _that_ is not hard; but it is a dead end.




That talk would also call
out some of the special challenges that you run into modelling
mathematical objects using OO constructs.


That would be interesting.
Are mathematical concepts really more special to model than other
concepts?


No, the problem is that low level reusable components intended to be
used by lots of different users for lots of different needs are
difficult to set up. You have to meet conflicting needs and the
developers do not know in advance how their code will be used.


That's what I wrote below: "trying to implement generic algorithms
to solve as many practical problems as possible".
Thus: it is good to have generic, reusable, code (e.g. just from a
maintenance POV), but it at some point, it will conflict with
unexpected usage. Hence API change will be in order.


In many cases, things start with "someone scratching an itch" because
open-source developers are the first users of their stuff. The 
resulting

API is biased towards this first need. Low level reusable components
developers have to make lots of efforts to design something clean
enough to anticipate other uses. Even experienced low level reusable
components developers don't succeed in this part.


I totally and did not say otherwise.
The wrong way would be to have duplicate code all over the place to
tak care of each new usage. Since we try to avoid that, we'll need
to refactor when the "genericity" in one direction conflicts with
unanticipated usage.




I rather think that the issues arise from trying to sort out the
general from the particular, trying to implement generic algorithms
to solve as many practical problems as possible.


Perhaps, but it is really an important need for reusable components.


From a development POV, I thinks so too.
For black-box users, it is not. [They don't care about what's in the
box as long as it does the job; and "no duplicate code" is, for
instance, not a requirement.  But this a short-term view, since
maintenance will suffer and loss of quality will ensue.]


Another problem is that not moving forward (typically still staying
in the 3.X series instead of starting 4.0) creates additional
constraints. Trying to patch something wrong is much more difficult
than rewriting it, and sometimes it is even completely impossible if
wrong design choices cannot be changed.


+1


This quite naturally lead to desing decisions that may be challenged
by the appearance of unforeseen cases (or better programming 
skills).


Exactly. However, I prefer to say that h

Re: [compress] zip64 writing seems to be broken

[Stefan Bodewig]

On 2015-01-04, Kristian Rosenvold wrote:

> Not entirely unsurprisingly this broken in r1648585. I'll try to
> understand it tonight

getBytesWritten vs getTotalBytesWritten - svn revision 1649322

Maybe we should rename getBytesWritten to something like
getBytesWrittenForLastEntry to make the difference more obvious?

I'm just running all ITs again to be sure.

Stefan

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

Re: [compress] zip64 writing seems to be broken

[Stefan Bodewig]

On 2015-01-04, Kristian Rosenvold wrote:

> Not entirely unsurprisingly this broken in r1648585. I'll try to
> understand it tonight

I might find time before that, not sure, but I'll have a look myself as
well.

It might be a good idea to run the zip and tar ITs in some continuous
build environment, the problem is they'd take about an hour and
temporarily create files of up to 8GB on disk.

Stefan

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

Re: [compress] zip64 writing seems to be broken

[Stefan Bodewig]

On 2015-01-04, Stefan Bodewig wrote:

> I'll leave my box alone to run the whole suite of ZIP64 ITs (i.e. enable
> the run-zipit profile) and report back later.

Failed tests:
  Zip64SupportIT.write100KFilesFile:305->withTemporaryArchive:2342
  arrays first differed at element [8]; expected:<52> but was:<122>
Zip64SupportIT.write100KFilesFileModeAlways:313->withTemporaryArchive:2342
  arrays first differed at element [8]; expected:<52> but was:<-6>
Zip64SupportIT.write100KFilesStream:309->withTemporaryArchive:2342
  arrays first differed at element [8]; expected:<52> but was:<122>
Zip64SupportIT.write100KFilesStreamModeAlways:318->withTemporaryArchive:2342
  arrays first differed at element [8]; expected:<52> but was:<-6>

Tests in error:
  
Zip64SupportIT.writeAndRead5GBOfZerosUsingZipFile:137->read5GBOfZerosUsingZipFileImpl:2450
  » Zip


Tests run: 79, Failures: 4, Errors: 1, Skipped: 2

and the two skipped tests have been skipped because of

Failed to write archive because of: archive's ZIP64 end of central
directory locator is corrupt. - likely not enough disk space.
Failed to write archive because of: archive's ZIP64 end of central
directory locator is corrupt. - likely not enough disk space.

so are actually failures, the tests are
read3EntriesCreatingBigArchiveFileUsingZipFile and
readSelfGenerated100KFilesUsingZipFile

Stefan

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

Re: [math][dbcp][pool] Apachecon NA (Austin)

[Luc Maisonobe]

Hi all,

Le 04/01/2015 02:07, Gilles a écrit :
> On Fri, 02 Jan 2015 14:45:15 -0700, Phil Steitz wrote:
>> I am thinking about submitting a proposal or two for Austin.  I
>> could update / extend the pool/dbcp talk I did last year or try a
>> [math] talk.  I would love to have company developing and / or
>> presenting either of these.  Is anyone else interested in working on
>> a talk on either of these?  Any suggestions on content?
>>
>> For [math] I have always wanted to do a high level overview followed
>> by some real world examples.  It would be great to make the examples
>> part a community effort.
> 
> It reminded me that I had yet to improve one toy example in the
> "src/userguide/java/org/apache/commons/math3/userguide" section
> of the repository.
> It also occurred to me that I don't know how to compile and run
> the applications stored there. :(
> Is there a maven incantation to do so?

No as maven does not know about this directory (and should not IMHO).

> 
>>
>> For [pool] / [dbcp] I did the boring part last year - summary of
>> changes in the 2.x versions, migration, etc. - so this year I could
>> focus on examples and best practices.  Again, a great thing to work
>> together on.
>>
>> Another crazy idea I have had is a talk on how hard it is to design
>> stable APIs, using [math] as an example.
> 
> Is it really hard?  Isn't it rather that some developers just lack
> the willpower to support less than ideal APIs? :-}

Yes, it is hard.

> 
>> That talk would also call
>> out some of the special challenges that you run into modelling
>> mathematical objects using OO constructs.
> 
> That would be interesting.
> Are mathematical concepts really more special to model than other
> concepts?

No, the problem is that low level reusable components intended to be
used by lots of different users for lots of different needs are
difficult to set up. You have to meet conflicting needs and the
developers do not know in advance how their code will be used.

In many cases, things start with "someone scratching an itch" because
open-source developers are the first users of their stuff. The resulting
API is biased towards this first need. Low level reusable components
developers have to make lots of efforts to design something clean
enough to anticipate other uses. Even experienced low level reusable
components developers don't succeed in this part.

> I rather think that the issues arise from trying to sort out the
> general from the particular, trying to implement generic algorithms
> to solve as many practical problems as possible.

Perhaps, but it is really an important need for reusable components.

Another problem is that not moving forward (typically still staying
in the 3.X series instead of starting 4.0) creates additional
constraints. Trying to patch something wrong is much more difficult
than rewriting it, and sometimes it is even completely impossible if
wrong design choices cannot be changed.

> This quite naturally lead to desing decisions that may be challenged
> by the appearance of unforeseen cases (or better programming skills).

Exactly. However, I prefer to say that here is the problem, and it is
a challenge we have to consider rather than saying it is something we
don't want to cope with so we ignore the problem and don't care about
users apart from our own needs.

> 
>> Might be a little painful
>> to develop, but also maybe a little cathartic ;)
> 
> It would certainly be useful to understand where the pain really
> comes from.

There is an old joke I have heard numerous times in different
activities (including outside of software development): remove
the user and everything gets way better.

best regards,
Luc

> 
> 
> 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: [compress] zip64 writing seems to be broken

[Kristian Rosenvold]

Not entirely unsurprisingly this broken in r1648585. I'll try to
understand it tonight

Kristia


2015-01-04 11:37 GMT+01:00 Stefan Bodewig :
> On 2015-01-04, Stefan Bodewig wrote:
>
>> I'll try to reproduce this as a unit test for compress later today,
>
> svn revision 1649312 - run via
>
> $ mvn test -Dtest=Zip64SupportIT#writeAndRead5GBOfZerosUsingZipFile
>
> I'll leave my box alone to run the whole suite of ZIP64 ITs (i.e. enable
> the run-zipit profile) and report back later.
>
> 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] zip64 writing seems to be broken

[Stefan Bodewig]

On 2015-01-04, Stefan Bodewig wrote:

> I'll try to reproduce this as a unit test for compress later today,

svn revision 1649312 - run via

$ mvn test -Dtest=Zip64SupportIT#writeAndRead5GBOfZerosUsingZipFile

I'll leave my box alone to run the whole suite of ZIP64 ITs (i.e. enable
the run-zipit profile) and report back later.

Stefan

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