I was thinking of doing a runtime type check on the exception returned
(grabbing an instance of the class via introspection, to avoid a
classload-time dependency) and reraising anything unexpected wrapped in a
RuntimeException; otherwise, that's pretty much exactly the way I would
have fixed the is
r1594279 seems to fix the issue, but I still don't understand why.
Any suggestion of a better fix is welcomed.
Nicolas
Le 11 mai 2014 à 23:41, Nicolas Lalevée a écrit :
> Hi,
>
> I need some help to understand a bug around classloading (nothing that
> particular to Ivy).
>
> I was looking in
On Tuesday, 13 May 2014, Antoine Levy Lambert wrote:
> Hello Matt,
>
> this is interesting - thanks for pointing this out since I am a newbie in
> git land.
>
> does one need to do some advance planning to make a module become a
> submodule of
> another repository aggregating the submodules ?
>
>
+1
Per A. Blaasmo
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Hello Matt,
this is interesting - thanks for pointing this out since I am a newbie in git
land.
does one need to do some advance planning to make a module become a submodule
of
another repository aggregating the submodules ?
there would be a use case for an aggregation of the complete ant fam
On 2014-05-07, Matt Sicker wrote:
> The Camel project takes PRs from GH, though, so they may have some useful
> info about that.
http://camel.apache.org/contributing.html#Contributing-PullrequestatGithub
sounds like manually merging the PR to the ASF git repo.
Stefan
--