Re: [VOTE] Release of commons-email-1.3 based on RC5

[Thomas Neidhart]

On Wed, Dec 12, 2012 at 4:58 AM, Gary Gregory wrote:

> Thank you for doing another RC.
>
> While I was digging for a justification of the Clirr errors, I found this
> in the release notes: "Clirr reports several errors for this release due to
> moving constants from the Email class to the newly introduced
> EmailConstants interface. These changes are guaranteed to be binary
> compatible."
>
> Is it really binary compatible? What if I use reflection to access the
> constant on Email, will the reflection call be redirected to
> EmailConstants? There's unit test for ya ;)
>
> Using an interface to define constants is a no-no in my book. I've seen
> this discussed before in other places and for a long time, but to
> summarize, I see an interface as defining a contract for a class to
> implement. A constant does not fit.
>
> Constants in interface feels like a hack to provide the short hand of a
> class implementing an interface just to be able to access the constants
> without qualifying them with a type. Not nice design IMO and a dubious us
> of an interface, very Java 1.0. It seems that static imports is another
> attempt to solve this desire for a short hand to use constants.
>
> What to do? Move the constants back to their 1.2? What's so bad about that?
> Hm...
>
> Make the EmailConstants a class instead of an interface? If binary
> compatible is broken, the constants have to move back, and you can still
> have a new EmailConstants class and deprecate the old constants to point to
> the new class.
>
> Maybe I'll see this more clearly in the AM...
>
> Interested in you all's feedback.
>

Hi Gary,

well, I think we go in circles with this change ;-).

I assumed that this topic is settled after reading the comment from sebb in
the RC2 thread (see http://markmail.org/message/svrb7nf3ocz7lgmd).

Otoh, it's the first time I see constants in an interface and would be in
favor of reverting to the previous version (also because I do not fully
understand the rationale behind the change, some of the constants are not
even used and thus have been deprecated).

Maybe we should postpone this kind of refactoring to 2.0 and do it then in
a proper way. Introducing this interface just created headaches and I also
had to disable some checks (e.g. InterfaceIsAType in checkstyle) because of
it.

Thomas


> On Tue, Dec 11, 2012 at 5:24 PM, Thomas Neidhart
> wrote:
>
> > Hi,
> >
> > I would like to call a vote from commons-email-1.3 based on RC5.
> >
> > This release candidate has the following changes compared to RC4
> >
> > +) update index and building page with correct information wrt Java
> >compatibility
> > +) update release notes with info on Java compatibility and Clirr errors
> > +) fix svn:keywords for all source files and remove use of $Date$ tags
> > +) add $Id$ tags for all newly introduced source files in 1.3
> > +) update javax.mail.mail dependency to 1.4.5
> > +) fix PMD warnings and add NOPMD comment for false positives
> > +) added findbugs exclude filter for false positives
> > +) fix release date in changes.xml
> > +) correctly removed *.asc.[md5,sha1] files from Nexus staging area
> >
> > The files:
> >
> > The artifacts are deployed to Nexus:
> > https://repository.apache.org/content/repositories/orgapachecommons-137/
> >
> > The tag:
> >
> https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_RC5/
> >
> > The site:
> > http://people.apache.org/builds/commons/email/1.3/RC5/
> >
> > Additional Notes:
> >
> > o the download page and api links to older releases only work on
> >   the published site and will be corrected after release.
> >
> > Please take a look at the commons-email-1.3 artifacts and vote!
> >
> > 
> > [ ] +1 release it
> > [ ] +0 go ahead I don't care
> > [ ] -1 no, do not release it because
> > 
> >
> > Vote will remain open for at least 72 hours.
> >
> > Thanks in advance,
> >
> > Thomas
> >
> > -
> > 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
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Re: [VOTE] Release of commons-email-1.3 based on RC5

[Gary Gregory]

On Wed, Dec 12, 2012 at 3:59 AM, Thomas Neidhart
wrote:

> On Wed, Dec 12, 2012 at 4:58 AM, Gary Gregory  >wrote:
>
> > Thank you for doing another RC.
> >
> > While I was digging for a justification of the Clirr errors, I found this
> > in the release notes: "Clirr reports several errors for this release due
> to
> > moving constants from the Email class to the newly introduced
> > EmailConstants interface. These changes are guaranteed to be binary
> > compatible."
> >
> > Is it really binary compatible? What if I use reflection to access the
> > constant on Email, will the reflection call be redirected to
> > EmailConstants? There's unit test for ya ;)
> >
> > Using an interface to define constants is a no-no in my book. I've seen
> > this discussed before in other places and for a long time, but to
> > summarize, I see an interface as defining a contract for a class to
> > implement. A constant does not fit.
> >
> > Constants in interface feels like a hack to provide the short hand of a
> > class implementing an interface just to be able to access the constants
> > without qualifying them with a type. Not nice design IMO and a dubious us
> > of an interface, very Java 1.0. It seems that static imports is another
> > attempt to solve this desire for a short hand to use constants.
> >
> > What to do? Move the constants back to their 1.2? What's so bad about
> that?
> > Hm...
> >
> > Make the EmailConstants a class instead of an interface? If binary
> > compatible is broken, the constants have to move back, and you can still
> > have a new EmailConstants class and deprecate the old constants to point
> to
> > the new class.
> >
> > Maybe I'll see this more clearly in the AM...
> >
> > Interested in you all's feedback.
> >
>
> Hi Gary,
>
> well, I think we go in circles with this change ;-).
>
> I assumed that this topic is settled after reading the comment from sebb in
> the RC2 thread (see http://markmail.org/message/svrb7nf3ocz7lgmd).
>
> Otoh, it's the first time I see constants in an interface and would be in
> favor of reverting to the previous version (also because I do not fully
> understand the rationale behind the change, some of the constants are not
> even used and thus have been deprecated).
>
-- 

>
> Maybe we should postpone this kind of refactoring to 2.0 and do it then in
> a proper way. Introducing this interface just created headaches and I also
> had to disable some checks (e.g. InterfaceIsAType in checkstyle) because of
> it.
>

That sounds like a good way to go to get 1.3 out the door.

Gary


>
> Thomas
>
>
> > On Tue, Dec 11, 2012 at 5:24 PM, Thomas Neidhart
> > wrote:
> >
> > > Hi,
> > >
> > > I would like to call a vote from commons-email-1.3 based on RC5.
> > >
> > > This release candidate has the following changes compared to RC4
> > >
> > > +) update index and building page with correct information wrt Java
> > >compatibility
> > > +) update release notes with info on Java compatibility and Clirr
> errors
> > > +) fix svn:keywords for all source files and remove use of $Date$ tags
> > > +) add $Id$ tags for all newly introduced source files in 1.3
> > > +) update javax.mail.mail dependency to 1.4.5
> > > +) fix PMD warnings and add NOPMD comment for false positives
> > > +) added findbugs exclude filter for false positives
> > > +) fix release date in changes.xml
> > > +) correctly removed *.asc.[md5,sha1] files from Nexus staging area
> > >
> > > The files:
> > >
> > > The artifacts are deployed to Nexus:
> > >
> https://repository.apache.org/content/repositories/orgapachecommons-137/
> > >
> > > The tag:
> > >
> >
> https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_RC5/
> > >
> > > The site:
> > > http://people.apache.org/builds/commons/email/1.3/RC5/
> > >
> > > Additional Notes:
> > >
> > > o the download page and api links to older releases only work on
> > >   the published site and will be corrected after release.
> > >
> > > Please take a look at the commons-email-1.3 artifacts and vote!
> > >
> > > 
> > > [ ] +1 release it
> > > [ ] +0 go ahead I don't care
> > > [ ] -1 no, do not release it because
> > > 
> > >
> > > Vote will remain open for at least 72 hours.
> > >
> > > Thanks in advance,
> > >
> > > Thomas
> > >
> > > -
> > > 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
> > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> > Spring Batch in Action: http://bit.ly/bqpbCK
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed:

Re: [VOTE] Release of commons-email-1.3 based on RC5

[sebb]

On 12 December 2012 03:58, Gary Gregory  wrote:
> Thank you for doing another RC.
>
> While I was digging for a justification of the Clirr errors, I found this
> in the release notes: "Clirr reports several errors for this release due to
> moving constants from the Email class to the newly introduced
> EmailConstants interface. These changes are guaranteed to be binary
> compatible."
>
> Is it really binary compatible? What if I use reflection to access the
> constant on Email, will the reflection call be redirected to
> EmailConstants? There's unit test for ya ;)

AFAICT, constants in interfaces become part of the implementing class.

That's one reason why they are not a good idea ...

> Using an interface to define constants is a no-no in my book. I've seen
> this discussed before in other places and for a long time, but to
> summarize, I see an interface as defining a contract for a class to
> implement. A constant does not fit.
>
> Constants in interface feels like a hack to provide the short hand of a
> class implementing an interface just to be able to access the constants
> without qualifying them with a type. Not nice design IMO and a dubious us
> of an interface, very Java 1.0. It seems that static imports is another
> attempt to solve this desire for a short hand to use constants.
>
> What to do? Move the constants back to their 1.2? What's so bad about that?
> Hm...
>
> Make the EmailConstants a class instead of an interface? If binary
> compatible is broken, the constants have to move back, and you can still
> have a new EmailConstants class and deprecate the old constants to point to
> the new class.
>
> Maybe I'll see this more clearly in the AM...
>
> Interested in you all's feedback.
>
> Gary
>
>
> On Tue, Dec 11, 2012 at 5:24 PM, Thomas Neidhart
> wrote:
>
>> Hi,
>>
>> I would like to call a vote from commons-email-1.3 based on RC5.
>>
>> This release candidate has the following changes compared to RC4
>>
>> +) update index and building page with correct information wrt Java
>>compatibility
>> +) update release notes with info on Java compatibility and Clirr errors
>> +) fix svn:keywords for all source files and remove use of $Date$ tags
>> +) add $Id$ tags for all newly introduced source files in 1.3
>> +) update javax.mail.mail dependency to 1.4.5
>> +) fix PMD warnings and add NOPMD comment for false positives
>> +) added findbugs exclude filter for false positives
>> +) fix release date in changes.xml
>> +) correctly removed *.asc.[md5,sha1] files from Nexus staging area
>>
>> The files:
>>
>> The artifacts are deployed to Nexus:
>> https://repository.apache.org/content/repositories/orgapachecommons-137/
>>
>> The tag:
>> https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_RC5/
>>
>> The site:
>> http://people.apache.org/builds/commons/email/1.3/RC5/
>>
>> Additional Notes:
>>
>> o the download page and api links to older releases only work on
>>   the published site and will be corrected after release.
>>
>> Please take a look at the commons-email-1.3 artifacts and vote!
>>
>> 
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because
>> 
>>
>> Vote will remain open for at least 72 hours.
>>
>> Thanks in advance,
>>
>> Thomas
>>
>> -
>> 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
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> 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: [VOTE] Release of commons-email-1.3 based on RC5

[sebb]

