From: Edward Povazan <epovazan@...>
> Ok, I have recreated the error in a separate test.
> Do you know where I can start looking in the source, where the import
> actually occurs.
> Or is there someone who 'maintains' the import code that would be interested
> to see this?
Maybe you refer to me <wink>. I'm guilty for much
of the import logic impl.
Sorry for the duplicated work but when I asked:
>The thing you haven't said to us
>is that you are doing the
> from impi.core import *
>from a module inside impi.core, is that true?
I had already code that duplicated the bug,
I was exploring whether my work hypothesis
matched your world(-view).
> No matter if I use * or a specific method/object, the error still occurs.
I never said the contrary, inside impi.core.editors
from impi.core import *
from impi.core import Impi
The situation is more involved that it already seems <wink>.
[*] At some point we [the devels] decided that
NoClassDefFoundError should be treated
differently than ClassNotFoundException, and not
transformed in import errors, but just propagated
up to the user. Because it can contain
valuable debug info.
So the naive fix that we can apply - leaving [*] as it is -
would fix the problem as long as sys.path is
disjunct from classpath... So the point
is that maybe we should rethink about [*].
For your case, I don't know if this is acceptable for you,
but I would move the java classes in impi.core.jclasses,
jclasses being a java package (a dir without __init__.py),
and putting the right package statements in the java sources.
Then you can put a
from jclasses import *
or from impi.core.import * inside impi.core.__init__
and murphy-willing things should work, unless
other subtlilities block this approach too.