date:20110211

Re: Fwd: [SCXML] Actionscript SCXML engine

2011-02-11 Thread Gavin Lei

Hey Johan,

Thank you for what you did,  you are the initial committer of this project
and you will always be owner of this project :-)

In my future develop process, may be i will contact with you if i get some
problems. I am sure that your work wasn't wasted

2011/2/11 Johan Roxendal 

>  hey,
>
> yeah, i've been too busy maintaining the python scxml interpreter and the
> actionscript implementation has fallen to the wayside. i'd happily transfer
> full ownership to you, to do with as you please. i'm just happy to see
> scxml4flex mature.
>
> so, um, wasting no time: i'll add you as the project owner and when you
> have access, just remove myself from the owner list.
>
> cool :) i'm glad to see my work wasn't wasted!
> regards,
> johan
>
> On Friday, February 11, 2011 at 5:12 , Gavin Lei wrote:
>
>
>
> -- 已转发邮件 --
> 发件人： Gavin Lei 
> 日期： 2011年2月10日 上午10:29
> 主题： Re: [SCXML] Actionscript SCXML engine
> 收件人： Commons Developers List 
>
>
> Hi Johan,
>
> You have started a good job about ActionScript SCXML engine, but your
> engine implements only small part of SCXML and have not been updated for
> months. So the question is that can we continue developing the engine base
> on your job? I noticed that you project is under LGPL licence. If possible,
> i want to perfect the project instead of developing a bran-new project. So,
> i want to know, can i improve the project and hold it as a Google Summer of
> Code under Apache 2.0 Licence?
>
> 2011/1/31 Johan Roxendal 
>
>  hey,
>
> I applaude the ambition, but I see little sense in doing this from scratch
> �C have a look at http://code.google.com/p/scxml4flex/ first. I actually
> spent quite some time writing that code, and now it's been sitting there for
> a few months while I develop its sister project in Python at
> http://code.google.com/p/pyscxml/ instead. but I actually made it quite
> far on the actionscript implementation!
>
> all the core functionality works, as well as the script tag, invoke
> (type="scxml" and invoking soap webservices). by no means do we have full
> coverage yet, but it's not too shabby, if I may say so myself.
>
> you'll find that I used it to write my thesis, located at
> http://code.google.com/p/pyscxml/downloads/detail?name=exjobb_johan_roxendal.pdf&can=2&q=
>
> in there you can read more about its capabilities. and check out the
> example at:
>
> http://scxml-example.appspot.com/static/menu/MenuExample.html
>
> where the library is used, in all its glory.
>
> / Johan Roxendal
>
>
>
>
> --
> -
> Best Regards
> Gavin Lei (雷银)
> Email: gavingui2...@gmail.com
>
>
>
> --
> -
> Best Regards
> Gavin Lei (雷银)
> Email: gavingui2...@gmail.com
>
>
>


-- 
-
Best Regards
Gavin Lei (雷银)
Email: gavingui2...@gmail.com

[attributes] Gump failure after qdox update

2011-02-11 Thread Stefan Bodewig

On 2011-02-11, Gump wrote:

> [javac] 
> /srv/gump/public/workspace/apache-commons/attributes/compiler/src/java/org/apache/commons/attributes/compiler/AttributeCompiler.java:245:
>  incompatible types
> [javac] found   : com.thoughtworks.qdox.model.JavaPackage
> [javac] required: java.lang.String
> [javac] packageName = javaClass.getPackage ();
> [javac]^