On 12 December 2012 13:17, Gary Gregory  wrote:
> On Wed, Dec 12, 2012 at 3:59 AM, Thomas Neidhart
> wrote:
>
>> On Wed, Dec 12, 2012 at 4:58 AM, Gary Gregory > >wrote:
>>
>> > Thank you for doing another RC.
>> >
>> > While I was digging for a justification of the Clirr errors, I found this
>> > in the release notes: "Clirr reports several errors for this release due
>> to
>> > moving constants from the Email class to the newly introduced
>> > EmailConstants interface. These changes are guaranteed to be binary
>> > compatible."
>> >
>> > Is it really binary compatible? What if I use reflection to access the
>> > constant on Email, will the reflection call be redirected to
>> > EmailConstants? There's unit test for ya ;)
>> >
>> > Using an interface to define constants is a no-no in my book. I've seen
>> > this discussed before in other places and for a long time, but to
>> > summarize, I see an interface as defining a contract for a class to
>> > implement. A constant does not fit.
>> >
>> > Constants in interface feels like a hack to provide the short hand of a
>> > class implementing an interface just to be able to access the constants
>> > without qualifying them with a type. Not nice design IMO and a dubious us
>> > of an interface, very Java 1.0. It seems that static imports is another
>> > attempt to solve this desire for a short hand to use constants.
>> >
>> > What to do? Move the constants back to their 1.2? What's so bad about
>> that?
>> > Hm...
>> >
>> > Make the EmailConstants a class instead of an interface? If binary
>> > compatible is broken, the constants have to move back, and you can still
>> > have a new EmailConstants class and deprecate the old constants to point
>> to
>> > the new class.
>> >
>> > Maybe I'll see this more clearly in the AM...
>> >
>> > Interested in you all's feedback.
>> >
>>
>> Hi Gary,
>>
>> well, I think we go in circles with this change ;-).
>>
>> I assumed that this topic is settled after reading the comment from sebb in
>> the RC2 thread (see http://markmail.org/message/svrb7nf3ocz7lgmd).
>>
>> Otoh, it's the first time I see constants in an interface and would be in
>> favor of reverting to the previous version (also because I do not fully
>> understand the rationale behind the change, some of the constants are not
>> even used and thus have been deprecated).
>>
> --
>
>>
>> Maybe we should postpone this kind of refactoring to 2.0 and do it then in
>> a proper way. Introducing this interface just created headaches and I also
>> had to disable some checks (e.g. InterfaceIsAType in checkstyle) because of
>> it.
>>
>
> That sounds like a good way to go to get 1.3 out the door.

Agreed.

> Gary
>
>
>>
>> Thomas
>>
>>
>> > On Tue, Dec 11, 2012 at 5:24 PM, Thomas Neidhart
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > I would like to call a vote from commons-email-1.3 based on RC5.
>> > >
>> > > This release candidate has the following changes compared to RC4
>> > >
>> > > +) update index and building page with correct information wrt Java
>> > >compatibility
>> > > +) update release notes with info on Java compatibility and Clirr
>> errors
>> > > +) fix svn:keywords for all source files and remove use of $Date$ tags
>> > > +) add $Id$ tags for all newly introduced source files in 1.3
>> > > +) update javax.mail.mail dependency to 1.4.5
>> > > +) fix PMD warnings and add NOPMD comment for false positives
>> > > +) added findbugs exclude filter for false positives
>> > > +) fix release date in changes.xml
>> > > +) correctly removed *.asc.[md5,sha1] files from Nexus staging area
>> > >
>> > > The files:
>> > >
>> > > The artifacts are deployed to Nexus:
>> > >
>> https://repository.apache.org/content/repositories/orgapachecommons-137/
>> > >
>> > > The tag:
>> > >
>> >
>> https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_RC5/
>> > >
>> > > The site:
>> > > http://people.apache.org/builds/commons/email/1.3/RC5/
>> > >
>> > > Additional Notes:
>> > >
>> > > o the download page and api links to older releases only work on
>> > >   the published site and will be corrected after release.
>> > >
>> > > Please take a look at the commons-email-1.3 artifacts and vote!
>> > >
>> > > 
>> > > [ ] +1 release it
>> > > [ ] +0 go ahead I don't care
>> > > [ ] -1 no, do not release it because
>> > > 
>> > >
>> > > Vote will remain open for at least 72 hours.
>> > >
>> > > Thanks in advance,
>> > >
>> > > Thomas
>> > >
>> > > -
>> > > 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
>> > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> > Spring Batch in Action: http://bit.ly/bqpbCK
>> > Blog

[continuum] BUILD FAILURE: Apache Commons - Commons Math -

[Continuum@vmbuild]

  Group (shared) Maven 2 Build Definition (Java 1.5)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Continuum-Build-Host: vmbuild
X-Continuum-Project-Id: 97
X-Continuum-Project-Name: Commons Math

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=25465&projectId=97

Build statistics:
  State: Failed
  Previous State: Ok
  Started at: Wed 12 Dec 2012 14:20:31 +
  Finished at: Wed 12 Dec 2012 14:29:46 +
  Total time: 9m 14s
  Build Trigger: Schedule
  Build Number: 1106
  Exit code: 1
  Building machine hostname: vmbuild
  Operating system : Linux(unknown)
  Java Home version : 
  java version "1.6.0_30"
  Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
  Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)

  Builder version :
  Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+)
  Java version: 1.6.0_30
  Java home: /usr/lib/jvm/jdk1.6.0_30/jre
  Default locale: en_US, platform encoding: ANSI_X3.4-1968
  OS name: "linux" version: "2.6.32-41-server" arch: "amd64" Family: 
"unix"


SCM Changes:

Changed: erans @ Wed 12 Dec 2012 13:33:20 +
Comment: Javadoc.
Files changed:
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/analysis/differentiation/FiniteDifferencesDifferentiator.java
 ( 1420666 )

Changed: erans @ Wed 12 Dec 2012 13:40:35 +
Comment: Fixed "Clirr" error.
Files changed:
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/special/Beta.java
 ( 1420669 )

Changed: erans @ Wed 12 Dec 2012 14:10:38 +
Comment: MATH-874
Refactored of the contents of package "o.a.c.m.optimization"
into the new "o.a.c.m.optim" and "o.a.c.m.fitting" packages.
* All deprecated classes/fields/methods have been removed in the
  replacement packages.
* Simplified API: a single "optimize(OptimizationData... data)"
  for all optimizer types.
* Simplified class hierarchy, merged interfaces and abstract
  classes, only base classes are generic.
