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 c
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 Hu
Github user coveralls commented on the issue:
https://github.com/apache/commons-fileupload/pull/17
[](https://coveralls.io/builds/17094811)
Coverage decreased (-0.1%) to 77.046% when pulling
**b33c20cab9e96ad8
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 an
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: dev-h...@commons.apache.o
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
p
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
[](https://coveralls.io/builds/17090743)
Coverage remained the same at 77.177% when pulling
**41694d54cf4fc2d8
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
reduc
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 o
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: dev-h...@commons.apa
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 Fil
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 prefix from "commons" to "commons-build"
> >
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?
>
> +1, given that maven works.
>
> >
> > Ga
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: dev-unsubscr...@commons.apache.org
Github user coveralls commented on the issue:
https://github.com/apache/commons-fileupload/pull/15
[](https://coveralls.io/builds/17088373)
Coverage remained the same at 77.177% when pulling
**e23e2aab745ccb6c
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
applica
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 to
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: dev-unsubscr...@commons.ap
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: dev-h...@commons.apa
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: dev-unsubscr
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 mor
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: dev-
The file src/changes/changes.xml is broken. It looks like a merge did not
apply cleanly.
Gary
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.
---
--
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
36 matches
Mail list logo
