What you describe seems to me like an entirely different problem.
If a .jar pulls in a DLL that pulls in another DLL that's not part
of the native platform, the second DLL should also be loaded
explicitly from within Java code. If one gets a pre-packaged .jar
that doesn't do this, it's not too difficult to wrap around it when
packaging the .nbm jar so that all this is made invisible to the end
developer. A brief HOWTO on how to do this would spare the world a
whole lot of pain. :)
As far as modifying the process's environment from within to make the
OS search for DLLs in the right places, I was under the impression
that a VM doesn't permit changing the native process's environment
from within, only reading it? I could be wrong. Of course, one
could always use JNI to get at a native call that permits one to do
so from the outside, eww...
--dv
Sven Reimers wrote:
> This solves your problem, since the *.dll is loaded from inside the
> VM. If this *.dll requires another *.dll it also has to provide, it is
> even more difficult to get this working.
>
> The main problem is that the second *.dll is loaded via the os
> mechanism, which just looks in . or whatever is declared beforehand on
> a systemwide scale. This is bad for a module that just would like to
> bring the library and remove it on uninstall.
>
> The actual solution is to put the *.dll into . (in nb6 this is
> netbeans/) to get this to work. BUt it would be better to have a
> similar solution to what is done for the wrapper *.dll's, e,g, add
> modules/lib of all clusters to the operating system library path , so
> that *.dll's would be found there as well.
>
> Anybody any further comments on this?
>
> -Sven
>
> On 1/25/07, Dejan Vucinic <
dejan.vucinic@...> wrote:
>> Thanks for the pointers Radim. The problem, of course, was that
>> it's not modules/lib that the build script looks in, it's
>> release/modules/lib which is not really documented in an obvious
>> place.
>>
>> The correct way to do it would be to have an Action in the Library
>> Wrapper Module so that a right-click offers a menu option
>> "Add Native Library..." which pops up a file chooser and copies
>> the chosen .dll or .so to the appropriate location. This is a
>> two-minute job for someone who knows where to add the action.
>> Could someone please do it in NB6? I'm sure hundreds of folks
>> stumble on this one.
>>
>> Thanks,
>>
>> --dv
>>
>> Radim Kubacki wrote:
>> > Dejan Vucinic wrote:
>> >> Greetings,
>> >>
>> >> I've been trying for the past couple of days to add a native library
>> >> to a Library Module for the NetBeans 5.5 Platform. The situation
>> >> seems to me like something that would be encountered often: I
>> >> have a third-party .jar file that comes with its own .DLL for use on
>> >> windows machines. I can wrap the .jar in a Library Module with a
>> >> few mouse clicks as described in the documentation, but no
>> >> matter where I put the .DLL, regardless of adding <include ...>
>> >> statements to common.xml, the .DLL just doesn't get found by
>> >> the target platform. Could anyone please explain why this is such
>> >> a pain? Will this get fixed in NB 6?
>> >>
>> > The module system looks for native libraries in modules/lib
>> directories.
>> > You can look at the example of extbrowser module that is part of IDE.
>> >
>> > -Radim
>> >
>> >> Thanks,
>> >>
>> >> --dv
>> >>
>> >
>>
>