* The new classes do not use the "DerivativeStructure" type.
Files changed:
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/exception/TooManyIterationsException.java
 ( 1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/exception/util/LocalizedFormats.java
 ( 1420684 )
  /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/fitting ( 
1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/fitting/CurveFitter.java
 ( 1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/fitting/GaussianFitter.java
 ( 1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/fitting/HarmonicFitter.java
 ( 1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/fitting/PolynomialFitter.java
 ( 1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/fitting/WeightedObservedPoint.java
 ( 1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/fitting/package-info.java
 ( 1420684 )
  /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim ( 
1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/AbstractConvergenceChecker.java
 ( 1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/BaseMultiStartMultivariateOptimizer.java
 ( 1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/BaseMultivariateOptimizer.java
 ( 1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/BaseOptimizer.java
 ( 1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/ConvergenceChecker.java
 ( 1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/GoalType.java
 ( 1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/InitialGuess.java
 ( 1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/MaxEval.java
 ( 1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/MaxIter.java
 ( 1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/ObjectiveFunction.java
 ( 1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/OptimizationData.java
 ( 1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/PointValuePair.java
 ( 1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/PointVectorValuePair.java
 ( 1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/SimpleBounds.java
 ( 1420684 )
  
/commons/proper/math/trunk/src/main/java/org/apache

[continuum] BUILD FAILURE: Apache Commons - Commons Math -

[Continuum@vmbuild]

  Group (shared) Maven 2 Build Definition (Java 1.5)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Continuum-Build-Host: vmbuild
X-Continuum-Project-Id: 97
X-Continuum-Project-Name: Commons Math

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=25467&projectId=97

Build statistics:
  State: Failed
  Previous State: Failed
  Started at: Wed 12 Dec 2012 15:22:25 +
  Finished at: Wed 12 Dec 2012 15:30:27 +
  Total time: 8m 2s
  Build Trigger: Schedule
  Build Number: 1106
  Exit code: 1
  Building machine hostname: vmbuild
  Operating system : Linux(unknown)
  Java Home version : 
  java version "1.6.0_30"
  Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
  Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)

  Builder version :
  Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+)
  Java version: 1.6.0_30
  Java home: /usr/lib/jvm/jdk1.6.0_30/jre
  Default locale: en_US, platform encoding: ANSI_X3.4-1968
  OS name: "linux" version: "2.6.32-41-server" arch: "amd64" Family: 
"unix"


SCM Changes:

Changed: erans @ Wed 12 Dec 2012 14:35:37 +
Comment: Fixed wrong position of package description.
Files changed:
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/linear/package-info.java
 ( 1420705 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/nonlinear/scalar/gradient/package-info.java
 ( 1420705 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/nonlinear/scalar/noderiv/package-info.java
 ( 1420705 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/nonlinear/scalar/package-info.java
 ( 1420705 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/nonlinear/vector/jacobian/package-info.java
 ( 1420705 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/nonlinear/vector/package-info.java
 ( 1420705 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/package-info.java
 ( 1420705 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/univariate/package-info.java
 ( 1420705 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optimization/package-info.java
 ( 1420705 )


Dependencies Changes:

No dependencies changed



Build Definition:

POM filename: pom.xml
Goals: clean deploy   
Arguments: --batch-mode -Pjava-1.5 -Dgpg.skip -Prelease
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Maven 2.2.1
Description: Group (shared) Maven 2 Build Definition (Java 1.5)


Test Summary:

Tests: 4535
Failures: 0
Errors: 7
Success Rate: 99
Total time: 433.5392





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

Re: svn commit: r1420448 - in /commons/proper/email/tags/EMAIL_1_3_RC5: ./ conf/ src/changes/ src/main/java/org/apache/commons/mail/ src/main/java/org/apache/commons/mail/resolver/ src/main/java/org/a

[Thomas Neidhart]

On Tue, Dec 11, 2012 at 11:39 PM, Thomas Neidhart  wrote:

> On 12/11/2012 11:30 PM, sebb wrote:
> > On 11 December 2012 22:00,   wrote:
> >> Author: tn
> >> Date: Tue Dec 11 22:00:13 2012
> >> New Revision: 1420448
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1420448&view=rev
> >> Log:
> >> Creating Commons Email v1.3 RC5 tag.
> >>
> >> Added:
> >> commons/proper/email/tags/EMAIL_1_3_RC5/
> >>   - copied from r1420374, commons/proper/email/trunk/
> >> commons/proper/email/tags/EMAIL_1_3_RC5/RELEASE-NOTES.txt
> >>   - copied unchanged from r1420416,
> commons/proper/email/trunk/RELEASE-NOTES.txt
> >>
> commons/proper/email/tags/EMAIL_1_3_RC5/conf/findbugs-exclude-filter.xml
> >>   - copied unchanged from r1420409,
> commons/proper/email/trunk/conf/findbugs-exclude-filter.xml
> >> commons/proper/email/tags/EMAIL_1_3_RC5/pom.xml
> >>   - copied, changed from r1420442,
> commons/proper/email/trunk/pom.xml
> >> commons/proper/email/tags/EMAIL_1_3_RC5/src/changes/changes.xml
> >>   - copied unchanged from r1420403,
> commons/proper/email/trunk/src/changes/changes.xml
> >>
> commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/ByteArrayDataSource.java
> >>   - copied unchanged from r1420381,
> commons/proper/email/trunk/src/main/java/org/apache/commons/mail/ByteArrayDataSource.java
> >>
> commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/DataSourceResolver.java
> >>   - copied unchanged from r1420381,
> commons/proper/email/trunk/src/main/java/org/apache/commons/mail/DataSourceResolver.java
> >>
> commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/DefaultAuthenticator.java
> >>   - copied unchanged from r1420381,
> commons/proper/email/trunk/src/main/java/org/apache/commons/mail/DefaultAuthenticator.java
> >>
> commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/Email.java
> >>   - copied unchanged from r1420388,
> commons/proper/email/trunk/src/main/java/org/apache/commons/mail/Email.java
> >>
> commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/EmailAttachment.java
> >>   - copied unchanged from r1420381,
> commons/proper/email/trunk/src/main/java/org/apache/commons/mail/EmailAttachment.java
> >>
> commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/EmailConstants.java
> >>   - copied unchanged from r1420381,
> commons/proper/email/trunk/src/main/java/org/apache/commons/mail/EmailConstants.java
> >>
> commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/EmailException.java
> >>   - copied unchanged from r1420381,
> commons/proper/email/trunk/src/main/java/org/apache/commons/mail/EmailException.java
> >>
> commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/EmailUtils.java
> >>   - copied unchanged from r1420381,
> commons/proper/email/trunk/src/main/java/org/apache/commons/mail/EmailUtils.java
> >>
> commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/HtmlEmail.java
> >>   - copied unchanged from r1420402,
> commons/proper/email/trunk/src/main/java/org/apache/commons/mail/HtmlEmail.java
> >>
> commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/ImageHtmlEmail.java
> >>   - copied unchanged from r1420381,
> commons/proper/email/trunk/src/main/java/org/apache/commons/mail/ImageHtmlEmail.java
> >>
> commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/MultiPartEmail.java
> >>   - copied unchanged from r1420402,
> commons/proper/email/trunk/src/main/java/org/apache/commons/mail/MultiPartEmail.java
> >>
> commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/SimpleEmail.java
> >>   - copied unchanged from r1420381,
> commons/proper/email/trunk/src/main/java/org/apache/commons/mail/SimpleEmail.java
> >>
> commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/resolver/DataSourceBaseResolver.java
> >>   - copied unchanged from r1420381,
> commons/proper/email/trunk/src/main/java/org/apache/commons/mail/resolver/DataSourceBaseResolver.java
> >>
> commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/resolver/DataSourceClassPathResolver.java
> >>   - copied unchanged from r1420381,
> commons/proper/email/trunk/src/main/java/org/apache/commons/mail/resolver/DataSourceClassPathResolver.java
> >>
> commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/resolver/DataSourceCompositeResolver.java
> >>   - copied unchanged from r1420381,
> commons/proper/email/trunk/src/main/java/org/apache/commons/mail/resolver/DataSourceCompositeResolver.java
> >>
> commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/resolver/DataSourceFileResolver.java
> >>   - copied unchanged from r1420381,
> commons/proper/email/trunk/src/main/java/org/

Re: svn commit: r1420448 - in /commons/proper/email/tags/EMAIL_1_3_RC5: ./ conf/ src/changes/ src/main/java/org/apache/commons/mail/ src/main/java/org/apache/commons/mail/resolver/ src/main/java/org/a

[Gilles Sadowski]

On Wed, Dec 12, 2012 at 04:35:03PM +0100, Thomas Neidhart wrote:
> On Tue, Dec 11, 2012 at 11:39 PM, Thomas Neidhart  > wrote:
> 
> > On 12/11/2012 11:30 PM, sebb wrote:
> > > On 11 December 2012 22:00,   wrote:
> > >> Author: tn
> > >> Date: Tue Dec 11 22:00:13 2012
> > >> New Revision: 1420448
> > >>
> > >> URL: http://svn.apache.org/viewvc?rev=1420448&view=rev
> > >> Log:
> > >> Creating Commons Email v1.3 RC5 tag.
> > >>
> > >> Added:
> > >> commons/proper/email/tags/EMAIL_1_3_RC5/
> > >>   - copied from r1420374, commons/proper/email/trunk/
> > >> commons/proper/email/tags/EMAIL_1_3_RC5/RELEASE-NOTES.txt
> > >>   - copied unchanged from r1420416,
> > commons/proper/email/trunk/RELEASE-NOTES.txt
> > >>
> > commons/proper/email/tags/EMAIL_1_3_RC5/conf/findbugs-exclude-filter.xml
> > >>   - copied unchanged from r1420409,
> > commons/proper/email/trunk/conf/findbugs-exclude-filter.xml
> > >> commons/proper/email/tags/EMAIL_1_3_RC5/pom.xml
> > >>   - copied, changed from r1420442,
> > commons/proper/email/trunk/pom.xml
> > >> commons/proper/email/tags/EMAIL_1_3_RC5/src/changes/changes.xml
> > >>   - copied unchanged from r1420403,
> > commons/proper/email/trunk/src/changes/changes.xml
> > >>
> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/ByteArrayDataSource.java
> > >>   - copied unchanged from r1420381,
> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/ByteArrayDataSource.java
> > >>
> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/DataSourceResolver.java
> > >>   - copied unchanged from r1420381,
> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/DataSourceResolver.java
> > >>
> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/DefaultAuthenticator.java
> > >>   - copied unchanged from r1420381,
> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/DefaultAuthenticator.java
> > >>
> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/Email.java
> > >>   - copied unchanged from r1420388,
> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/Email.java
> > >>
> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/EmailAttachment.java
> > >>   - copied unchanged from r1420381,
> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/EmailAttachment.java
> > >>
> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/EmailConstants.java
> > >>   - copied unchanged from r1420381,
> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/EmailConstants.java
> > >>
> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/EmailException.java
> > >>   - copied unchanged from r1420381,
> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/EmailException.java
> > >>
> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/EmailUtils.java
> > >>   - copied unchanged from r1420381,
> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/EmailUtils.java
> > >>
> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/HtmlEmail.java
> > >>   - copied unchanged from r1420402,
> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/HtmlEmail.java
> > >>
> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/ImageHtmlEmail.java
> > >>   - copied unchanged from r1420381,
> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/ImageHtmlEmail.java
> > >>
> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/MultiPartEmail.java
> > >>   - copied unchanged from r1420402,
> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/MultiPartEmail.java
> > >>
> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/SimpleEmail.java
> > >>   - copied unchanged from r1420381,
> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/SimpleEmail.java
> > >>
> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/resolver/DataSourceBaseResolver.java
> > >>   - copied unchanged from r1420381,
> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/resolver/DataSourceBaseResolver.java
> > >>
> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/resolver/DataSourceClassPathResolver.java
> > >>   - copied unchanged from r1420381,
> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/resolver/DataSourceClassPathResolver.java
> > >>
> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/resolver/DataSourceCompositeResolver.java
> > >>   - copied unchanged from r1420381,
> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/resolver/Data

[Math] Preparing release 3.1

[Gilles Sadowski]

Hi.

I'm going to start the steps of the release procedure, tomorrow or Friday,
after the pending issues (MATH-874 and MATH-911) are resolved.

There is one known compatibility problem (cf. messsage with subject "svn
commit: r142"). Can it be solved by tomorrow?

Any other blocking issues?


Regards,
Gilles

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

[continuum] BUILD FAILURE: Apache Commons - Commons Configuration - Group (shared) Maven 2 Build Definition (Java 1.5)

[Continuum@vmbuild]

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=25469&projectId=72

Build statistics:
  State: Failed
  Previous State: Ok
  Started at: Wed 12 Dec 2012 18:19:02 +
  Finished at: Wed 12 Dec 2012 18:19:34 +
  Total time: 32s
  Build Trigger: Schedule
  Build Number: 217
  Exit code: 1
  Building machine hostname: vmbuild
  Operating system : Linux(unknown)
  Java Home version : 
  java version "1.6.0_30"
  Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
  Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)

  Builder version :
  Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+)
  Java version: 1.6.0_30
  Java home: /usr/lib/jvm/jdk1.6.0_30/jre
  Default locale: en_US, platform encoding: ANSI_X3.4-1968
  OS name: "linux" version: "2.6.32-41-server" arch: "amd64" Family: 
"unix"


SCM Changes:

Changed: oheger @ Wed 12 Dec 2012 17:58:47 +
Comment: Added a merge() method to BasicBuilderParameters.
Files changed:
  
/commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/builder/BasicBuilderParameters.java
 ( 1420889 )
  
/commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/builder/BasicConfigurationBuilder.java
 ( 1420889 )
  
/commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/builder/BuilderParameters.java
 ( 1420889 )
  
/commons/proper/configuration/trunk/src/test/java/org/apache/commons/configuration/builder/TestBasicBuilderParameters.java
 ( 1420889 )


Dependencies Changes:

No dependencies changed



Build Definition:

POM filename: pom.xml
Goals: clean deploy   
Arguments: --batch-mode -Pjava-1.5 -Dgpg.skip -Prelease
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Maven 2.2.1
Description: Group (shared) Maven 2 Build Definition (Java 1.5)


Test Summary:

Tests: 0
Failures: 0
Errors: 0
Total time: 0.0





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

Re: [VOTE] Release of commons-email-1.3 based on RC5

[Gary Gregory]

On Wed, Dec 12, 2012 at 9:06 AM, sebb  wrote:

> On 12 December 2012 13:17, Gary Gregory  wrote:
> > On Wed, Dec 12, 2012 at 3:59 AM, Thomas Neidhart
> > wrote:
> >
> >> On Wed, Dec 12, 2012 at 4:58 AM, Gary Gregory  >> >wrote:
> >>
> >> > Thank you for doing another RC.
> >> >
> >> > While I was digging for a justification of the Clirr errors, I found
> this
> >> > in the release notes: "Clirr reports several errors for this release
> due
> >> to
> >> > moving constants from the Email class to the newly introduced
> >> > EmailConstants interface. These changes are guaranteed to be binary
> >> > compatible."
> >> >
> >> > Is it really binary compatible? What if I use reflection to access the
> >> > constant on Email, will the reflection call be redirected to
> >> > EmailConstants? There's unit test for ya ;)
> >> >
> >> > Using an interface to define constants is a no-no in my book. I've
> seen
> >> > this discussed before in other places and for a long time, but to
> >> > summarize, I see an interface as defining a contract for a class to
> >> > implement. A constant does not fit.
> >> >
> >> > Constants in interface feels like a hack to provide the short hand of
> a
> >> > class implementing an interface just to be able to access the
> constants
> >> > without qualifying them with a type. Not nice design IMO and a
> dubious us
> >> > of an interface, very Java 1.0. It seems that static imports is
> another
> >> > attempt to solve this desire for a short hand to use constants.
> >> >
> >> > What to do? Move the constants back to their 1.2? What's so bad about
> >> that?
> >> > Hm...
> >> >
> >> > Make the EmailConstants a class instead of an interface? If binary
> >> > compatible is broken, the constants have to move back, and you can
> still
> >> > have a new EmailConstants class and deprecate the old constants to
> point
> >> to
> >> > the new class.
> >> >
> >> > Maybe I'll see this more clearly in the AM...
> >> >
> >> > Interested in you all's feedback.
> >> >
> >>
> >> Hi Gary,
> >>
> >> well, I think we go in circles with this change ;-).
> >>
> >> I assumed that this topic is settled after reading the comment from
> sebb in
> >> the RC2 thread (see http://markmail.org/message/svrb7nf3ocz7lgmd).
> >>
> >> Otoh, it's the first time I see constants in an interface and would be
> in
> >> favor of reverting to the previous version (also because I do not fully
> >> understand the rationale behind the change, some of the constants are
> not
> >> even used and thus have been deprecated).
> >>
> > --
> >
> >>
> >> Maybe we should postpone this kind of refactoring to 2.0 and do it then
> in
> >> a proper way. Introducing this interface just created headaches and I
> also
> >> had to disable some checks (e.g. InterfaceIsAType in checkstyle)
> because of
> >> it.
> >>
> >
> > That sounds like a good way to go to get 1.3 out the door.
>
> Agreed.
>

Just in case: Thomas, do not despair, we are, I believe on the last leg of
the trip :)

Gary


>
> > Gary
> >
> >
> >>
> >> Thomas
> >>
> >>
> >> > On Tue, Dec 11, 2012 at 5:24 PM, Thomas Neidhart
> >> > wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > I would like to call a vote from commons-email-1.3 based on RC5.
> >> > >
> >> > > This release candidate has the following changes compared to RC4
> >> > >
> >> > > +) update index and building page with correct information wrt Java
> >> > >compatibility
> >> > > +) update release notes with info on Java compatibility and Clirr
> >> errors
> >> > > +) fix svn:keywords for all source files and remove use of $Date$
> tags
> >> > > +) add $Id$ tags for all newly introduced source files in 1.3
> >> > > +) update javax.mail.mail dependency to 1.4.5
> >> > > +) fix PMD warnings and add NOPMD comment for false positives
> >> > > +) added findbugs exclude filter for false positives
> >> > > +) fix release date in changes.xml
> >> > > +) correctly removed *.asc.[md5,sha1] files from Nexus staging area
> >> > >
> >> > > The files:
> >> > >
> >> > > The artifacts are deployed to Nexus:
> >> > >
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-137/
> >> > >
> >> > > The tag:
> >> > >
> >> >
> >>
> https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_RC5/
> >> > >
> >> > > The site:
> >> > > http://people.apache.org/builds/commons/email/1.3/RC5/
> >> > >
> >> > > Additional Notes:
> >> > >
> >> > > o the download page and api links to older releases only work on
> >> > >   the published site and will be corrected after release.
> >> > >
> >> > > Please take a look at the commons-email-1.3 artifacts and vote!
> >> > >
> >> > > 
> >> > > [ ] +1 release it
> >> > > [ ] +0 go ahead I don't care
> >> > > [ ] -1 no, do not release it because
> >> > > 
> >> > >
> >> > > Vote will remain open for at least 72 hours.
> >> > >
> >> > > Thanks in advance,
> >> > >
> >> > > Thomas
> >> > >
> >> > >
> -

Re: [Math] Preparing release 3.1

[Luc Maisonobe]

Le 12/12/2012 19:09, Gilles Sadowski a écrit :
> Hi.

Hi Gilles,

> 
> I'm going to start the steps of the release procedure, tomorrow or Friday,
> after the pending issues (MATH-874 and MATH-911) are resolved.

This are really good new!

> 
> There is one known compatibility problem (cf. messsage with subject "svn
> commit: r142"). Can it be solved by tomorrow?
> 
> Any other blocking issues?

None from my side.

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: [Math] Preparing release 3.1

[Gary Gregory]

Make sure you have all of your Checkstyle, FindBugs, and PMD ducks in a row
;)

Gary


On Wed, Dec 12, 2012 at 2:11 PM, Luc Maisonobe wrote:

> Le 12/12/2012 19:09, Gilles Sadowski a écrit :
> > Hi.
>
> Hi Gilles,
>
> >
> > I'm going to start the steps of the release procedure, tomorrow or
> Friday,
> > after the pending issues (MATH-874 and MATH-911) are resolved.
>
> This are really good new!
>
> >
> > There is one known compatibility problem (cf. messsage with subject "svn
> > commit: r142"). Can it be solved by tomorrow?
> >
> > Any other blocking issues?
>
> None from my side.
>
> 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
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Release of commons-email-1.3 based on RC5

[Siegfried Goeschl]

Hi folks,

to avoid the full circles here

* I hopefully fixed the binary compatibility issue, wrote test and also 
tested it with my production code


* I moved the constants to EmailConstants because there are many 
constants and using an non-trivial implementation class (Email) to 
access a few constants is also questionable in my opinion


* The design of commons-email is flawed in a few ways and there is not a 
lot you can fix in a major version. So I suggest that we focus on 
delivered value instead


Cheers,

Siegfried Goeschl


On 12.12.12 15:06, sebb wrote:

On 12 December 2012 13:17, Gary Gregory  wrote:

On Wed, Dec 12, 2012 at 3:59 AM, Thomas Neidhart
wrote:


On Wed, Dec 12, 2012 at 4:58 AM, Gary Gregory 
wrote:



Thank you for doing another RC.

While I was digging for a justification of the Clirr errors, I found this
in the release notes: "Clirr reports several errors for this release due

to

moving constants from the Email class to the newly introduced
EmailConstants interface. These changes are guaranteed to be binary
compatible."

Is it really binary compatible? What if I use reflection to access the
constant on Email, will the reflection call be redirected to
EmailConstants? There's unit test for ya ;)

Using an interface to define constants is a no-no in my book. I've seen
this discussed before in other places and for a long time, but to
summarize, I see an interface as defining a contract for a class to
implement. A constant does not fit.

Constants in interface feels like a hack to provide the short hand of a
class implementing an interface just to be able to access the constants
without qualifying them with a type. Not nice design IMO and a dubious us
of an interface, very Java 1.0. It seems that static imports is another
attempt to solve this desire for a short hand to use constants.

What to do? Move the constants back to their 1.2? What's so bad about

that?

Hm...

Make the EmailConstants a class instead of an interface? If binary
compatible is broken, the constants have to move back, and you can still
have a new EmailConstants class and deprecate the old constants to point

to

the new class.

Maybe I'll see this more clearly in the AM...

Interested in you all's feedback.



Hi Gary,

well, I think we go in circles with this change ;-).

I assumed that this topic is settled after reading the comment from sebb in
the RC2 thread (see http://markmail.org/message/svrb7nf3ocz7lgmd).

Otoh, it's the first time I see constants in an interface and would be in
favor of reverting to the previous version (also because I do not fully
understand the rationale behind the change, some of the constants are not
even used and thus have been deprecated).


--



Maybe we should postpone this kind of refactoring to 2.0 and do it then in
a proper way. Introducing this interface just created headaches and I also
had to disable some checks (e.g. InterfaceIsAType in checkstyle) because of
it.



That sounds like a good way to go to get 1.3 out the door.


Agreed.


Gary




Thomas



On Tue, Dec 11, 2012 at 5:24 PM, Thomas Neidhart
wrote:


Hi,

I would like to call a vote from commons-email-1.3 based on RC5.

This release candidate has the following changes compared to RC4

+) update index and building page with correct information wrt Java
compatibility
+) update release notes with info on Java compatibility and Clirr

errors

+) fix svn:keywords for all source files and remove use of $Date$ tags
+) add $Id$ tags for all newly introduced source files in 1.3
+) update javax.mail.mail dependency to 1.4.5
+) fix PMD warnings and add NOPMD comment for false positives
+) added findbugs exclude filter for false positives
+) fix release date in changes.xml
+) correctly removed *.asc.[md5,sha1] files from Nexus staging area

The files:

The artifacts are deployed to Nexus:


https://repository.apache.org/content/repositories/orgapachecommons-137/


The tag:




https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_RC5/


The site:
http://people.apache.org/builds/commons/email/1.3/RC5/

Additional Notes:

o the download page and api links to older releases only work on
   the published site and will be corrected after release.

Please take a look at the commons-email-1.3 artifacts and vote!


[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because


Vote will remain open for at least 72 hours.

Thanks in advance,

Thomas

-
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
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygrego

Re: svn commit: r1420448 - in /commons/proper/email/tags/EMAIL_1_3_RC5: ./ conf/ src/changes/ src/main/java/org/apache/commons/mail/ src/main/java/org/apache/commons/mail/resolver/ src/main/java/org/a

[sebb]

On 12 December 2012 15:42, Gilles Sadowski  wrote:
> On Wed, Dec 12, 2012 at 04:35:03PM +0100, Thomas Neidhart wrote:
>> On Tue, Dec 11, 2012 at 11:39 PM, Thomas Neidhart > > wrote:
>>
>> > On 12/11/2012 11:30 PM, sebb wrote:
>> > > On 11 December 2012 22:00,   wrote:
>> > >> Author: tn
>> > >> Date: Tue Dec 11 22:00:13 2012
>> > >> New Revision: 1420448
>> > >>
>> > >> URL: http://svn.apache.org/viewvc?rev=1420448&view=rev
>> > >> Log:
>> > >> Creating Commons Email v1.3 RC5 tag.
>> > >>
>> > >> Added:
>> > >> commons/proper/email/tags/EMAIL_1_3_RC5/
>> > >>   - copied from r1420374, commons/proper/email/trunk/
>> > >> commons/proper/email/tags/EMAIL_1_3_RC5/RELEASE-NOTES.txt
>> > >>   - copied unchanged from r1420416,
>> > commons/proper/email/trunk/RELEASE-NOTES.txt
>> > >>
>> > commons/proper/email/tags/EMAIL_1_3_RC5/conf/findbugs-exclude-filter.xml
>> > >>   - copied unchanged from r1420409,
>> > commons/proper/email/trunk/conf/findbugs-exclude-filter.xml
>> > >> commons/proper/email/tags/EMAIL_1_3_RC5/pom.xml
>> > >>   - copied, changed from r1420442,
>> > commons/proper/email/trunk/pom.xml
>> > >> commons/proper/email/tags/EMAIL_1_3_RC5/src/changes/changes.xml
>> > >>   - copied unchanged from r1420403,
>> > commons/proper/email/trunk/src/changes/changes.xml
>> > >>
>> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/ByteArrayDataSource.java
>> > >>   - copied unchanged from r1420381,
>> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/ByteArrayDataSource.java
>> > >>
>> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/DataSourceResolver.java
>> > >>   - copied unchanged from r1420381,
>> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/DataSourceResolver.java
>> > >>
>> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/DefaultAuthenticator.java
>> > >>   - copied unchanged from r1420381,
>> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/DefaultAuthenticator.java
>> > >>
>> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/Email.java
>> > >>   - copied unchanged from r1420388,
>> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/Email.java
>> > >>
>> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/EmailAttachment.java
>> > >>   - copied unchanged from r1420381,
>> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/EmailAttachment.java
>> > >>
>> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/EmailConstants.java
>> > >>   - copied unchanged from r1420381,
>> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/EmailConstants.java
>> > >>
>> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/EmailException.java
>> > >>   - copied unchanged from r1420381,
>> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/EmailException.java
>> > >>
>> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/EmailUtils.java
>> > >>   - copied unchanged from r1420381,
>> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/EmailUtils.java
>> > >>
>> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/HtmlEmail.java
>> > >>   - copied unchanged from r1420402,
>> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/HtmlEmail.java
>> > >>
>> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/ImageHtmlEmail.java
>> > >>   - copied unchanged from r1420381,
>> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/ImageHtmlEmail.java
>> > >>
>> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/MultiPartEmail.java
>> > >>   - copied unchanged from r1420402,
>> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/MultiPartEmail.java
>> > >>
>> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/SimpleEmail.java
>> > >>   - copied unchanged from r1420381,
>> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/SimpleEmail.java
>> > >>
>> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/resolver/DataSourceBaseResolver.java
>> > >>   - copied unchanged from r1420381,
>> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/resolver/DataSourceBaseResolver.java
>> > >>
>> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/resolver/DataSourceClassPathResolver.java
>> > >>   - copied unchanged from r1420381,
>> > commons/proper/email/trunk/src/main/java/org/apache/commons/mail/resolver/DataSourceClassPathResolver.java
>> > >>
>> > commons/proper/email/tags/EMAIL_1_3_RC5/src/main/java/org/apache/commons/mail/resolver/DataSourceCompositeReso

Re: [VOTE] Release of commons-email-1.3 based on RC5

[sebb]

On 12 December 2012 19:39, Siegfried Goeschl  wrote:
> Hi folks,
>
> to avoid the full circles here
>
> * I hopefully fixed the binary compatibility issue, wrote test and also
> tested it with my production code
>
> * I moved the constants to EmailConstants because there are many constants
> and using an non-trivial implementation class (Email) to access a few
> constants is also questionable in my opinion

A better solution might have been to use a constant class rather than
an interface.

The Email class can then reference the constant class:

public static final String XYZ = EmailConstants.XYZ;

Other classes can then reference EmailConstants directly.

> * The design of commons-email is flawed in a few ways and there is not a lot
> you can fix in a major version. So I suggest that we focus on delivered
> value instead
>
> Cheers,
>
> Siegfried Goeschl
>
>
>
> On 12.12.12 15:06, sebb wrote:
>>
>> On 12 December 2012 13:17, Gary Gregory  wrote:
>>>
>>> On Wed, Dec 12, 2012 at 3:59 AM, Thomas Neidhart
>>> wrote:
>>>
 On Wed, Dec 12, 2012 at 4:58 AM, Gary Gregory 
> wrote:


> Thank you for doing another RC.
>
> While I was digging for a justification of the Clirr errors, I found
> this
> in the release notes: "Clirr reports several errors for this release
> due

 to
>
> moving constants from the Email class to the newly introduced
> EmailConstants interface. These changes are guaranteed to be binary
> compatible."
>
> Is it really binary compatible? What if I use reflection to access the
> constant on Email, will the reflection call be redirected to
> EmailConstants? There's unit test for ya ;)
>
> Using an interface to define constants is a no-no in my book. I've seen
> this discussed before in other places and for a long time, but to
> summarize, I see an interface as defining a contract for a class to
> implement. A constant does not fit.
>
> Constants in interface feels like a hack to provide the short hand of a
> class implementing an interface just to be able to access the constants
> without qualifying them with a type. Not nice design IMO and a dubious
> us
> of an interface, very Java 1.0. It seems that static imports is another
> attempt to solve this desire for a short hand to use constants.
>
> What to do? Move the constants back to their 1.2? What's so bad about

 that?
>
> Hm...
>
> Make the EmailConstants a class instead of an interface? If binary
> compatible is broken, the constants have to move back, and you can
> still
> have a new EmailConstants class and deprecate the old constants to
> point

 to
>
> the new class.
>
> Maybe I'll see this more clearly in the AM...
>
> Interested in you all's feedback.
>

 Hi Gary,

 well, I think we go in circles with this change ;-).

 I assumed that this topic is settled after reading the comment from sebb
 in
 the RC2 thread (see http://markmail.org/message/svrb7nf3ocz7lgmd).

 Otoh, it's the first time I see constants in an interface and would be
 in
 favor of reverting to the previous version (also because I do not fully
 understand the rationale behind the change, some of the constants are
 not
 even used and thus have been deprecated).

>>> --
>>>

 Maybe we should postpone this kind of refactoring to 2.0 and do it then
 in
 a proper way. Introducing this interface just created headaches and I
 also
 had to disable some checks (e.g. InterfaceIsAType in checkstyle) because
 of
 it.

>>>
>>> That sounds like a good way to go to get 1.3 out the door.
>>
>>
>> Agreed.
>>
>>> Gary
>>>
>>>

 Thomas


> On Tue, Dec 11, 2012 at 5:24 PM, Thomas Neidhart
> wrote:
>
>> Hi,
>>
>> I would like to call a vote from commons-email-1.3 based on RC5.
>>
>> This release candidate has the following changes compared to RC4
>>
>> +) update index and building page with correct information wrt Java
>> compatibility
>> +) update release notes with info on Java compatibility and Clirr

 errors
>>
>> +) fix svn:keywords for all source files and remove use of $Date$ tags
>> +) add $Id$ tags for all newly introduced source files in 1.3
>> +) update javax.mail.mail dependency to 1.4.5
>> +) fix PMD warnings and add NOPMD comment for false positives
>> +) added findbugs exclude filter for false positives
>> +) fix release date in changes.xml
>> +) correctly removed *.asc.[md5,sha1] files from Nexus staging area
>>
>> The files:
>>
>> The artifacts are deployed to Nexus:
>>
 https://repository.apache.org/content/repositories/orgapachecommons-137/
