Hello ,
While Porting the codes in [1] I discovered below problems.
commons-numbers-rootsolver (with codes from package
> "org.apache.commons.math4.analysis.solver")
>
This needs some dependencies in the Module *commons.Math4.differentiation*.
But I couldn't find corresponding redesign in the
Hi Amitava,
There were still pending issues prior to the 1.0 release, so it was moved to a
branch for further work. If you are interested in using it, perhaps you would
have some suggestions/comments for these tickets:
* Human name parser https://issues.apache.org/jira/browse/TEXT-15
* Make
Github user coveralls commented on the issue:
https://github.com/apache/commons-fileupload/pull/17
[![Coverage
Status](https://coveralls.io/builds/17094811/badge)](https://coveralls.io/builds/17094811)
Coverage decreased (-0.1%) to 77.046% when pulling
GitHub user krichter722 opened a pull request:
https://github.com/apache/commons-fileupload/pull/17
Move static analysis plugins from reporting to build
Moving the static code analysis plugins maven-checkstyle-plugin and
maven-pmd-plugin from the reporting to the build section
Hi All,
I'd appreciate thoughts on https://issues.apache.org/jira/browse/IO-577.
Gary
Github user asfgit closed the pull request at:
https://github.com/apache/commons-fileupload/pull/16
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
Well, the VOTE.txt generation is mostly done, it is missing a few pieces of
course. The current Ant filter-based approach works and is simple. If you
want to redo it with Velaocity, feel free :-) As long as there is not much
a learning curve to further modifying the template, I'm OK with what you
Hey Gary,
I’ve finished creating some velocity templates for the README.html, and
HEADER.html to put along side the artifacts in the distribution repository. I
don’t think that it would be much trouble to include the Vote.txt in with the
velocity templates to generate during staging. Thoughts?
Github user coveralls commented on the issue:
https://github.com/apache/commons-fileupload/pull/16
[![Coverage
Status](https://coveralls.io/builds/17090743/badge)](https://coveralls.io/builds/17090743)
Coverage remained the same at 77.177% when pulling
GitHub user krichter722 opened a pull request:
https://github.com/apache/commons-fileupload/pull/16
Use Apache Commons I/O in tests
Replace File.delete and File.mkdir with Apache Commons I/O's FileUtils
equivalent which throw IOException instead of returning false which
Github user sebbASF commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
FooDiskItem.write is not part of FileUpload, so it *can* throw Exception if
it has not been recompiled since it was compiled against FileUpload 1.3.3.
---
Github user krichter722 commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
> I run my FooDiskFileItem that throws an Exception (not an IOException).
How? If `DiskItem.write` doesn't throw `Exception` `FooDiskItem.write`
can't.
> My new code
Github user krichter722 closed the pull request at:
https://github.com/apache/commons-fileupload/pull/15
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
Github user sebbASF commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
Surely if your new code uses FooDiskFileItem, it needs to know that it
throws Exception and catch that accordingly? Why would you knowingly use
FooDiskFileItem but not catch Exception?
Github user garydgregory commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
I am concerned about:
- I create a class or jar with a subclass of `DiskFileItem` called
`FooDiskFileItem` that throws an `Exception` against FileUpload 1.3.3.
- We release
Github user sebbASF commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
AFAICT this only affects source compatibility.
I was able to run the subclass (throwing Exception) against the base class
(updated to throw IOE).
Of course I could not compile
Done.
Gary
On Wed, May 16, 2018 at 10:22 AM, Rob Tompkins wrote:
>
>
> > On May 16, 2018, at 12:00 PM, Gary Gregory
> wrote:
> >
> > Hi All:
> >
> > Now that we have more than one plugin in Commons, I'd like to:
> > - Rename the build plugin's goal
Done. https://issues.apache.org/jira/browse/DBCP-492
Gary
On Sat, May 12, 2018 at 2:30 PM, Rob Tompkins wrote:
>
>
> > On May 12, 2018, at 2:36 PM, Gary Gregory
> wrote:
> >
> > Hi All:
> >
> > Commons DBCP still has an Ant build. Should we drop it?
Github user garydgregory commented on the issue:
https://github.com/apache/commons-fileupload/pull/15
Committed to git master. Please verify and close.
---
-
To unsubscribe, e-mail:
Github user coveralls commented on the issue:
https://github.com/apache/commons-fileupload/pull/15
[![Coverage
Status](https://coveralls.io/builds/17088373/badge)](https://coveralls.io/builds/17088373)
Coverage remained the same at 77.177% when pulling
GitHub user krichter722 opened a pull request:
https://github.com/apache/commons-fileupload/pull/15
pom.xml: Remove tab characters
pom.xml contains a mixture of spaces and tab characters in order
to indent markup which is confusing. Spaces should be used instead where
Github user krichter722 commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
> True, but what if I have a subclass of DiskFileItem that throws an
Exception? What happens at runtime?
Correct, I didn't think about that. I'm already glad, you're willing
The reason this came up for me is using a different library (Commons DBCP)
that NPE'd on null inputs in a deep application stack, all the way from a
UI down to that library. My layer was in the middle. Granted I could have
added null checks in my code but it was cleaner to avoid the NPEs in DBCP.
Github user krichter722 commented on the issue:
https://github.com/apache/commons-fileupload/pull/14
I made a mistake during rebase, the results are identical.
---
-
To unsubscribe, e-mail:
Github user krichter722 closed the pull request at:
https://github.com/apache/commons-fileupload/pull/14
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
Github user sebbASF commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
@krichter722 Yes. I meant to say: changing a throw clause can affect source
compatibility
@garydgregory - are you asking whether an overloaded method will have to be
amended?
Github user garydgregory commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
True, but what if I have a subclass of DiskFileItem that throws an
Exception?
Note: We are OK with breaking source compatibility but not BC outside of a
major release.
Github user garydgregory commented on the issue:
https://github.com/apache/commons-fileupload/pull/14
If you have more, please update this PR based on what is in git master.
---
-
To unsubscribe, e-mail:
Github user krichter722 commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
In any previous situation users needed to catch `Exception`. Since both
exception extend `Exception` there's no case where they need to change any code.
---
Github user krichter722 commented on the issue:
https://github.com/apache/commons-fileupload/pull/14
> Thank you for your report. I used Eclipse'd clean up feature to implement
this change instead of applying this patch. Please verify and close.
NetBeans seems to find some
Github user sebbASF commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
The throws clause is not part of the method signature, and does not affect
binary compatibility.
However it does affect source compatibilty
---
Github user garydgregory commented on the issue:
https://github.com/apache/commons-fileupload/pull/14
Thank you for your report. I used Eclipse'd clean up feature to implement
this change instead of applying this patch. Please verify and close.
---
Github user garydgregory commented on the issue:
https://github.com/apache/commons-fileupload/pull/13
I think that would break binary compatibility. So it would have to be for
2.0.
---
-
To unsubscribe, e-mail:
The file src/changes/changes.xml is broken. It looks like a merge did not
apply cleanly.
Gary
Github user markt-asf closed the pull request at:
https://github.com/apache/commons-pool/pull/4
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Github user markt-asf commented on the issue:
https://github.com/apache/commons-pool/pull/4
Thanks for the PR. I've fixed this in a slightly different way after
reviewing the prior changes. The tst case I used largely as-is. Thanks.
---
36 matches
Mail list logo