This started when I upgraded Gump's version of qdox from 1.6 to 1.12
('cause FOP needed the newer version).

IIUC there hasn't been any change in attributes for two years so I'm not
sure what to do with it.  Try to adapt attributes to a newer qdox?
Provide the old qdox to attributes in Gump so it can build even though
no other project in Gump needs it?  Remove attributes from Gump?

Any ideas?

Stefan

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

[lang] propse new ObjectExistsException extends IllegalArgumentException

2011-02-11 Thread thomas menzel

hi,

i suggest a new exception under the commons.lang.exception namely  

ObjectExistsException extends IllegalArgumentException.

in the jpa world there is already one like this, bit i think it has merit for 
also other cases outside of jpa and hence i would like to see it defined in 
apache's commons.lang.exception.

what do u think?

-- 
NEU: FreePhone - kostenlos mobil telefonieren und surfen!   
Jetzt informieren: http://www.gmx.net/de/go/freephone

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

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

2011-02-11 Thread 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 77 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: 19 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --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
-

---
 T E S T S
---
Running org.apache.commons.scxml.invoke.InvokeTestSuite
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.542 sec
Running org.apache.commons.scxml.test.TestingTestSuite
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.017 sec
Running org.apache.commons.scxml.env.EnvTestSuite
Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.149 sec
Running org.apache.commons.scxml.SCXMLTestSuite
Tests run: 71, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.918 sec <<< 
FAILURE!
Running org.apache.commons.scxml.issues.IssuesTestSuite
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
Running org.apache.commons.scxml.model.ModelTestSuite
Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.369 sec <<< 
FAILURE!
Running org.apache.commons.scxml.env.faces.EnvFacesTestSuite
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Running org.apache.commons.scxml.semantics.SemanticsTestSuite
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.commons.scxml.env.jsp.EnvJspTestSuite
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.038 sec
Running org.apache.commons.scxml.env.jexl.EnvJexlTestSuite
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 sec
Running org.apache.commons.scxml.env.servlet.EnvServletTestSuite
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.scxml.io.IOTestSuite
Tests run: 30, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.355 sec

Results :

Failed tests: 
  
testNamespacePrefixedXPathsEL(org.apache.commons.scxml.NamespacePrefixedXPathsTest)
  testDatamodelSimultaneousJsp(org.apache.commons.scxml.model.DatamodelTest)

Tests run: 228, Failures: 2, Errors: 0, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.

Please refer to 
/srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 18 seconds
[INFO] Finished at: Fri Feb 11 09:35:06 UTC 2011
[INFO] Final Memory: 25M/61M
[INFO] 
-

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

== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 06000611022011, vmgump.apache.org:vmgump:06000611022011
Gump E-mail Identifier (unique wit

[GUMP@vmgump]: Project commons-jelly-tags-quartz (in module commons-jelly) failed

2011-02-11 Thread 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-jelly-tags-quartz has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 5 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-quartz :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-quartz/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-jelly-tags-quartz-11022011.jar] identifier 
set to project name
 -DEBUG- Dependency on logging-log4j-12 exists, no need to add for property 
maven.jar.log4j.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -DEBUG- Dependency on commons-jexl-1.x exists, no need to add for property 
maven.jar.commons-jexl.
 -DEBUG- (Apache Gump generated) Apache Maven Properties in: 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/project.xml
 -DEBUG- Maven project properties in: 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/project.properties
 -INFO- Project Reports in: 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/test-reports
 -WARNING- No directory 
[/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/test-reports]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-quartz/gump_work/build_commons-jelly_commons-jelly-tags-quartz.html
Work Name: build_commons-jelly_commons-jelly-tags-quartz (Type: Build)
Work ended in a state of : Failed
Elapsed: 5 secs
Command Line: maven --offline jar 
[Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz]
-
java:compile:
[echo] Compiling to 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/classes
[javac] Compiling 7 source files to 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/classes
[javac] 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:198:
 org.quartz.CronTrigger is abstract; cannot be instantiated
[javac] CronTrigger trigger = new CronTrigger( getName(),
[javac]   ^
[javac] 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:201:
 cannot find symbol
[javac] symbol  : method setCronExpression(java.lang.String)
[javac] location: interface org.quartz.CronTrigger
[javac] trigger.setCronExpression( getSpec() );
[javac]^
[javac] 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:206:
 cannot find symbol
[javac] symbol  : method setJobName(java.lang.String)
[javac] location: interface org.quartz.CronTrigger
[javac] trigger.setJobName( getJobName() );
[javac]^
[javac] 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:207:
 cannot find symbol
[javac] symbol  : method setJobGroup(java.lang.String)
[javac] location: interface org.quartz.CronTrigger
[javac] trigger.setJobGroup( getJobGroup() );
[javac]^
[javac] 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:208:
 cannot find symbol
[javac] symbol  : method setStartTime(java.util.Date)
[javac] location: interface org.quartz.CronTrigger
[javac] trigger.setStartTime( new Date() );
[javac]^
[javac] 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/JobTag.java:118:
 org.quartz.JobDetail is abstract; cannot be instantiated
[javac] JobDetail detail = new JobDetail( getName(),
[javac]^
[javac] 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/JobTag.java:122:
 cannot find symbol
[javac] symbol  : method setDurability(boolean)
[javac] location: interface org.quartz.JobDetail
[javac] detail.setDurability( true );
[javac]   ^
[javac]

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

2011-02-11 Thread 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 77 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: 11 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
-
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.factory.util.TestMethodSignature
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.commons.proxy.provider.TestConstantProvider
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec
Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec
Running org.apache.commons.proxy.interceptor.TestInterceptorChain
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Running org.apache.commons.proxy.invoker.TestNullInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec
Running org.apache.commons.proxy.exception.TestDelegateProviderException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.invoker.TestChainInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory
Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.17 sec
Running org.apache.commons.proxy.exception.TestProxyFactoryException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.commons.proxy.provider.TestBeanProvider
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.025 sec

Results :

Tests in error: 
  testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker)

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

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.

Please refer to 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 10 seconds
[INFO] Finished at: Fri Feb 11 10:12:20 UTC 2011
[INFO] Final Memory: 24M/58M
[INFO] 
-

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

Re: [lang] propse new ObjectExistsException extends IllegalArgumentException

2011-02-11 Thread Simone Tripodi

Hi Thomas,
can you describe please in which non-JPA context the exception can
become useful?
Many thanks in advance, have a nice day,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Fri, Feb 11, 2011 at 10:31 AM, thomas menzel  wrote:
> hi,
>
> i suggest a new exception under the commons.lang.exception namely
>
> ObjectExistsException extends IllegalArgumentException.
>
> in the jpa world there is already one like this, bit i think it has merit for 
> also other cases outside of jpa and hence i would like to see it defined in 
> apache's commons.lang.exception.
>
> what do u think?
>
> --
> NEU: FreePhone - kostenlos mobil telefonieren und surfen!
> Jetzt informieren: http://www.gmx.net/de/go/freephone
>
> -
> 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: [lang] propse new ObjectExistsException extends IllegalArgumentException

2011-02-11 Thread Henri Yandell

To define a bar on exceptions; they need to be used by Commons Lang.
In 3.0 we've dropped the "this would be a better name for an
exception" exceptions as it's too easy for that to grow and grow.

Hen

On Fri, Feb 11, 2011 at 6:01 AM, Simone Tripodi
 wrote:
> Hi Thomas,
> can you describe please in which non-JPA context the exception can
> become useful?
> Many thanks in advance, have a nice day,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Fri, Feb 11, 2011 at 10:31 AM, thomas menzel  
> wrote:
>> hi,
>>
>> i suggest a new exception under the commons.lang.exception namely
>>
>> ObjectExistsException extends IllegalArgumentException.
>>
>> in the jpa world there is already one like this, bit i think it has merit 
>> for also other cases outside of jpa and hence i would like to see it defined 
>> in apache's commons.lang.exception.
>>
>> what do u think?
>>
>> --
>> NEU: FreePhone - kostenlos mobil telefonieren und surfen!
>> Jetzt informieren: http://www.gmx.net/de/go/freephone
>>
>> -
>> 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: [attributes] Gump failure after qdox update

2011-02-11 Thread Rahul Akolkar

On Fri, Feb 11, 2011 at 3:55 AM, Stefan Bodewig  wrote:
> On 2011-02-11, Gump wrote:
>
>>     [javac] 
>> /srv/gump/public/workspace/apache-commons/attributes/compiler/src/java/org/apache/commons/attributes/compiler/AttributeCompiler.java:245:
>>  incompatible types
>>     [javac] found   : com.thoughtworks.qdox.model.JavaPackage
>>     [javac] required: java.lang.String
>>     [javac]         packageName = javaClass.getPackage ();
>>     [javac]                                            ^
>
> This started when I upgraded Gump's version of qdox from 1.6 to 1.12
> ('cause FOP needed the newer version).
>
> IIUC there hasn't been any change in attributes for two years so I'm not
> sure what to do with it.  Try to adapt attributes to a newer qdox?
> Provide the old qdox to attributes in Gump so it can build even though
> no other project in Gump needs it?  Remove attributes from Gump?
>
> Any ideas?
>


If no one shows interest in helping you with this, then I think we can
move attributes from proper to dormant and remove it from Gump.

-Rahul


> Stefan
>

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

Re: [attributes] Gump failure after qdox update

2011-02-11 Thread sebb

On 11 February 2011 16:36, Rahul Akolkar  wrote:
> On Fri, Feb 11, 2011 at 3:55 AM, Stefan Bodewig  wrote:
>> On 2011-02-11, Gump wrote:
>>
>>>     [javac] 
>>> /srv/gump/public/workspace/apache-commons/attributes/compiler/src/java/org/apache/commons/attributes/compiler/AttributeCompiler.java:245:
>>>  incompatible types
>>>     [javac] found   : com.thoughtworks.qdox.model.JavaPackage
>>>     [javac] required: java.lang.String
>>>     [javac]         packageName = javaClass.getPackage ();
>>>     [javac]                                            ^
>>
>> This started when I upgraded Gump's version of qdox from 1.6 to 1.12
>> ('cause FOP needed the newer version).
>>
>> IIUC there hasn't been any change in attributes for two years so I'm not
>> sure what to do with it.  Try to adapt attributes to a newer qdox?
>> Provide the old qdox to attributes in Gump so it can build even though
>> no other project in Gump needs it?  Remove attributes from Gump?
>>
>> Any ideas?
>>
> 
>
> If no one shows interest in helping you with this, then I think we can
> move attributes from proper to dormant and remove it from Gump.

+1

I've not used Attributes so I could be completely wrong, but it looks
very much like Java 5 annotations mean that there is little need for
the component now.

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

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

Re: [attributes] Gump failure after qdox update

2011-02-11 Thread Simone Tripodi

my 0.02cents: I'm +1 on moving Attributes to dormant, since it aimed
provide an Java5 Annotation for VM that didn't support at all.
since it proved to be stable enough - Cedric Beust uses it on TestNG
library - there's no reason to continue be maintained for the reasons
explained by Sebastian.
Have a nice day, all the best,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Fri, Feb 11, 2011 at 5:49 PM, sebb  wrote:
> On 11 February 2011 16:36, Rahul Akolkar  wrote:
>> On Fri, Feb 11, 2011 at 3:55 AM, Stefan Bodewig  wrote:
>>> On 2011-02-11, Gump wrote:
>>>
     [javac] 
 /srv/gump/public/workspace/apache-commons/attributes/compiler/src/java/org/apache/commons/attributes/compiler/AttributeCompiler.java:245:
  incompatible types
     [javac] found   : com.thoughtworks.qdox.model.JavaPackage
     [javac] required: java.lang.String
     [javac]         packageName = javaClass.getPackage ();
     [javac]                                            ^
>>>
>>> This started when I upgraded Gump's version of qdox from 1.6 to 1.12
>>> ('cause FOP needed the newer version).
>>>
>>> IIUC there hasn't been any change in attributes for two years so I'm not
>>> sure what to do with it.  Try to adapt attributes to a newer qdox?
>>> Provide the old qdox to attributes in Gump so it can build even though
>>> no other project in Gump needs it?  Remove attributes from Gump?
>>>
>>> Any ideas?
>>>
>> 
>>
>> If no one shows interest in helping you with this, then I think we can
>> move attributes from proper to dormant and remove it from Gump.
>
> +1
>
> I've not used Attributes so I could be completely wrong, but it looks
> very much like Java 5 annotations mean that there is little need for
> the component now.
>
>> -Rahul
>>
>>
>>> Stefan
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

[math] the 2.2 release saga conclusion ?

2011-02-11 Thread Luc Maisonobe

Hi all,

I would like to have 2.2 out as soon as possible. I would like to
propose yet another intermediate solution, not a perfect one, but trying
to mitigate everything that has been said here. Remember this is *only*
for 2.2 and it does *not* mean anything about 3.0 or any further
discussions.

So I propose we release 2.2 with the following changes relative to what
is currently in the repository:

 - change FunctionEvaluationException, DerivativeException and
   MatrixVisitorException to unchecked again by making them
   extend o.a.c.math.exception.MathUserException
 - change ConvergenceException to unchecked by making it extend
   o.a.c.math.exception.MathIllegalStateException
 - undeprecate all these exceptions
 - accept the 17 CLIRR errors remaining after these changes
   (13 related to exceptions, 4 related to ODE)
 - accept the 30 CLIRR warnings remaining after these changes
   (all of them related to exceptions)
 - accept the 422 CLIRR infos remaining after these changes

This is by no means a perfect solution, I really tried to reach a
compromise between several points of view. As each compromise, everyone
would have something to tell against it but please don't start another
lengthy discussion and even less a flame war. There is no hidden
intention behind this and the choices presented would be put only in 2.2
branch, not in trunk. The only intention is to be able to publish 2.2.

What do you think ?

Luc

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

Re: [math] the 2.2 release saga conclusion ?

2011-02-11 Thread Mikkel Meyer Andersen

Hi Luc,

+1
Thanks for the constructive post. I agree with the compromise although I
don't have the entire outlook of pros and cons.

Cheers, Mikkel.
Den 11/02/2011 18.50 skrev "Luc Maisonobe" :
> Hi all,
>
> I would like to have 2.2 out as soon as possible. I would like to
> propose yet another intermediate solution, not a perfect one, but trying
> to mitigate everything that has been said here. Remember this is *only*
> for 2.2 and it does *not* mean anything about 3.0 or any further
> discussions.
>
> So I propose we release 2.2 with the following changes relative to what
> is currently in the repository:
>
> - change FunctionEvaluationException, DerivativeException and
> MatrixVisitorException to unchecked again by making them
> extend o.a.c.math.exception.MathUserException
> - change ConvergenceException to unchecked by making it extend
> o.a.c.math.exception.MathIllegalStateException
> - undeprecate all these exceptions
> - accept the 17 CLIRR errors remaining after these changes
> (13 related to exceptions, 4 related to ODE)
> - accept the 30 CLIRR warnings remaining after these changes
> (all of them related to exceptions)
> - accept the 422 CLIRR infos remaining after these changes
>
> This is by no means a perfect solution, I really tried to reach a
> compromise between several points of view. As each compromise, everyone
> would have something to tell against it but please don't start another
> lengthy discussion and even less a flame war. There is no hidden
> intention behind this and the choices presented would be put only in 2.2
> branch, not in trunk. The only intention is to be able to publish 2.2.
>
> What do you think ?
>
> Luc
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

Re: [math] the 2.2 release saga conclusion ?

2011-02-11 Thread Phil Steitz

On 2/11/11 12:49 PM, Luc Maisonobe wrote:
> Hi all,
>
> I would like to have 2.2 out as soon as possible. I would like to
> propose yet another intermediate solution, not a perfect one, but trying
> to mitigate everything that has been said here. Remember this is *only*
> for 2.2 and it does *not* mean anything about 3.0 or any further
> discussions.
>
> So I propose we release 2.2 with the following changes relative to what
> is currently in the repository:
>
>  - change FunctionEvaluationException, DerivativeException and
>MatrixVisitorException to unchecked again by making them
>extend o.a.c.math.exception.MathUserException
>  - change ConvergenceException to unchecked by making it extend
>o.a.c.math.exception.MathIllegalStateException
>  - undeprecate all these exceptions
>  - accept the 17 CLIRR errors remaining after these changes
>(13 related to exceptions, 4 related to ODE)
>  - accept the 30 CLIRR warnings remaining after these changes
>(all of them related to exceptions)
>  - accept the 422 CLIRR infos remaining after these changes
>
> This is by no means a perfect solution, I really tried to reach a
> compromise between several points of view. As each compromise, everyone
> would have something to tell against it but please don't start another
> lengthy discussion and even less a flame war. There is no hidden
> intention behind this and the choices presented would be put only in 2.2
> branch, not in trunk. The only intention is to be able to publish 2.2.
>
> What do you think ?
>
Can you create a Clirr report showing the issues above and put it in
~luc so we can all look at it?

Also, what would it take to fully eliminate the exceptions-related
errors?

Phil
> Luc
>
> -
> 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] the 2.2 release saga conclusion ?

2011-02-11 Thread Luc Maisonobe

Le 11/02/2011 19:07, Phil Steitz a écrit :
> On 2/11/11 12:49 PM, Luc Maisonobe wrote:
>> Hi all,
>>
>> I would like to have 2.2 out as soon as possible. I would like to
>> propose yet another intermediate solution, not a perfect one, but trying
>> to mitigate everything that has been said here. Remember this is *only*
>> for 2.2 and it does *not* mean anything about 3.0 or any further
>> discussions.
>>
>> So I propose we release 2.2 with the following changes relative to what
>> is currently in the repository:
>>
>>  - change FunctionEvaluationException, DerivativeException and
>>MatrixVisitorException to unchecked again by making them
>>extend o.a.c.math.exception.MathUserException
>>  - change ConvergenceException to unchecked by making it extend
>>o.a.c.math.exception.MathIllegalStateException
>>  - undeprecate all these exceptions
>>  - accept the 17 CLIRR errors remaining after these changes
>>(13 related to exceptions, 4 related to ODE)
>>  - accept the 30 CLIRR warnings remaining after these changes
>>(all of them related to exceptions)
>>  - accept the 422 CLIRR infos remaining after these changes
>>
>> This is by no means a perfect solution, I really tried to reach a
>> compromise between several points of view. As each compromise, everyone
>> would have something to tell against it but please don't start another
>> lengthy discussion and even less a flame war. There is no hidden
>> intention behind this and the choices presented would be put only in 2.2
>> branch, not in trunk. The only intention is to be able to publish 2.2.
>>
>> What do you think ?
>>
> Can you create a Clirr report showing the issues above and put it in
> ~luc so we can all look at it?

Yes, I have put it there:
.

> 
> Also, what would it take to fully eliminate the exceptions-related
> errors?

This would mean going back to checked exception as most errors are
"Removed org.apache.commons.math.MathException from the list of
superclasses"

Luc

> 
> Phil
>> Luc
>>
>> -
>> 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: [math] the 2.2 release saga conclusion ?

2011-02-11 Thread sebb

On 11 February 2011 18:53, Luc Maisonobe  wrote:
> Le 11/02/2011 19:07, Phil Steitz a écrit :
>> On 2/11/11 12:49 PM, Luc Maisonobe wrote:
>>> Hi all,
>>>
>>> I would like to have 2.2 out as soon as possible. I would like to
>>> propose yet another intermediate solution, not a perfect one, but trying
>>> to mitigate everything that has been said here. Remember this is *only*
>>> for 2.2 and it does *not* mean anything about 3.0 or any further
>>> discussions.
>>>
>>> So I propose we release 2.2 with the following changes relative to what
>>> is currently in the repository:
>>>
>>>  - change FunctionEvaluationException, DerivativeException and
>>>    MatrixVisitorException to unchecked again by making them
>>>    extend o.a.c.math.exception.MathUserException
>>>  - change ConvergenceException to unchecked by making it extend
>>>    o.a.c.math.exception.MathIllegalStateException
>>>  - undeprecate all these exceptions
>>>  - accept the 17 CLIRR errors remaining after these changes
>>>    (13 related to exceptions, 4 related to ODE)
>>>  - accept the 30 CLIRR warnings remaining after these changes
>>>    (all of them related to exceptions)
>>>  - accept the 422 CLIRR infos remaining after these changes
>>>
>>> This is by no means a perfect solution, I really tried to reach a
>>> compromise between several points of view. As each compromise, everyone
>>> would have something to tell against it but please don't start another
>>> lengthy discussion and even less a flame war. There is no hidden
>>> intention behind this and the choices presented would be put only in 2.2
>>> branch, not in trunk. The only intention is to be able to publish 2.2.
>>>
>>> What do you think ?
>>>
>> Can you create a Clirr report showing the issues above and put it in
>> ~luc so we can all look at it?
>
> Yes, I have put it there:
> .
>
>>
>> Also, what would it take to fully eliminate the exceptions-related
>> errors?
>
> This would mean going back to checked exception as most errors are
> "Removed org.apache.commons.math.MathException from the list of
> superclasses"

BTW, I have run the 2.1 test cases against the current 2.2 code.
There are a lot of errors and failures. Many of them relate to the
changes in exception hierarchy - e.g. expecting MathException, actual
NullArgumentException.

Some are obviously OK, e.g. the following fails:
   assertFalse(ex.getMessage().equals(ex.getMessage(Locale.FRENCH)));
[Not sure that was a safe test anyway - suppose the default Locale was FRENCH?]

However, there are also errors in MathUtils (e.g. changes in equals methods).
I'm not sure it's a good idea to change the behaviour in a point
release, unless the current behaviour is obviously incorrect.
The behaviour wrt NaNs has been changed, and it no longer agrees with
the Javadoc for 2.1.
I think in this case it would be safer to introduce the new
equalsIncludingNaN() methods, but keep the old equals() method
behaviour.
Otherwise user code may break - as does the test code.

Sorry, I realise that I should have brought this up a long while ago,
but I was not really following the changes initially.

> Luc
>
>>
>> Phil
>>> Luc
>>>
>>> -
>>> 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
>
>

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

Re: [math] the 2.2 release saga conclusion ?

2011-02-11 Thread Phil Steitz

On 2/11/11 1:53 PM, Luc Maisonobe wrote:
> Le 11/02/2011 19:07, Phil Steitz a écrit :
>> On 2/11/11 12:49 PM, Luc Maisonobe wrote:
>>> Hi all,
>>>
>>> I would like to have 2.2 out as soon as possible. I would like to
>>> propose yet another intermediate solution, not a perfect one, but trying
>>> to mitigate everything that has been said here. Remember this is *only*
>>> for 2.2 and it does *not* mean anything about 3.0 or any further
>>> discussions.
>>>
>>> So I propose we release 2.2 with the following changes relative to what
>>> is currently in the repository:
>>>
>>>  - change FunctionEvaluationException, DerivativeException and
>>>MatrixVisitorException to unchecked again by making them
>>>extend o.a.c.math.exception.MathUserException
>>>  - change ConvergenceException to unchecked by making it extend
>>>o.a.c.math.exception.MathIllegalStateException
>>>  - undeprecate all these exceptions
>>>  - accept the 17 CLIRR errors remaining after these changes
>>>(13 related to exceptions, 4 related to ODE)
>>>  - accept the 30 CLIRR warnings remaining after these changes
>>>(all of them related to exceptions)
>>>  - accept the 422 CLIRR infos remaining after these changes
>>>
>>> This is by no means a perfect solution, I really tried to reach a
>>> compromise between several points of view. As each compromise, everyone
>>> would have something to tell against it but please don't start another
>>> lengthy discussion and even less a flame war. There is no hidden
>>> intention behind this and the choices presented would be put only in 2.2
>>> branch, not in trunk. The only intention is to be able to publish 2.2.
>>>
>>> What do you think ?
>>>
>> Can you create a Clirr report showing the issues above and put it in
>> ~luc so we can all look at it?
> Yes, I have put it there:
> .
>
>> Also, what would it take to fully eliminate the exceptions-related
>> errors?
> This would mean going back to checked exception as most errors are
> "Removed org.apache.commons.math.MathException from the list of
> superclasses"
So from the user perspective, the compatibility issue is that code
that catches MathException will in some cases propagate runtime
exceptions instead.   This sounds ridiculous, but what would be the
implications of just reverting the hierarchy so catching
MathException would work as before, but make MathException itself
unchecked?

Sorry if this seems to be walking into the kind of discussion you
did not want to reopen at this point; but I am just trying to see
what we might be able to do to prevent users having to make code
changes to have their apps that use 2.1 work safely in 2.2.

I will add at this point that if we just s/2.2/3.0 and s/3.0/4.0, I
am fine releasing as is.

Phil
> Luc
>
>> Phil
>>> Luc
>>>
>>> -
>>> 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
>
>


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

Re: [math] the 2.2 release saga conclusion ?

2011-02-11 Thread Luc Maisonobe

Le 11/02/2011 20:23, Phil Steitz a écrit :
> On 2/11/11 1:53 PM, Luc Maisonobe wrote:
>> Le 11/02/2011 19:07, Phil Steitz a écrit :
>>> On 2/11/11 12:49 PM, Luc Maisonobe wrote:
 Hi all,

 I would like to have 2.2 out as soon as possible. I would like to
 propose yet another intermediate solution, not a perfect one, but trying
 to mitigate everything that has been said here. Remember this is *only*
 for 2.2 and it does *not* mean anything about 3.0 or any further
 discussions.

 So I propose we release 2.2 with the following changes relative to what
 is currently in the repository:

  - change FunctionEvaluationException, DerivativeException and
MatrixVisitorException to unchecked again by making them
extend o.a.c.math.exception.MathUserException
  - change ConvergenceException to unchecked by making it extend
o.a.c.math.exception.MathIllegalStateException
  - undeprecate all these exceptions
  - accept the 17 CLIRR errors remaining after these changes
(13 related to exceptions, 4 related to ODE)
  - accept the 30 CLIRR warnings remaining after these changes
(all of them related to exceptions)
  - accept the 422 CLIRR infos remaining after these changes

 This is by no means a perfect solution, I really tried to reach a
 compromise between several points of view. As each compromise, everyone
 would have something to tell against it but please don't start another
 lengthy discussion and even less a flame war. There is no hidden
 intention behind this and the choices presented would be put only in 2.2
 branch, not in trunk. The only intention is to be able to publish 2.2.

 What do you think ?

>>> Can you create a Clirr report showing the issues above and put it in
>>> ~luc so we can all look at it?
>> Yes, I have put it there:
>> .
>>
>>> Also, what would it take to fully eliminate the exceptions-related
>>> errors?
>> This would mean going back to checked exception as most errors are
>> "Removed org.apache.commons.math.MathException from the list of
>> superclasses"
> So from the user perspective, the compatibility issue is that code
> that catches MathException will in some cases propagate runtime
> exceptions instead.   This sounds ridiculous, but what would be the
> implications of just reverting the hierarchy so catching
> MathException would work as before, but make MathException itself
> unchecked?

This could be done. I sincerely simply did not think about it.

> 
> Sorry if this seems to be walking into the kind of discussion you
> did not want to reopen at this point; but I am just trying to see
> what we might be able to do to prevent users having to make code
> changes to have their apps that use 2.1 work safely in 2.2.

I would say we can't do anything. There are the ODE changes which are
flagged as errors by CLIRR even for things which clearly do not belong
to the public API like private fields having been replaced. There are
also the 2.1 tests that Sebb checked against 2.2 and which fail due to
other changes which are not flagged at all by CLIRR because they are
semantic changes.

> 
> I will add at this point that if we just s/2.2/3.0 and s/3.0/4.0, I
> am fine releasing as is.

2.2 *is* a clumsy version, so promoting it to 3.0 would be really a bad
idea as it would imply telling to users « we have done great changes,
look at them » to only change everything again.

Current 3.0 is more in line with what we want. It will certainly not be
perfect either, but much better.

So rather than patching this mess once again, we could simply drop 2.2
completely and concentrate our efforts in 3.0 to be able to publish it
soon. However, this is not an easy decision. As some of you already
know, and as Gary said in his interview recently, we have some great
news to publish about some uses of [math]. Dropping 2.2 and waiting
months for 3.0 would be really really bad for this.

The alternative is therefore:
 - do we publish a 2.2 that is clumsy but fixes many important bugs
   and introduces some incompatibilities
 - do we consider we can publish 3.0 in the next two months so we
   can afford dropping 2.2

Please, choose one option and stick to it. I am exhausted and depressed,
I don't want to argue anymore.

Luc

> 
> Phil
>> Luc
>>
>>> Phil
 Luc

 -
 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
>> F

Re: [math] the 2.2 release saga conclusion ?

2011-02-11 Thread Paul Benedict

I believe re-organizing the exception hierarchy is a great feature for a
major release. For minor releases, avoid refactoring that would break
current code.

Paul

On Fri, Feb 11, 2011 at 1:23 PM, Phil Steitz  wrote:

> So from the user perspective, the compatibility issue is that code
> that catches MathException will in some cases propagate runtime
> exceptions instead.   This sounds ridiculous, but what would be the
> implications of just reverting the hierarchy so catching
> MathException would work as before, but make MathException itself
> unchecked?
>
> Sorry if this seems to be walking into the kind of discussion you
> did not want to reopen at this point; but I am just trying to see
> what we might be able to do to prevent users having to make code
> changes to have their apps that use 2.1 work safely in 2.2.
>
> I will add at this point that if we just s/2.2/3.0 and s/3.0/4.0, I
> am fine releasing as is.
>
> Phil
>

Re: [math] the 2.2 release saga conclusion ?

2011-02-11 Thread Phil Steitz

On 2/11/11 3:03 PM, Luc Maisonobe wrote:
> Le 11/02/2011 20:23, Phil Steitz a écrit :
>> On 2/11/11 1:53 PM, Luc Maisonobe wrote:
>>> Le 11/02/2011 19:07, Phil Steitz a écrit :
 On 2/11/11 12:49 PM, Luc Maisonobe wrote:
> Hi all,
>
> I would like to have 2.2 out as soon as possible. I would like to
> propose yet another intermediate solution, not a perfect one, but trying
> to mitigate everything that has been said here. Remember this is *only*
> for 2.2 and it does *not* mean anything about 3.0 or any further
> discussions.
>
> So I propose we release 2.2 with the following changes relative to what
> is currently in the repository:
>
>  - change FunctionEvaluationException, DerivativeException and
>MatrixVisitorException to unchecked again by making them
>extend o.a.c.math.exception.MathUserException
>  - change ConvergenceException to unchecked by making it extend
>o.a.c.math.exception.MathIllegalStateException
>  - undeprecate all these exceptions
>  - accept the 17 CLIRR errors remaining after these changes
>(13 related to exceptions, 4 related to ODE)
>  - accept the 30 CLIRR warnings remaining after these changes
>(all of them related to exceptions)
>  - accept the 422 CLIRR infos remaining after these changes
>
> This is by no means a perfect solution, I really tried to reach a
> compromise between several points of view. As each compromise, everyone
> would have something to tell against it but please don't start another
> lengthy discussion and even less a flame war. There is no hidden
> intention behind this and the choices presented would be put only in 2.2
> branch, not in trunk. The only intention is to be able to publish 2.2.
>
> What do you think ?
>
 Can you create a Clirr report showing the issues above and put it in
 ~luc so we can all look at it?
>>> Yes, I have put it there:
>>> .
>>>
 Also, what would it take to fully eliminate the exceptions-related
 errors?
>>> This would mean going back to checked exception as most errors are
>>> "Removed org.apache.commons.math.MathException from the list of
>>> superclasses"
>> So from the user perspective, the compatibility issue is that code
>> that catches MathException will in some cases propagate runtime
>> exceptions instead.   This sounds ridiculous, but what would be the
>> implications of just reverting the hierarchy so catching
>> MathException would work as before, but make MathException itself
>> unchecked?
> This could be done. I sincerely simply did not think about it.
>
>> Sorry if this seems to be walking into the kind of discussion you
>> did not want to reopen at this point; but I am just trying to see
>> what we might be able to do to prevent users having to make code
>> changes to have their apps that use 2.1 work safely in 2.2.
> I would say we can't do anything. There are the ODE changes which are
> flagged as errors by CLIRR even for things which clearly do not belong
> to the public API like private fields having been replaced. There are
> also the 2.1 tests that Sebb checked against 2.2 and which fail due to
> other changes which are not flagged at all by CLIRR because they are
> semantic changes.
>
What if we reverted all of the incompatible changes other than those
required to fix the ODE bug?  That would mean

1. Revert changes in exception hierarchy
2. Revert semantic changes in equals that Sebb flagged
3. Anything else?

I honestly don't recall anything else and we could look through the
tickets to verify no other semantic changes
>> I will add at this point that if we just s/2.2/3.0 and s/3.0/4.0, I
>> am fine releasing as is.
> 2.2 *is* a clumsy version, so promoting it to 3.0 would be really a bad
> idea as it would imply telling to users « we have done great changes,
> look at them » to only change everything again.
>
> Current 3.0 is more in line with what we want. It will certainly not be
> perfect either, but much better.
>
> So rather than patching this mess once again, we could simply drop 2.2
> completely and concentrate our efforts in 3.0 to be able to publish it
> soon. However, this is not an easy decision. As some of you already
> know, and as Gary said in his interview recently, we have some great
> news to publish about some uses of [math]. Dropping 2.2 and waiting
> months for 3.0 would be really really bad for this.
>
> The alternative is therefore:
>  - do we publish a 2.2 that is clumsy but fixes many important bugs
>and introduces some incompatibilities
>  - do we consider we can publish 3.0 in the next two months so we
>can afford dropping 2.2
>
> Please, choose one option and stick to it. I am exhausted and depressed,
> I don't want to argue anymore.
>
I am really sorry about this, Luc.  I should have complained more
about the incompatible changes as they were introduced.  W

Re: [math] the 2.2 release saga conclusion ?

2011-02-11 Thread Luc Maisonobe

Le 11/02/2011 21:34, Phil Steitz a écrit :
> On 2/11/11 3:03 PM, Luc Maisonobe wrote:
>> Le 11/02/2011 20:23, Phil Steitz a écrit :
>>> On 2/11/11 1:53 PM, Luc Maisonobe wrote:
 Le 11/02/2011 19:07, Phil Steitz a écrit :
> On 2/11/11 12:49 PM, Luc Maisonobe wrote:
>> Hi all,
>>
>> I would like to have 2.2 out as soon as possible. I would like to
>> propose yet another intermediate solution, not a perfect one, but trying
>> to mitigate everything that has been said here. Remember this is *only*
>> for 2.2 and it does *not* mean anything about 3.0 or any further
>> discussions.
>>
>> So I propose we release 2.2 with the following changes relative to what
>> is currently in the repository:
>>
>>  - change FunctionEvaluationException, DerivativeException and
>>MatrixVisitorException to unchecked again by making them
>>extend o.a.c.math.exception.MathUserException
>>  - change ConvergenceException to unchecked by making it extend
>>o.a.c.math.exception.MathIllegalStateException
>>  - undeprecate all these exceptions
>>  - accept the 17 CLIRR errors remaining after these changes
>>(13 related to exceptions, 4 related to ODE)
>>  - accept the 30 CLIRR warnings remaining after these changes
>>(all of them related to exceptions)
>>  - accept the 422 CLIRR infos remaining after these changes
>>
>> This is by no means a perfect solution, I really tried to reach a
>> compromise between several points of view. As each compromise, everyone
>> would have something to tell against it but please don't start another
>> lengthy discussion and even less a flame war. There is no hidden
>> intention behind this and the choices presented would be put only in 2.2
>> branch, not in trunk. The only intention is to be able to publish 2.2.
>>
>> What do you think ?
>>
> Can you create a Clirr report showing the issues above and put it in
> ~luc so we can all look at it?
 Yes, I have put it there:
 .

> Also, what would it take to fully eliminate the exceptions-related
> errors?
 This would mean going back to checked exception as most errors are
 "Removed org.apache.commons.math.MathException from the list of
 superclasses"
>>> So from the user perspective, the compatibility issue is that code
>>> that catches MathException will in some cases propagate runtime
>>> exceptions instead.   This sounds ridiculous, but what would be the
>>> implications of just reverting the hierarchy so catching
>>> MathException would work as before, but make MathException itself
>>> unchecked?
>> This could be done. I sincerely simply did not think about it.
>>
>>> Sorry if this seems to be walking into the kind of discussion you
>>> did not want to reopen at this point; but I am just trying to see
>>> what we might be able to do to prevent users having to make code
>>> changes to have their apps that use 2.1 work safely in 2.2.
>> I would say we can't do anything. There are the ODE changes which are
>> flagged as errors by CLIRR even for things which clearly do not belong
>> to the public API like private fields having been replaced. There are
>> also the 2.1 tests that Sebb checked against 2.2 and which fail due to
>> other changes which are not flagged at all by CLIRR because they are
>> semantic changes.
>>
> What if we reverted all of the incompatible changes other than those
> required to fix the ODE bug?  That would mean
> 
> 1. Revert changes in exception hierarchy
> 2. Revert semantic changes in equals that Sebb flagged
> 3. Anything else?
> 
> I honestly don't recall anything else and we could look through the
> tickets to verify no other semantic changes
>>> I will add at this point that if we just s/2.2/3.0 and s/3.0/4.0, I
>>> am fine releasing as is.
>> 2.2 *is* a clumsy version, so promoting it to 3.0 would be really a bad
>> idea as it would imply telling to users « we have done great changes,
>> look at them » to only change everything again.
>>
>> Current 3.0 is more in line with what we want. It will certainly not be
>> perfect either, but much better.
>>
>> So rather than patching this mess once again, we could simply drop 2.2
>> completely and concentrate our efforts in 3.0 to be able to publish it
>> soon. However, this is not an easy decision. As some of you already
>> know, and as Gary said in his interview recently, we have some great
>> news to publish about some uses of [math]. Dropping 2.2 and waiting
>> months for 3.0 would be really really bad for this.
>>
>> The alternative is therefore:
>>  - do we publish a 2.2 that is clumsy but fixes many important bugs
>>and introduces some incompatibilities
>>  - do we consider we can publish 3.0 in the next two months so we
>>can afford dropping 2.2
>>
>> Please, choose one option and stick to it. I am exhausted and depressed,
>> I don

Re: [math] the 2.2 release saga conclusion ?

2011-02-11 Thread Phil Steitz

On 2/11/11 3:42 PM, Luc Maisonobe wrote:
> Le 11/02/2011 21:34, Phil Steitz a écrit :
>> On 2/11/11 3:03 PM, Luc Maisonobe wrote:
>>> Le 11/02/2011 20:23, Phil Steitz a écrit :
 On 2/11/11 1:53 PM, Luc Maisonobe wrote:
> Le 11/02/2011 19:07, Phil Steitz a écrit :
>> On 2/11/11 12:49 PM, Luc Maisonobe wrote:
>>> Hi all,
>>>
>>> I would like to have 2.2 out as soon as possible. I would like to
>>> propose yet another intermediate solution, not a perfect one, but trying
>>> to mitigate everything that has been said here. Remember this is *only*
>>> for 2.2 and it does *not* mean anything about 3.0 or any further
>>> discussions.
>>>
>>> So I propose we release 2.2 with the following changes relative to what
>>> is currently in the repository:
>>>
>>>  - change FunctionEvaluationException, DerivativeException and
>>>MatrixVisitorException to unchecked again by making them
>>>extend o.a.c.math.exception.MathUserException
>>>  - change ConvergenceException to unchecked by making it extend
>>>o.a.c.math.exception.MathIllegalStateException
>>>  - undeprecate all these exceptions
>>>  - accept the 17 CLIRR errors remaining after these changes
>>>(13 related to exceptions, 4 related to ODE)
>>>  - accept the 30 CLIRR warnings remaining after these changes
>>>(all of them related to exceptions)
>>>  - accept the 422 CLIRR infos remaining after these changes
>>>
>>> This is by no means a perfect solution, I really tried to reach a
>>> compromise between several points of view. As each compromise, everyone
>>> would have something to tell against it but please don't start another
>>> lengthy discussion and even less a flame war. There is no hidden
>>> intention behind this and the choices presented would be put only in 2.2
>>> branch, not in trunk. The only intention is to be able to publish 2.2.
>>>
>>> What do you think ?
>>>
>> Can you create a Clirr report showing the issues above and put it in
>> ~luc so we can all look at it?
> Yes, I have put it there:
> .
>
>> Also, what would it take to fully eliminate the exceptions-related
>> errors?
> This would mean going back to checked exception as most errors are
> "Removed org.apache.commons.math.MathException from the list of
> superclasses"
 So from the user perspective, the compatibility issue is that code
 that catches MathException will in some cases propagate runtime
 exceptions instead.   This sounds ridiculous, but what would be the
 implications of just reverting the hierarchy so catching
 MathException would work as before, but make MathException itself
 unchecked?
>>> This could be done. I sincerely simply did not think about it.
>>>
 Sorry if this seems to be walking into the kind of discussion you
 did not want to reopen at this point; but I am just trying to see
 what we might be able to do to prevent users having to make code
 changes to have their apps that use 2.1 work safely in 2.2.
>>> I would say we can't do anything. There are the ODE changes which are
>>> flagged as errors by CLIRR even for things which clearly do not belong
>>> to the public API like private fields having been replaced. There are
>>> also the 2.1 tests that Sebb checked against 2.2 and which fail due to
>>> other changes which are not flagged at all by CLIRR because they are
>>> semantic changes.
>>>
>> What if we reverted all of the incompatible changes other than those
>> required to fix the ODE bug?  That would mean
>>
>> 1. Revert changes in exception hierarchy
>> 2. Revert semantic changes in equals that Sebb flagged
>> 3. Anything else?
>>
>> I honestly don't recall anything else and we could look through the
>> tickets to verify no other semantic changes
 I will add at this point that if we just s/2.2/3.0 and s/3.0/4.0, I
 am fine releasing as is.
>>> 2.2 *is* a clumsy version, so promoting it to 3.0 would be really a bad
>>> idea as it would imply telling to users « we have done great changes,
>>> look at them » to only change everything again.
>>>
>>> Current 3.0 is more in line with what we want. It will certainly not be
>>> perfect either, but much better.
>>>
>>> So rather than patching this mess once again, we could simply drop 2.2
>>> completely and concentrate our efforts in 3.0 to be able to publish it
>>> soon. However, this is not an easy decision. As some of you already
>>> know, and as Gary said in his interview recently, we have some great
>>> news to publish about some uses of [math]. Dropping 2.2 and waiting
>>> months for 3.0 would be really really bad for this.
>>>
>>> The alternative is therefore:
>>>  - do we publish a 2.2 that is clumsy but fixes many important bugs
>>>and introduces some incompatibilities
>>>  - do we consider we can publish 3.0 in the nex

Re: [math] the 2.2 release saga conclusion ?

2011-02-11 Thread sebb

On 11 February 2011 20:58, Phil Steitz  wrote:
> On 2/11/11 3:42 PM, Luc Maisonobe wrote:
>> Le 11/02/2011 21:34, Phil Steitz a écrit :
>>> On 2/11/11 3:03 PM, Luc Maisonobe wrote:
 Le 11/02/2011 20:23, Phil Steitz a écrit :
> On 2/11/11 1:53 PM, Luc Maisonobe wrote:
>> Le 11/02/2011 19:07, Phil Steitz a écrit :
>>> On 2/11/11 12:49 PM, Luc Maisonobe wrote:
 Hi all,

 I would like to have 2.2 out as soon as possible. I would like to
 propose yet another intermediate solution, not a perfect one, but 
 trying
 to mitigate everything that has been said here. Remember this is *only*
 for 2.2 and it does *not* mean anything about 3.0 or any further
 discussions.

 So I propose we release 2.2 with the following changes relative to what
 is currently in the repository:

  - change FunctionEvaluationException, DerivativeException and
    MatrixVisitorException to unchecked again by making them
    extend o.a.c.math.exception.MathUserException
  - change ConvergenceException to unchecked by making it extend
    o.a.c.math.exception.MathIllegalStateException
  - undeprecate all these exceptions
  - accept the 17 CLIRR errors remaining after these changes
    (13 related to exceptions, 4 related to ODE)
  - accept the 30 CLIRR warnings remaining after these changes
    (all of them related to exceptions)
  - accept the 422 CLIRR infos remaining after these changes

 This is by no means a perfect solution, I really tried to reach a
 compromise between several points of view. As each compromise, everyone
 would have something to tell against it but please don't start another
 lengthy discussion and even less a flame war. There is no hidden
 intention behind this and the choices presented would be put only in 
 2.2
 branch, not in trunk. The only intention is to be able to publish 2.2.

 What do you think ?

>>> Can you create a Clirr report showing the issues above and put it in
>>> ~luc so we can all look at it?
>> Yes, I have put it there:
>> .
>>
>>> Also, what would it take to fully eliminate the exceptions-related
>>> errors?
>> This would mean going back to checked exception as most errors are
>> "Removed org.apache.commons.math.MathException from the list of
>> superclasses"
> So from the user perspective, the compatibility issue is that code
> that catches MathException will in some cases propagate runtime
> exceptions instead.   This sounds ridiculous, but what would be the
> implications of just reverting the hierarchy so catching
> MathException would work as before, but make MathException itself
> unchecked?
 This could be done. I sincerely simply did not think about it.

> Sorry if this seems to be walking into the kind of discussion you
> did not want to reopen at this point; but I am just trying to see
> what we might be able to do to prevent users having to make code
> changes to have their apps that use 2.1 work safely in 2.2.
 I would say we can't do anything. There are the ODE changes which are
 flagged as errors by CLIRR even for things which clearly do not belong
 to the public API like private fields having been replaced. There are
 also the 2.1 tests that Sebb checked against 2.2 and which fail due to
 other changes which are not flagged at all by CLIRR because they are
 semantic changes.

>>> What if we reverted all of the incompatible changes other than those
>>> required to fix the ODE bug?  That would mean
>>>
>>> 1. Revert changes in exception hierarchy
>>> 2. Revert semantic changes in equals that Sebb flagged
>>> 3. Anything else?
>>>
>>> I honestly don't recall anything else and we could look through the
>>> tickets to verify no other semantic changes
> I will add at this point that if we just s/2.2/3.0 and s/3.0/4.0, I
> am fine releasing as is.
 2.2 *is* a clumsy version, so promoting it to 3.0 would be really a bad
 idea as it would imply telling to users « we have done great changes,
 look at them » to only change everything again.

 Current 3.0 is more in line with what we want. It will certainly not be
 perfect either, but much better.

 So rather than patching this mess once again, we could simply drop 2.2
 completely and concentrate our efforts in 3.0 to be able to publish it
 soon. However, this is not an easy decision. As some of you already
 know, and as Gary said in his interview recently, we have some great
 news to publish about some uses of [math]. Dropping 2.2 and waiting
 months for 3.0 would be really really bad for this.

 The alternative is therefore:

Re: [math] the 2.2 release saga conclusion ?

2011-02-11 Thread Phil Steitz

On 2/11/11 4:12 PM, sebb wrote:
> On 11 February 2011 20:58, Phil Steitz  wrote:
>> On 2/11/11 3:42 PM, Luc Maisonobe wrote:
>>> Le 11/02/2011 21:34, Phil Steitz a écrit :
 On 2/11/11 3:03 PM, Luc Maisonobe wrote:
> Le 11/02/2011 20:23, Phil Steitz a écrit :
>> On 2/11/11 1:53 PM, Luc Maisonobe wrote:
>>> Le 11/02/2011 19:07, Phil Steitz a écrit :
 On 2/11/11 12:49 PM, Luc Maisonobe wrote:
> Hi all,
>
> I would like to have 2.2 out as soon as possible. I would like to
> propose yet another intermediate solution, not a perfect one, but 
> trying
> to mitigate everything that has been said here. Remember this is 
> *only*
> for 2.2 and it does *not* mean anything about 3.0 or any further
> discussions.
>
> So I propose we release 2.2 with the following changes relative to 
> what
> is currently in the repository:
>
>  - change FunctionEvaluationException, DerivativeException and
>MatrixVisitorException to unchecked again by making them
>extend o.a.c.math.exception.MathUserException
>  - change ConvergenceException to unchecked by making it extend
>o.a.c.math.exception.MathIllegalStateException
>  - undeprecate all these exceptions
>  - accept the 17 CLIRR errors remaining after these changes
>(13 related to exceptions, 4 related to ODE)
>  - accept the 30 CLIRR warnings remaining after these changes
>(all of them related to exceptions)
>  - accept the 422 CLIRR infos remaining after these changes
>
> This is by no means a perfect solution, I really tried to reach a
> compromise between several points of view. As each compromise, 
> everyone
> would have something to tell against it but please don't start another
> lengthy discussion and even less a flame war. There is no hidden
> intention behind this and the choices presented would be put only in 
> 2.2
> branch, not in trunk. The only intention is to be able to publish 2.2.
>
> What do you think ?
>
 Can you create a Clirr report showing the issues above and put it in
 ~luc so we can all look at it?
>>> Yes, I have put it there:
>>> .
>>>
 Also, what would it take to fully eliminate the exceptions-related
 errors?
>>> This would mean going back to checked exception as most errors are
>>> "Removed org.apache.commons.math.MathException from the list of
>>> superclasses"
>> So from the user perspective, the compatibility issue is that code
>> that catches MathException will in some cases propagate runtime
>> exceptions instead.   This sounds ridiculous, but what would be the
>> implications of just reverting the hierarchy so catching
>> MathException would work as before, but make MathException itself
>> unchecked?
> This could be done. I sincerely simply did not think about it.
>
>> Sorry if this seems to be walking into the kind of discussion you
>> did not want to reopen at this point; but I am just trying to see
>> what we might be able to do to prevent users having to make code
>> changes to have their apps that use 2.1 work safely in 2.2.
> I would say we can't do anything. There are the ODE changes which are
> flagged as errors by CLIRR even for things which clearly do not belong
> to the public API like private fields having been replaced. There are
> also the 2.1 tests that Sebb checked against 2.2 and which fail due to
> other changes which are not flagged at all by CLIRR because they are
> semantic changes.
>
 What if we reverted all of the incompatible changes other than those
 required to fix the ODE bug?  That would mean

 1. Revert changes in exception hierarchy
 2. Revert semantic changes in equals that Sebb flagged
 3. Anything else?

 I honestly don't recall anything else and we could look through the
 tickets to verify no other semantic changes
>> I will add at this point that if we just s/2.2/3.0 and s/3.0/4.0, I
>> am fine releasing as is.
> 2.2 *is* a clumsy version, so promoting it to 3.0 would be really a bad
> idea as it would imply telling to users « we have done great changes,
> look at them » to only change everything again.
>
> Current 3.0 is more in line with what we want. It will certainly not be
> perfect either, but much better.
>
> So rather than patching this mess once again, we could simply drop 2.2
> completely and concentrate our efforts in 3.0 to be able to publish it
> soon. However, this is not an easy decision. As some of you already
> know, and as Gary said in his interview recently, we have some great
> news to pub

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

2011-02-11 Thread 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-attributes has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 5 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-attributes :  Commons Attributes


Full details are available at:

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

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -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-attributes/gump_work/build_apache-commons_commons-attributes.html
Work Name: build_apache-commons_commons-attributes (Type: Build)
Work ended in a state of : Failed
Elapsed: 4 secs
Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only org.apache.tools.ant.Main 
-Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Dfinal.name.api=commons-attributes-api-12022011 
-Dfinal.name.compiler=commons-attributes-compiler-12022011 dist 
[Working Directory: /srv/gump/public/workspace/apache-commons/attributes]
CLASSPATH: 
/usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/apache-commons/attributes/target/classes:/srv/gump/public/workspace/apache-commons/attributes/target/test-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/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/packages/qdox/qdox-1.12.jar:/srv/gump/public/workspace/junit/dist/junit-12022011.jar:/srv/gump/public/workspace/junit/dist/junit-dep-12022011.jar
-
Buildfile: /srv/gump/public/workspace/apache-commons/attributes/build.xml

init:
[mkdir] Created dir: 
/srv/gump/public/workspace/apache-commons/attributes/target/lib

get-deps:

compile:
[mkdir] Created dir: 
/srv/gump/public/workspace/apache-commons/attributes/target/classes
[javac] Compiling 28 source files to 
/srv/gump/public/workspace/apache-commons/attributes/target/classes
[javac] 
/srv/gump/public/workspace/apache-commons/attributes/compiler/src/java/org/apache/commons/attributes/compiler/AttributeCompiler.java:90:
 warning: [deprecation] project in org.apache.tools.ant.ProjectComponent has 
been deprecated
[javac] String sourcePaths = project.getReference 
(pathref).toString ();
[javac]  ^
[javac] 
/srv/gump/public/workspace/apache-commons/attributes/compiler/src/java/org/apache/commons/attributes/compiler/AttributeCompiler.java:96:
 warning: [deprecation] project in org.apache.tools.ant.ProjectComponent has 
been deprecated
[javac] fs.setProject (project);
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/attributes/compiler/src/java/org/apache/commons/attributes/compiler/AttributeCompiler.java:245:
 incompatible types
[javac] found   : com.thoughtworks.qdox.model.JavaPackage
[javac] required: java.lang.String
[javac] packageName = javaClass.getPackage ();
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/attributes/compiler/src/java/org/apache/commons/attributes/compiler/AttributeCompiler.java:454:
 warning: [deprecation] getFile() in com.thoughtworks.qdox.model.JavaSource has 
been deprecated
[javac] return javaClass.getSource ().getFile ();
[javac]  ^
[javac] 
/srv/gump/public/workspace/apache-commons/attributes/compiler/src/java/org/apache/commons/attributes/compiler/AttributeCompiler.java:481:
 warning: [deprecation] project in org.apache.tools.ant.ProjectComponent has 
been deprecated
[javac] DirectoryScanner ds = 
fs.getDirectoryScanner(project);
[javac]  ^
[javac] 
/srv/gump/public/workspace/apache-commons/attributes/compiler/src/java/org/apache/commons/attributes/compiler/AttributeCompiler.java:482:
 warning: [deprecation] project in org.apache.tools.ant.ProjectComponent has 
been deprecated
[javac] File fromD

Re: [math] the 2.2 release saga conclusion ?

2011-02-11 Thread Michael Giannakopoulos

Hi guys,
As far as exceptions is concerned it is a major change in the code and
leaving it out from the 2.2 release is a good idea. About the exceptions i
would like to point that in some cases new exceptions are needed so as to be
more clear to developers which one of them to use...

>
>This is by no means a perfect solution, I really tried to reach a
>compromise between several points of view. As each compromise, everyone
>would have something to tell against it but please don't start another
>lengthy discussion and even less a flame war. There is no hidden
>intention behind this and the choices presented would be put only in 2.2
>branch, not in trunk. The only intention is to be able to publish 2.2.

Luc what do you mean by this? There are two versions of code out there?
Sorry for these questions but this is new to me...

I'm willing to help so as to publish 2.2. Thank you all for your time!

Best regards,
Giannakopoulos Michael

Re: Fwd: [SCXML] Actionscript SCXML engine

[attributes] Gump failure after qdox update

[lang] propse new ObjectExistsException extends IllegalArgumentException

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

[GUMP@vmgump]: Project commons-jelly-tags-quartz (in module commons-jelly) failed

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

Re: [lang] propse new ObjectExistsException extends IllegalArgumentException

Re: [lang] propse new ObjectExistsException extends IllegalArgumentException

Re: [attributes] Gump failure after qdox update

Re: [attributes] Gump failure after qdox update

Re: [attributes] Gump failure after qdox update

[math] the 2.2 release saga conclusion ?

Re: [math] the 2.2 release saga conclusion ?

Re: [math] the 2.2 release saga conclusion ?

Re: [math] the 2.2 release saga conclusion ?

Re: [math] the 2.2 release saga conclusion ?

Re: [math] the 2.2 release saga conclusion ?

Re: [math] the 2.2 release saga conclusion ?

Re: [math] the 2.2 release saga conclusion ?

Re: [math] the 2.2 release saga conclusion ?

Re: [math] the 2.2 release saga conclusion ?

Re: [math] the 2.2 release saga conclusion ?

Re: [math] the 2.2 release saga conclusion ?

Re: [math] the 2.2 release saga conclusion ?

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

Re: [math] the 2.2 release saga conclusion ?

26 matches

Site Navigation

Mail list logo

Footer information