>>
>>
>> The tag:
>>
>

 https://svn.apache.org/repos/asf/commo

Re: [VOTE] Release of commons-email-1.3 based on RC5

[Gary Gregory]

On Wed, Dec 12, 2012 at 2:47 PM, sebb  wrote:

> On 12 December 2012 19:39, Siegfried Goeschl  wrote:
> > Hi folks,
> >
> > to avoid the full circles here
> >
> > * I hopefully fixed the binary compatibility issue, wrote test and also
> > tested it with my production code
> >
> > * I moved the constants to EmailConstants because there are many
> constants
> > and using an non-trivial implementation class (Email) to access a few
> > constants is also questionable in my opinion
>
> A better solution might have been to use a constant class rather than
> an interface.
>
> The Email class can then reference the constant class:
>
> public static final String XYZ = EmailConstants.XYZ;
>
> Other classes can then reference EmailConstants directly.
>
> > * The design of commons-email is flawed in a few ways and there is not a
> lot
> > you can fix in a major version. So I suggest that we focus on delivered
> > value instead
> >
> > Cheers,
> >
> > Siegfried Goeschl
> >
> >
> >
> > On 12.12.12 15:06, sebb wrote:
> >>
> >> On 12 December 2012 13:17, Gary Gregory  wrote:
> >>>
> >>> On Wed, Dec 12, 2012 at 3:59 AM, Thomas Neidhart
> >>> wrote:
> >>>
>  On Wed, Dec 12, 2012 at 4:58 AM, Gary Gregory  >
> > wrote:
> 
> 
> > Thank you for doing another RC.
> >
> > While I was digging for a justification of the Clirr errors, I found
> > this
> > in the release notes: "Clirr reports several errors for this release
> > due
> 
>  to
> >
> > moving constants from the Email class to the newly introduced
> > EmailConstants interface. These changes are guaranteed to be binary
> > compatible."
> >
> > Is it really binary compatible? What if I use reflection to access
> the
> > constant on Email, will the reflection call be redirected to
> > EmailConstants? There's unit test for ya ;)
> >
> > Using an interface to define constants is a no-no in my book. I've
> seen
> > this discussed before in other places and for a long time, but to
> > summarize, I see an interface as defining a contract for a class to
> > implement. A constant does not fit.
> >
> > Constants in interface feels like a hack to provide the short hand
> of a
> > class implementing an interface just to be able to access the
> constants
> > without qualifying them with a type. Not nice design IMO and a
> dubious
> > us
> > of an interface, very Java 1.0. It seems that static imports is
> another
> > attempt to solve this desire for a short hand to use constants.
> >
> > What to do? Move the constants back to their 1.2? What's so bad about
> 
>  that?
> >
> > Hm...
> >
> > Make the EmailConstants a class instead of an interface? If binary
> > compatible is broken, the constants have to move back, and you can
> > still
> > have a new EmailConstants class and deprecate the old constants to
> > point
> 
>  to
> >
> > the new class.
>

Yes, at least do this unless we revert to 1.2.

Gary


> >
> > Maybe I'll see this more clearly in the AM...
> >
> > Interested in you all's feedback.
> >
> 
>  Hi Gary,
> 
>  well, I think we go in circles with this change ;-).
> 
>  I assumed that this topic is settled after reading the comment from
> sebb
>  in
>  the RC2 thread (see http://markmail.org/message/svrb7nf3ocz7lgmd).
> 
>  Otoh, it's the first time I see constants in an interface and would be
>  in
>  favor of reverting to the previous version (also because I do not
> fully
>  understand the rationale behind the change, some of the constants are
>  not
>  even used and thus have been deprecated).
> 
> >>> --
> >>>
> 
>  Maybe we should postpone this kind of refactoring to 2.0 and do it
> then
>  in
>  a proper way. Introducing this interface just created headaches and I
>  also
>  had to disable some checks (e.g. InterfaceIsAType in checkstyle)
> because
>  of
>  it.
> 
> >>>
> >>> That sounds like a good way to go to get 1.3 out the door.
> >>
> >>
> >> Agreed.
> >>
> >>> Gary
> >>>
> >>>
> 
>  Thomas
> 
> 
> > On Tue, Dec 11, 2012 at 5:24 PM, Thomas Neidhart
> > wrote:
> >
> >> Hi,
> >>
> >> I would like to call a vote from commons-email-1.3 based on RC5.
> >>
> >> This release candidate has the following changes compared to RC4
> >>
> >> +) update index and building page with correct information wrt Java
> >> compatibility
> >> +) update release notes with info on Java compatibility and Clirr
> 
>  errors
> >>
> >> +) fix svn:keywords for all source files and remove use of $Date$
> tags
> >> +) add $Id$ tags for all newly introduced source files in 1.3
> >> +) update javax.mail.mail dependency to 1.4.5
> >> +) fix PMD warnings and add NOPMD comment for false positives
>

Re: [VOTE][CANCEL] Release of commons-email-1.3 based on RC4

[Siegfried Goeschl]

Unfortunately I do remember ... :-(

Siegfried Goeschl

On 11.12.12 22:08, Mark Struberg wrote:

we had this over here at UPC as well. This did cost Sigi a release as well if 
you remember ;)

Most times this can be disabled by your provider. Just phone them and explain 
that they are breaking your computer and this creates costs by them not acting 
standard conform ;)


LieGrue,
strub



- Original Message -

From: sebb 
To: Commons Developers List 
Cc:
Sent: Tuesday, December 11, 2012 9:18 PM
Subject: Re: [VOTE][CANCEL] Release of commons-email-1.3 based on RC4

On 11 December 2012 12:11, Gary Gregory  wrote:

  On Tue, Dec 11, 2012 at 6:56 AM, sebb  wrote:


  On 11 December 2012 08:58, Thomas Neidhart



  wrote:
  > Hi,
  >
  > thanks for looking into it.
  >
  > I will fix the issues wrt build page, release notes and findbugs
  warnings.
  >
  > Regarding the unit test failure:
  >
  > I have not seen the problem before, and just validated it. The

unit test

  > tries to open a connection to an invalid url:

http://example.invalid

  > For some reason this seems to succeed in your environment. Could

it be

  that
  > you have a custom hosts entry for this domain?

  Or it could be a faulty DNS server.

  I used to have this exact problem with the OpenDNS server.
  They resolve unknown hosts to their home page (extra advertising).
  They used to do this for *.invalid as well, but after years of
  complaints that this behaviour was contrary to the RFC they fixed the
  issue.

  Try pinging example.invalid and then do an nslookup on the IP address.



  That is what Cox must be doing indeed:

  Pinging example.invalid [72.215.225.9] with 32 bytes of data:
  Request timed out.
  Request timed out.
  Request timed out.
  My browser redirects this IP to http://finder.cox.net/dnserror.html


So Cox are violating the RFC.

Perhaps you could direct them to the relevant RFC:

There are several TLD names which are reserved by RFC 2606, section 2.
Amongst them is the TLD "invalid".


".invalid" is intended for use in online construction of domain
   names that are sure to be invalid and which it is obvious at a
   glance are invalid.


Note the phrase "that are sure to be invalid".
An invalid domain name cannot have an IP address.
No DNS server should ever resolve addresses in the TLD "invalid".


  Gary


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



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




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

Re: [VOTE] Release of commons-email-1.3 based on RC5

[Thomas Neidhart]

On 12/12/2012 08:39 PM, Siegfried Goeschl wrote:
> Hi folks,
> 
> to avoid the full circles here
> 
> * I hopefully fixed the binary compatibility issue, wrote test and also
> tested it with my production code
> 
> * I moved the constants to EmailConstants because there are many
> constants and using an non-trivial implementation class (Email) to
> access a few constants is also questionable in my opinion
> 
> * The design of commons-email is flawed in a few ways and there is not a
> lot you can fix in a major version. So I suggest that we focus on
> delivered value instead

Hi Siegfried,

thanks for your feedback.

Taking this into account, together with the posts from sebb and Gary,
imho the best solutions is as sebb proposed:

* Change EmailConstants to a public final class
* Add back the constants to the Email class by referencing them from
  EmailConstants
* Mark the constants in Email as deprecated

btw. there are several constants that have not been in use since the 1.0
release:

String SENDER_EMAIL = "sender.email";
String SENDER_NAME = "sender.name";
String RECEIVER_EMAIL = "receiver.email";
String RECEIVER_NAME = "receiver.name";
String EMAIL_SUBJECT = "email.subject";
String EMAIL_BODY = "email.body";
String CONTENT_TYPE = "content.type";
String ATTACHMENTS = "attachments";
String FILE_SERVER = "file.server";

Does anybody know how or if they are in use? They are now marked as
deprecated, but I am really curious about there origin.

Does everybody agree on wha?

Thomas

> 
> Cheers,
> 
> Siegfried Goeschl
> 
> 
> On 12.12.12 15:06, sebb wrote:
>> On 12 December 2012 13:17, Gary Gregory  wrote:
>>> On Wed, Dec 12, 2012 at 3:59 AM, Thomas Neidhart
>>> wrote:
>>>
 On Wed, Dec 12, 2012 at 4:58 AM, Gary Gregory  wrote:

> Thank you for doing another RC.
>
> While I was digging for a justification of the Clirr errors, I
> found this
> in the release notes: "Clirr reports several errors for this
> release due
 to
> moving constants from the Email class to the newly introduced
> EmailConstants interface. These changes are guaranteed to be binary
> compatible."
>
> Is it really binary compatible? What if I use reflection to access the
> constant on Email, will the reflection call be redirected to
> EmailConstants? There's unit test for ya ;)
>
> Using an interface to define constants is a no-no in my book. I've
> seen
> this discussed before in other places and for a long time, but to
> summarize, I see an interface as defining a contract for a class to
> implement. A constant does not fit.
>
> Constants in interface feels like a hack to provide the short hand
> of a
> class implementing an interface just to be able to access the
> constants
> without qualifying them with a type. Not nice design IMO and a
> dubious us
> of an interface, very Java 1.0. It seems that static imports is
> another
> attempt to solve this desire for a short hand to use constants.
>
> What to do? Move the constants back to their 1.2? What's so bad about
 that?
> Hm...
>
> Make the EmailConstants a class instead of an interface? If binary
> compatible is broken, the constants have to move back, and you can
> still
> have a new EmailConstants class and deprecate the old constants to
> point
 to
> the new class.
>
> Maybe I'll see this more clearly in the AM...
>
> Interested in you all's feedback.
>

 Hi Gary,

 well, I think we go in circles with this change ;-).

 I assumed that this topic is settled after reading the comment from
 sebb in
 the RC2 thread (see http://markmail.org/message/svrb7nf3ocz7lgmd).

 Otoh, it's the first time I see constants in an interface and would
 be in
 favor of reverting to the previous version (also because I do not fully
 understand the rationale behind the change, some of the constants
 are not
 even used and thus have been deprecated).

>>> -- 
>>>

 Maybe we should postpone this kind of refactoring to 2.0 and do it
 then in
 a proper way. Introducing this interface just created headaches and
 I also
 had to disable some checks (e.g. InterfaceIsAType in checkstyle)
 because of
 it.

>>>
>>> That sounds like a good way to go to get 1.3 out the door.
>>
>> Agreed.
>>
>>> Gary
>>>
>>>

 Thomas


> On Tue, Dec 11, 2012 at 5:24 PM, Thomas Neidhart
> wrote:
>
>> Hi,
>>
>> I would like to call a vote from commons-email-1.3 based on RC5.
>>
>> This release candidate has the following changes compared to RC4
>>
>> +) update index and building page with correct information wrt Java
>> compatibility
>> +) update release notes with info on Java compatibility and Clirr
 errors
>> +) fix svn:keywords fo

Re: [VOTE] Release of commons-email-1.3 based on RC5

[Siegfried Goeschl]

Hi Thomas,

there is some code out there using it to build emails based on maps

https://turbine.apache.org/fulcrum/fulcrum-commonsemail/xref/index.html

AFAIK we are free to drop deprecated stuff when doing a minor release - 
which of course breaks binary compatibility.


Cheers,

Siegfried Goeschl

On 12.12.12 21:31, Thomas Neidhart wrote:

On 12/12/2012 08:39 PM, Siegfried Goeschl wrote:

Hi folks,

to avoid the full circles here

* I hopefully fixed the binary compatibility issue, wrote test and also
tested it with my production code

* I moved the constants to EmailConstants because there are many
constants and using an non-trivial implementation class (Email) to
access a few constants is also questionable in my opinion

* The design of commons-email is flawed in a few ways and there is not a
lot you can fix in a major version. So I suggest that we focus on
delivered value instead


Hi Siegfried,

thanks for your feedback.

Taking this into account, together with the posts from sebb and Gary,
imho the best solutions is as sebb proposed:

* Change EmailConstants to a public final class
* Add back the constants to the Email class by referencing them from
   EmailConstants
* Mark the constants in Email as deprecated

btw. there are several constants that have not been in use since the 1.0
release:

 String SENDER_EMAIL = "sender.email";
 String SENDER_NAME = "sender.name";
 String RECEIVER_EMAIL = "receiver.email";
 String RECEIVER_NAME = "receiver.name";
 String EMAIL_SUBJECT = "email.subject";
 String EMAIL_BODY = "email.body";
 String CONTENT_TYPE = "content.type";
 String ATTACHMENTS = "attachments";
 String FILE_SERVER = "file.server";

Does anybody know how or if they are in use? They are now marked as
deprecated, but I am really curious about there origin.

Does everybody agree on wha?

Thomas



Cheers,

Siegfried Goeschl


On 12.12.12 15:06, sebb wrote:

On 12 December 2012 13:17, Gary Gregory  wrote:

On Wed, Dec 12, 2012 at 3:59 AM, Thomas Neidhart
wrote:


On Wed, Dec 12, 2012 at 4:58 AM, Gary Gregory 
wrote:



Thank you for doing another RC.

While I was digging for a justification of the Clirr errors, I
found this
in the release notes: "Clirr reports several errors for this
release due

to

moving constants from the Email class to the newly introduced
EmailConstants interface. These changes are guaranteed to be binary
compatible."

Is it really binary compatible? What if I use reflection to access the
constant on Email, will the reflection call be redirected to
EmailConstants? There's unit test for ya ;)

Using an interface to define constants is a no-no in my book. I've
seen
this discussed before in other places and for a long time, but to
summarize, I see an interface as defining a contract for a class to
implement. A constant does not fit.

Constants in interface feels like a hack to provide the short hand
of a
class implementing an interface just to be able to access the
constants
without qualifying them with a type. Not nice design IMO and a
dubious us
of an interface, very Java 1.0. It seems that static imports is
another
attempt to solve this desire for a short hand to use constants.

What to do? Move the constants back to their 1.2? What's so bad about

that?

Hm...

Make the EmailConstants a class instead of an interface? If binary
compatible is broken, the constants have to move back, and you can
still
have a new EmailConstants class and deprecate the old constants to
point

to

the new class.

Maybe I'll see this more clearly in the AM...

Interested in you all's feedback.



Hi Gary,

well, I think we go in circles with this change ;-).

I assumed that this topic is settled after reading the comment from
sebb in
the RC2 thread (see http://markmail.org/message/svrb7nf3ocz7lgmd).

Otoh, it's the first time I see constants in an interface and would
be in
favor of reverting to the previous version (also because I do not fully
understand the rationale behind the change, some of the constants
are not
even used and thus have been deprecated).


--



Maybe we should postpone this kind of refactoring to 2.0 and do it
then in
a proper way. Introducing this interface just created headaches and
I also
had to disable some checks (e.g. InterfaceIsAType in checkstyle)
because of
it.



That sounds like a good way to go to get 1.3 out the door.


Agreed.


Gary




Thomas



On Tue, Dec 11, 2012 at 5:24 PM, Thomas Neidhart
wrote:


Hi,

I would like to call a vote from commons-email-1.3 based on RC5.

This release candidate has the following changes compared to RC4

+) update index and building page with correct information wrt Java
 compatibility
+) update release notes with info on Java compatibility and Clirr

errors

+) fix svn:keywords for all source files and remove use of $Date$
tags
+) add $Id$ tags for all newly introduced source files in 1.3
+) update javax.mail.mail dependency to 1.4.5
+) fix PMD warnings and add NOPMD comment for false posi

Re: [VOTE] Release of commons-email-1.3 based on RC5

[Gary Gregory]

On Wed, Dec 12, 2012 at 3:31 PM, Thomas Neidhart
wrote:

> On 12/12/2012 08:39 PM, Siegfried Goeschl wrote:
> > Hi folks,
> >
> > to avoid the full circles here
> >
> > * I hopefully fixed the binary compatibility issue, wrote test and also
> > tested it with my production code
> >
> > * I moved the constants to EmailConstants because there are many
> > constants and using an non-trivial implementation class (Email) to
> > access a few constants is also questionable in my opinion
> >
> > * The design of commons-email is flawed in a few ways and there is not a
> > lot you can fix in a major version. So I suggest that we focus on
> > delivered value instead
>
> Hi Siegfried,
>
> thanks for your feedback.
>
> Taking this into account, together with the posts from sebb and Gary,
> imho the best solutions is as sebb proposed:
>
> * Change EmailConstants to a public final class
> * Add back the constants to the Email class by referencing them from
>   EmailConstants
> * Mark the constants in Email as deprecated
>

+1 to these three changes.


>
> btw. there are several constants that have not been in use since the 1.0
> release:
>
> String SENDER_EMAIL = "sender.email";
> String SENDER_NAME = "sender.name";
> String RECEIVER_EMAIL = "receiver.email";
> String RECEIVER_NAME = "receiver.name";
> String EMAIL_SUBJECT = "email.subject";
> String EMAIL_BODY = "email.body";
> String CONTENT_TYPE = "content.type";
> String ATTACHMENTS = "attachments";
> String FILE_SERVER = "file.server";
>
> Does anybody know how or if they are in use? They are now marked as
> deprecated, but I am really curious about there origin.
>

You could add "not in use since..." to the deprecated message.

Gary


>
> Does everybody agree on wha?
>
> Thomas
>
> >
> > Cheers,
> >
> > Siegfried Goeschl
> >
> >
> > On 12.12.12 15:06, sebb wrote:
> >> On 12 December 2012 13:17, Gary Gregory  wrote:
> >>> On Wed, Dec 12, 2012 at 3:59 AM, Thomas Neidhart
> >>> wrote:
> >>>
>  On Wed, Dec 12, 2012 at 4:58 AM, Gary Gregory  > wrote:
> 
> > Thank you for doing another RC.
> >
> > While I was digging for a justification of the Clirr errors, I
> > found this
> > in the release notes: "Clirr reports several errors for this
> > release due
>  to
> > moving constants from the Email class to the newly introduced
> > EmailConstants interface. These changes are guaranteed to be binary
> > compatible."
> >
> > Is it really binary compatible? What if I use reflection to access
> the
> > constant on Email, will the reflection call be redirected to
> > EmailConstants? There's unit test for ya ;)
> >
> > Using an interface to define constants is a no-no in my book. I've
> > seen
> > this discussed before in other places and for a long time, but to
> > summarize, I see an interface as defining a contract for a class to
> > implement. A constant does not fit.
> >
> > Constants in interface feels like a hack to provide the short hand
> > of a
> > class implementing an interface just to be able to access the
> > constants
> > without qualifying them with a type. Not nice design IMO and a
> > dubious us
> > of an interface, very Java 1.0. It seems that static imports is
> > another
> > attempt to solve this desire for a short hand to use constants.
> >
> > What to do? Move the constants back to their 1.2? What's so bad about
>  that?
> > Hm...
> >
> > Make the EmailConstants a class instead of an interface? If binary
> > compatible is broken, the constants have to move back, and you can
> > still
> > have a new EmailConstants class and deprecate the old constants to
> > point
>  to
> > the new class.
> >
> > Maybe I'll see this more clearly in the AM...
> >
> > Interested in you all's feedback.
> >
> 
>  Hi Gary,
> 
>  well, I think we go in circles with this change ;-).
> 
>  I assumed that this topic is settled after reading the comment from
>  sebb in
>  the RC2 thread (see http://markmail.org/message/svrb7nf3ocz7lgmd).
> 
>  Otoh, it's the first time I see constants in an interface and would
>  be in
>  favor of reverting to the previous version (also because I do not
> fully
>  understand the rationale behind the change, some of the constants
>  are not
>  even used and thus have been deprecated).
> 
> >>> --
> >>>
> 
>  Maybe we should postpone this kind of refactoring to 2.0 and do it
>  then in
>  a proper way. Introducing this interface just created headaches and
>  I also
>  had to disable some checks (e.g. InterfaceIsAType in checkstyle)
>  because of
>  it.
> 
> >>>
> >>> That sounds like a good way to go to get 1.3 out the door.
> >>
> >> Agreed.
> >>
> >>> Gary
> >>>
> >>>
> 
>  Thomas
> 
> 
> > On Tue, Dec 

Re: [VOTE] Release of commons-email-1.3 based on RC5

[Gary Gregory]

On Wed, Dec 12, 2012 at 3:40 PM, Siegfried Goeschl  wrote:

> Hi Thomas,
>
> there is some code out there using it to build emails based on maps
>
> https://turbine.apache.org/**fulcrum/fulcrum-commonsemail/**
> xref/index.html
>
> AFAIK we are free to drop deprecated stuff when doing a minor release -
> which of course breaks binary compatibility.
>

I do not think so, not for a minor release. Breaking BC is for major
releases, which also involves a package name and artifact name change, if
we follow what we've done for [lang] and [vfs].

Gary


>
> Cheers,
>
> Siegfried Goeschl
>
>
> On 12.12.12 21:31, Thomas Neidhart wrote:
>
>> On 12/12/2012 08:39 PM, Siegfried Goeschl wrote:
>>
>>> Hi folks,
>>>
>>> to avoid the full circles here
>>>
>>> * I hopefully fixed the binary compatibility issue, wrote test and also
>>> tested it with my production code
>>>
>>> * I moved the constants to EmailConstants because there are many
>>> constants and using an non-trivial implementation class (Email) to
>>> access a few constants is also questionable in my opinion
>>>
>>> * The design of commons-email is flawed in a few ways and there is not a
>>> lot you can fix in a major version. So I suggest that we focus on
>>> delivered value instead
>>>
>>
>> Hi Siegfried,
>>
>> thanks for your feedback.
>>
>> Taking this into account, together with the posts from sebb and Gary,
>> imho the best solutions is as sebb proposed:
>>
>> * Change EmailConstants to a public final class
>> * Add back the constants to the Email class by referencing them from
>>EmailConstants
>> * Mark the constants in Email as deprecated
>>
>> btw. there are several constants that have not been in use since the 1.0
>> release:
>>
>>  String SENDER_EMAIL = "sender.email";
>>  String SENDER_NAME = "sender.name";
>>  String RECEIVER_EMAIL = "receiver.email";
>>  String RECEIVER_NAME = "receiver.name";
>>  String EMAIL_SUBJECT = "email.subject";
>>  String EMAIL_BODY = "email.body";
>>  String CONTENT_TYPE = "content.type";
>>  String ATTACHMENTS = "attachments";
>>  String FILE_SERVER = "file.server";
>>
>> Does anybody know how or if they are in use? They are now marked as
>> deprecated, but I am really curious about there origin.
>>
>> Does everybody agree on wha?
>>
>> Thomas
>>
>>
>>> Cheers,
>>>
>>> Siegfried Goeschl
>>>
>>>
>>> On 12.12.12 15:06, sebb wrote:
>>>
 On 12 December 2012 13:17, Gary Gregory  wrote:

> On Wed, Dec 12, 2012 at 3:59 AM, Thomas Neidhart
> **wrote:
>
>  On Wed, Dec 12, 2012 at 4:58 AM, Gary Gregory >
>>> wrote:
>>>
>>
>>  Thank you for doing another RC.
>>>
>>> While I was digging for a justification of the Clirr errors, I
>>> found this
>>> in the release notes: "Clirr reports several errors for this
>>> release due
>>>
>> to
>>
>>> moving constants from the Email class to the newly introduced
>>> EmailConstants interface. These changes are guaranteed to be binary
>>> compatible."
>>>
>>> Is it really binary compatible? What if I use reflection to access
>>> the
>>> constant on Email, will the reflection call be redirected to
>>> EmailConstants? There's unit test for ya ;)
>>>
>>> Using an interface to define constants is a no-no in my book. I've
>>> seen
>>> this discussed before in other places and for a long time, but to
>>> summarize, I see an interface as defining a contract for a class to
>>> implement. A constant does not fit.
>>>
>>> Constants in interface feels like a hack to provide the short hand
>>> of a
>>> class implementing an interface just to be able to access the
>>> constants
>>> without qualifying them with a type. Not nice design IMO and a
>>> dubious us
>>> of an interface, very Java 1.0. It seems that static imports is
>>> another
>>> attempt to solve this desire for a short hand to use constants.
>>>
>>> What to do? Move the constants back to their 1.2? What's so bad about
>>>
>> that?
>>
>>> Hm...
>>>
>>> Make the EmailConstants a class instead of an interface? If binary
>>> compatible is broken, the constants have to move back, and you can
>>> still
>>> have a new EmailConstants class and deprecate the old constants to
>>> point
>>>
>> to
>>
>>> the new class.
>>>
>>> Maybe I'll see this more clearly in the AM...
>>>
>>> Interested in you all's feedback.
>>>
>>>
>> Hi Gary,
>>
>> well, I think we go in circles with this change ;-).
>>
>> I assumed that this topic is settled after reading the comment from
>> sebb in
>> the RC2 thread (see 
>> http://markmail.org/message/**svrb7nf3ocz7lgmd
>> ).
>>
>> Otoh, it's the first time I see constants in an

Fwd: Re: [VOTE] Release of commons-email-1.3 based on RC5

[Siegfried Goeschl]

 Original Message 
Subject: Re: [VOTE] Release of commons-email-1.3 based on RC5
Date: Wed, 12 Dec 2012 21:49:39 +0100
From: Siegfried Goeschl 
Reply-To: sgoes...@gmx.at
To: Gary Gregory 

Hi Gary,

just checked the Apache site and you are right - no way to remove a
deprecated method using the same major release version

Siegfried Goeschl

On 12.12.12 21:44, Gary Gregory wrote:

On Wed, Dec 12, 2012 at 3:40 PM, Siegfried Goeschl mailto:sgoes...@gmx.at>> wrote:

Hi Thomas,

there is some code out there using it to build emails based on maps

https://turbine.apache.org/__fulcrum/fulcrum-commonsemail/__xref/index.html


AFAIK we are free to drop deprecated stuff when doing a minor
release - which of course breaks binary compatibility.


I do not think so, not for a minor release. Breaking BC is for major
releases, which also involves a package name and artifact name change,
if we follow what we've done for [lang] and [vfs].

Gary


Cheers,

Siegfried Goeschl


On 12.12.12 21:31, Thomas Neidhart wrote:

On 12/12/2012 08:39 PM, Siegfried Goeschl wrote:

Hi folks,

to avoid the full circles here

* I hopefully fixed the binary compatibility issue, wrote
test and also
tested it with my production code

* I moved the constants to EmailConstants because there are many
constants and using an non-trivial implementation class
(Email) to
access a few constants is also questionable in my opinion

* The design of commons-email is flawed in a few ways and
there is not a
lot you can fix in a major version. So I suggest that we
focus on
delivered value instead


Hi Siegfried,

thanks for your feedback.

Taking this into account, together with the posts from sebb and
Gary,
imho the best solutions is as sebb proposed:

* Change EmailConstants to a public final class
* Add back the constants to the Email class by referencing them from
EmailConstants
* Mark the constants in Email as deprecated

btw. there are several constants that have not been in use since
the 1.0
release:

  String SENDER_EMAIL = "sender.email";
  String SENDER_NAME = "sender.name ";
  String RECEIVER_EMAIL = "receiver.email";
  String RECEIVER_NAME = "receiver.name ";
  String EMAIL_SUBJECT = "email.subject";
  String EMAIL_BODY = "email.body";
  String CONTENT_TYPE = "content.type";
  String ATTACHMENTS = "attachments";
  String FILE_SERVER = "file.server";

Does anybody know how or if they are in use? They are now marked as
deprecated, but I am really curious about there origin.

Does everybody agree on wha?

Thomas


Cheers,

Siegfried Goeschl


On 12.12.12 15:06, sebb wrote:

On 12 December 2012 13:17, Gary Gregory
mailto:garydgreg...@gmail.com>>
wrote:

On Wed, Dec 12, 2012 at 3:59 AM, Thomas Neidhart
mailto:thomas.neidh...@gmail.com>>__wrote:

On Wed, Dec 12, 2012 at 4:58 AM, Gary Gregory
mailto:garydgreg...@gmail.com>

wrote:


Thank you for doing another RC.

While I was digging for a justification of
the Clirr errors, I
found this
in the release notes: "Clirr reports several
errors for this
release due

to

moving constants from the Email class to the
newly introduced
EmailConstants interface. These changes are
guaranteed to be binary
compatible."

Is it really binary compatible? What if I
use reflection to access the
constant on Email, will the reflection call
be redirected to
EmailConstants? There's unit test for ya ;)

Using an interface to define constants is a
no-no in my book. I've
seen
this discussed before in other places and
for a long time, but to
summarize, I see an interface as defining a
 

Re: We will not be able to update our websites...

[Ralph Goers]

At the very least, someone should file a Jira asking for a commons-test site.

Ralph

On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:

> On 12/10/12 5:10 PM, Ralph Goers wrote:
>> On Dec 10, 2012, at 4:12 PM, sebb wrote:
>> 
>>> On 10 December 2012 21:53, Phil Steitz  wrote:
 On 12/10/12 1:27 PM, Ralph Goers wrote:
> Yes, I think you are missing something fundamental.
> 
> If you check in "the whole mess" you will never again be able to properly 
> build a sub-project's site with Maven.  This is because the process of 
> updating the site would require first doing a diff and then deleting 
> items that are not included in the new version. Someone created a Maven 
> plugin to try to do this but it is not the way I would want to go at all.
 Sorry, I don't get it.  Why won't the following work:
 
 0) Grab all of, say p.a.o/www/commons.apache.org
 1) check all of that into an svn repo
 2) when I want to update, say, math, I generate the content locally,
 copy it to the /math subtree and check it in.
>>> There would need to be some extra work done to ensure that stale files
>>> are deleted.
> 
> I get it now.  In practice, with maven sites, is this a big deal?  I
> don't remember seeing lots of cruft accumulating on p.a.o, which
> would happen if this were common.  If it is not that common, then
> manual svn rm's would not be that onerous.
> 
> Phil
>>> 
>>> For some projects, it would be possible to just delete the existing
>>> sub-tree and check the whole new site in.
>>> [This can be done as one transaction in svnmucc]
>>> 
>>> However, for sites that retain Javadoc etc. for older releases, one
>>> would need to re-instate that part of the tree somehow.
>>> 
>>> Given that svnpubsub immediately publishes what is checked in, it
>>> might be sensible to have a parallel staging directory tree where
>>> files can be updated piecemeal if necessary, and then use svnmucc to
>>> replace the live component subtree with the staging component subtree
>>> as part of a single transaction.
>>> 
>>> There would need to be some co-ordination between committers when
>>> updating commons parent, as that would affect the whole tree.
>>> 
>> Yes. This is why Logging used the extpath approach where each subproject 
>> commits directly to production. Each release goes to a release subdirectory 
>> under each subproject's directory.  Then you can just perform your maven 
>> site build to a local directory, copy that into the production svn location, 
>> and commit it.
>> 
>> See "Managing the subproject sites" at 
>> http://wiki.apache.org/logging/ManagingTheWebSite
>> 
>> Ralph
> 
> 
> -
> 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

[GUMP@vmgump]: Project commons-dbcp (in module commons-dbcp-1.x) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-dbcp has an issue affecting its community integration.
This issue affects 18 projects,
 and has been outstanding for 71 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbcp :  Object Pooling
- db-ddlutils :  Easy-to-use component for working with Database Definition 
(...
- jakarta-tomcat-4.0 :  Servlet 2.3 and JSP 1.2 Reference Implementation
- jakarta-tomcat-catalina :  Servlet 2.4 Reference Implementation
- jakarta-tomcat-dbcp :  Servlet 2.4 and JSP 2.0 Reference Implementation
- jakarta-tomcat-jk :  Connectors to various web servers
- javax.el :  Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for 
...
- javax.servlet :  Java Servlet 2.5 & Server Pages JSP 2.1 implementation 
(for ...
- javax.servlet.jsp :  Java Servlet 2.5 & Server Pages JSP 2.1 
implementation (for ...
- solr :  Java Based Search Engine
- solr-test :  Java Based Search Engine
- tomcat-tc6 :  Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for 
...
- tomcat-tc7.0.x :  Tomcat 7.x, a web server implementing Java Servlet 3.0,
...
- tomcat-tc7.0.x-dbcp :  Tomcat 7.x, a web server implementing Java Servlet 
3.0,
...
- tomcat-tc7.0.x-test :  Tomcat 7.x, a web server implementing Java Servlet 
3.0,
...
- tomcat-trunk :  Tomcat 8.x, a web server implementing Java Servlet 3.1,
...
- tomcat-trunk-dbcp :  Tomcat 8.x, a web server implementing Java Servlet 
3.1,
...
- tomcat-trunk-test :  Tomcat 8.x, a web server implementing Java Servlet 
3.1,
...


Full details are available at:

http://vmgump.apache.org/gump/public/commons-dbcp-1.x/commons-dbcp/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-dbcp.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-dbcp-1.x/commons-dbcp/gump_work/build_commons-dbcp-1.x_commons-dbcp.html
Work Name: build_commons-dbcp-1.x_commons-dbcp (Type: Build)
Work ended in a state of : Failed
Elapsed: 9 secs
Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only 
-Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
dist 
[Working Directory: /srv/gump/public/workspace/commons-dbcp-1.x]
CLASSPATH: 
/usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/junit/dist/junit-13122012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-13122012.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/srv/gump/public/workspace/commons-pool-1.x/dist/commons-pool-1.6.1-SNAPSHOT.jar
-
[javac]^
[javac]   where T is a type-variable:
[javac] T extends Object declared in method 
getObject(String,Class)
[javac] 
/srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingConnection.java:65:
 error: DelegatingConnection is not abstract and does not override abstract 
method getNetworkTimeout() in Connection
[javac] public class DelegatingConnection extends AbandonedTrace
[javac]^
[javac] 
/srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingDatabaseMetaData.java:38:
 error: DelegatingDatabaseMetaData is not abstract and does not override 
abstract method generatedKeyAlwaysReturned() in DatabaseMetaData
[javac] public class DelegatingDatabaseMetaData extends AbandonedTrace
[javac]^
[javac] 
/srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingResultSet.java:61:
 error: DelegatingResultSet is not abstract and does not override abstract 
method getObject(String,Class) in ResultSet
[javac] public class DelegatingResultSet extends Aban

[GUMP@vmgump]: Project commons-dbcp2 (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-dbcp2 has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 240 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbcp2 :  Database Connection Pool


Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbcp2/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-dbcp2-*[0-9T].jar] identifier set to project 
name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbcp2/gump_work/build_apache-commons_commons-dbcp2.html
Work Name: build_apache-commons_commons-dbcp2 (Type: Build)
Work ended in a state of : Failed
Elapsed: 10 secs
Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only 
-Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
dist 
[Working Directory: /srv/gump/public/workspace/apache-commons/dbcp]
CLASSPATH: 
/usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/apache-commons/dbcp/dist/classes:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/srv/gump/packages/jdbc2_0/jdbc2_0-stdext.jar:/srv/gump/public/workspace/junit/dist/junit-13122012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-13122012.jar:/srv/gump/public/workspace/apache-commons/pool/dist/commons-pool2-2.0-SNAPSHOT.jar
-
[mkdir] Created dir: 
/srv/gump/public/workspace/apache-commons/dbcp/build/classes
[javac] Compiling 52 source files to 
/srv/gump/public/workspace/apache-commons/dbcp/build/classes
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/BasicDataSource.java:52:
 error: BasicDataSource is not abstract and does not override abstract method 
getParentLogger() in CommonDataSource
[javac] public class BasicDataSource implements DataSource {
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingConnection.java:65:
 error: DelegatingConnection is not abstract and does not override abstract 
method getNetworkTimeout() in Connection
[javac] public class DelegatingConnection extends AbandonedTrace
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingStatement.java:46:
 error: DelegatingStatement is not abstract and does not override abstract 
method isCloseOnCompletion() in Statement
[javac] public class DelegatingStatement extends AbandonedTrace implements 
Statement {
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingPreparedStatement.java:57:
 error: DelegatingPreparedStatement is not abstract and does not override 
abstract method isCloseOnCompletion() in Statement
[javac] public class DelegatingPreparedStatement extends DelegatingStatement
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingCallableStatement.java:58:
 error: DelegatingCallableStatement is not abstract and does not override 
abstract method getObject(String,Class) in CallableStatement
[javac] public class DelegatingCallableStatement extends 
DelegatingPreparedStatement
[javac]^
[javac]   where T is a type-variable:
[javac] T extends Object declared in method 
getObject(String,Class)
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingDatabaseMetaData.java:36:
 error: DelegatingDatabaseMetaData is not abstract and does not override 
abstract method generatedKeyAlwaysReturned() in DatabaseMetaData
[javac] public cla

[GUMP@vmgump]: Project commons-digester3 (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-digester3 has an issue affecting its community integration.
This issue affects 2 projects,
 and has been outstanding for 71 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-digester3 :  XML to Java Object Configuration
- commons-digester3-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-digester3-*[0-9T].jar] identifier set to 
project name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/apache-commons/digester/pom.xml
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/gump_work/build_apache-commons_commons-digester3.html
Work Name: build_apache-commons_commons-digester3 (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 3 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings 
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml 
package 
[Working Directory: /srv/gump/public/workspace/apache-commons/digester]
M2_HOME: /opt/maven2
-
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor && svn 
--non-interactive info
[INFO] Working directory: 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildNumber: ?? at timestamp: 1355371959325
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor && svn 
--non-interactive info
[INFO] Working directory: 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 5 source files to 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/classes
[INFO] [bundle:manifest {execution: bundle-manifest}]
[debug] execute contextualize
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/src/test/resources
[INFO] Copying 0 resource to META-INF
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Compiling 3 source files to 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/test-classes
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel")
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel/image")
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel/item")
>
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] error: Impossible to generate class 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule: 
Attempt to recreate a file for type 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[ERROR] error: Impossible to generate class 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule: 
Attempt to recreate a file for type 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[INFO] 2 errors 
[INFO] -
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

error: Impossible to generate class 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule: 
Attempt to recreate a file for type 
org.apache.commons.digester3.a

[GUMP@vmgump]: Project commons-chain2 (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-chain2 has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 262 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-chain2 :  GoF "Chain of Responsibility" pattern


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-chain2-*[0-9T].jar] identifier set to project 
name
 -DEBUG- Sole pom output [pom.xml] identifier set to project name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/chain/pom.xml
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/gump_work/build_apache-commons_commons-chain2.html
Work Name: build_apache-commons_commons-chain2 (Type: Build)
Work ended in a state of : Failed
Elapsed: 59 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/chain]
M2_HOME: /opt/maven2
-
[INFO] Building war: 
/srv/gump/public/workspace/apache-commons/chain/apps/cookbook-examples/target/chain-cookbook-examples-2.0-SNAPSHOT.war
[INFO] 
[INFO] Building Apache Commons Chain :: Distribution Packages
[INFO]task-segment: [package]
[INFO] 
[INFO] snapshot org.apache.commons:commons-chain2-configuration:2.0-SNAPSHOT: 
checking for updates from apache.snapshots
Downloading: 
http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.pom
[INFO] Unable to find resource 
'org.apache.commons:commons-chain2-configuration:pom:2.0-SNAPSHOT' in 
repository apache.snapshots (http://repository.apache.org/snapshots)
Downloading: 
http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.jar
[INFO] Unable to find resource 
'org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT' in 
repository apache.snapshots (http://repository.apache.org/snapshots)
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Failed to resolve artifact.

Missing:
--
1) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.commons 
-DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT 
-Dpackaging=jar -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.apache.commons 
-DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT 
-Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT
2) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT

--
1 required artifact is missing.

for artifact: 
  org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT

from the specified remote repositories:
  gump-central (http://localhost:8192/maven2),
  gump-apache.snapshots (http://localhost:8192/repo/m2-snapshot-repository)



[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 57 seconds
[INFO] Finished at: Thu Dec 13 05:25:27 UTC 2012
[INFO] Final Memory: 114M/241M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/atom

[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-proxy-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 76 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-proxy-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html
Work Name: build_apache-commons_commons-proxy-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 16 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/proxy]
M2_HOME: /opt/maven2
-
Running org.apache.commons.proxy.factory.util.TestMethodSignature
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec

Results :

Tests in error: 
  
testMethodInvocationImplementation(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter)
  
testSerialization(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter)
  
testMethodInterception(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter)
  testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker)
  
testMethodInvocation(org.apache.commons.proxy.invoker.TestInvocationHandlerAdapter)
  
testInterceptorEquals(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerEquals(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorWithSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerWithSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testProxiesWithClashingFinalMethodInSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerHashCode(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testBooleanInterceptorParameter(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testChangingArguments(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testCreateInterceptorProxy(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptingProxyClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptingProxySerializable(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorProxyWithCheckedException(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorProxyWithUncheckedException(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerProxy(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerProxyClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerProxySerializable(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testMethodInvocationClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testMethodInvocationDuplicateMethods(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testMethodInvocationImplementation(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorHashCode(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testWithNonAccessibleTargetType(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  testCreateNullObject(org.apache.commons.proxy.TestProxyUtils)
  testCreateNullObjectWithClassLoader(org.apache.commons.proxy.TestProxyUtils)

Tests run: 179, Failures: 0, Errors: 28, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There 

[GUMP@vmgump]: Project commons-dbutils (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-dbutils has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 240 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbutils :  Commons DbUtils


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-dbutils-*[0-9T].jar] identifier set to 
project name
 -INFO- Optional dependency mockito failed with reason build failed
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/dbutils/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports
 -WARNING- No directory 
[/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/gump_work/build_apache-commons_commons-dbutils.html
Work Name: build_apache-commons_commons-dbutils (Type: Build)
Work ended in a state of : Failed
Elapsed: 16 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/dbutils]
M2_HOME: /opt/maven2
-
1K downloaded  (mockito-core-1.9.0.pom)
Downloading: 
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.pom
479b downloaded  (hamcrest-all-1.1.pom)
Downloading: 
http://localhost:8192/maven2/org/mockito/mockito-core/1.9.0/mockito-core-1.9.0.jar
Downloading: 
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.jar
273K downloaded  (hamcrest-all-1.1.jar)
1381K downloaded  (mockito-core-1.9.0.jar)
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks

main:
 [copy] Copying 2 files to 
/srv/gump/public/workspace/apache-commons/dbutils/target/apidocs/META-INF
[INFO] Executed tasks
[WARNING] The parameter expression: 'project.build.resources' used in mojo: 
'process' has been deprecated. Use 'project.resources' instead.
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/dbutils && svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildNumber: ?? at timestamp: 1355377573665
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/dbutils && svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/srv/gump/public/workspace/apache-commons/dbutils/src/main/resources
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 29 source files to 
/srv/gump/public/workspace/apache-commons/dbutils/target/classes
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
 error: DriverProxy is not abstract and does not override abstract method 
getParentLogger() in Driver
[INFO] 1 error
[INFO] -
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
 error: DriverProxy is not abstract and does not override abstract method 
getParentLogger() in Driver

[INFO] 
[INFO] For more information, run Mav

[GUMP@vmgump]: Project commons-configuration (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-configuration has an issue affecting its community integration.
This issue affects 2 projects,
 and has been outstanding for 93 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-configuration :  Apache Commons
- commons-configuration-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-configuration/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-configuration-*[0-9T].jar] identifier set to 
project name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/apache-commons/configuration/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/configuration/target/surefire-reports
 -WARNING- No directory 
[/srv/gump/public/workspace/apache-commons/configuration/target/surefire-reports]
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-configuration/gump_work/build_apache-commons_commons-configuration.html
Work Name: build_apache-commons_commons-configuration (Type: Build)
Work ended in a state of : Failed
Elapsed: 8 mins 49 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings 
/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml 
package 
[Working Directory: /srv/gump/public/workspace/apache-commons/configuration]
M2_HOME: /opt/maven2
-
Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-components/1.1.20/plexus-components-1.1.20.pom
2K downloaded  (plexus-components-1.1.20.pom)
Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus/3.1/plexus-3.1.pom
18K downloaded  (plexus-3.1.pom)
Downloading: 
http://localhost:8192/maven2/org/sonatype/spice/spice-parent/17/spice-parent-17.pom
6K downloaded  (spice-parent-17.pom)
Downloading: 
http://localhost:8192/maven2/org/sonatype/forge/forge-parent/10/forge-parent-10.pom
13K downloaded  (forge-parent-10.pom)
Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-compiler-manager/1.9.1/plexus-compiler-manager-1.9.1.pom
692b downloaded  (plexus-compiler-manager-1.9.1.pom)
Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-compiler-javac/1.9.1/plexus-compiler-javac-1.9.1.pom
688b downloaded  (plexus-compiler-javac-1.9.1.pom)
Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-compilers/1.9.1/plexus-compilers-1.9.1.pom
1K downloaded  (plexus-compilers-1.9.1.pom)
Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-utils/3.0/plexus-utils-3.0.jar
220K downloaded  (plexus-utils-3.0.jar)
Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-compiler-api/1.9.1/plexus-compiler-api-1.9.1.jar
20K downloaded  (plexus-compiler-api-1.9.1.jar)
Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-compiler-manager/1.9.1/plexus-compiler-manager-1.9.1.jar
4K downloaded  (plexus-compiler-manager-1.9.1.jar)
Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-compiler-javac/1.9.1/plexus-compiler-javac-1.9.1.jar
13K downloaded  (plexus-compiler-javac-1.9.1.jar)
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 159 source files to 
/srv/gump/public/workspace/apache-commons/configuration/target/classes
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/srv/gump/public/workspace/apache-commons/configuration/src/main/java/org/apache/commons/configuration/builder/combined/CombinedBuilderParametersImpl.java:[53,37]
 error: cannot find symbol
[ERROR]   symbol:   variable RESERVED_PARAMETER
  location: class BasicConfigurationBuilder
/srv/gump/public/workspace/apache-commons/configuration/src/main/java/org/apache/commons/configuration/builder/FileBasedBuilderParametersImpl.java:[53,37]
 error: cannot find symbol
[INFO] 2 errors 
[INFO] -
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

/srv/gump/public/workspace/apache-commons/configuration/src/main

[GUMP@vmgump]: Project commons-scxml-test (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-scxml-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 245 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-scxml-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/scxml/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html
Work Name: build_apache-commons_commons-scxml-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 23 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -Dsimplelog.defaultlog=info 
--settings 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/scxml]
M2_HOME: /opt/maven2
-
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1
[INFO] SimpleSCXMLListener - /s2
[INFO] SimpleSCXMLListener - transition (event = s2.1.done, cond = null, from = 
/s2, to = /s3)
[INFO] SimpleSCXMLListener - /s3
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.289 sec
Running org.apache.commons.scxml.issues.Issue64Test
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: somedata
[INFO] SCXMLSemantics - null: *somedata
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from = 
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:30:21
 and digester match "scxml/datamodel/misplaced"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:36:19
 and digester match "scxml/state/onentry/foo"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://my.foo.example/"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:37:22
 and digester match "scxml/state/onentry/bar"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:41:21
 and digester match "scxml/state/transition/datamodel"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:42:41
 and digester match "scxml/state/transition/datamodel/data"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://my.foo.example/"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:49:14
 and digester match "scxml/baz"
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: null
[WARN] SimpleErrorReporter - EXPRESSION_ERROR (eval(''*' + dummy'):null): 
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from = 
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.097 sec

Results :

Failed tests: 
  testCustomActionCallbacks(org.apache.commons.scxml.model.CustomActionTest)

Tests run: 229, Failures: 1, Errors: 0, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO