External Dependancies
PhreaK
Posts: 966
Hey there fellow Duet'ers and Duet'ettes. For those of you who have some nice libraries / utility classes etc that you share between projects and like me had been doing the import thing every time you need them in a new project here's a much funkier way.
Turns out that you can export your nice useful reusable and sexy libraries as a jar (yes I know, you knew that you could do this). But... if you use a custom manifest and include the line 'AMX-Type: Duet' things start to get sexy.
This allows you to place the jar in one of the directories in which NLStudio looks for modules (by default AMXShare\Duet\bundle, AMXShare\Duet\lib and AMXShare\Duet\module - or you can add more from the preferences window). From there when you create new modules in Duet simply include the JAR in the build path and add it to the 'File Dependencies' in the modules duet manifest.
Now every time hit the compile button in NetLinx Studio for a project that uses the module it will look for the jar (if it's not in the NetLinx compiler build paths you'll get something similar to this) and... it will also be transferred to the controller along with your module - exactly the same was as snapirouter.jar and devicesdkrt.jar are handled. Now you have one nice re-usable jar that all you modules can use without having to worry about continuously importing helper class and maintaining them across projects. Sexy.
Turns out that you can export your nice useful reusable and sexy libraries as a jar (yes I know, you knew that you could do this). But... if you use a custom manifest and include the line 'AMX-Type: Duet' things start to get sexy.
This allows you to place the jar in one of the directories in which NLStudio looks for modules (by default AMXShare\Duet\bundle, AMXShare\Duet\lib and AMXShare\Duet\module - or you can add more from the preferences window). From there when you create new modules in Duet simply include the JAR in the build path and add it to the 'File Dependencies' in the modules duet manifest.
Now every time hit the compile button in NetLinx Studio for a project that uses the module it will look for the jar (if it's not in the NetLinx compiler build paths you'll get something similar to this) and... it will also be transferred to the controller along with your module - exactly the same was as snapirouter.jar and devicesdkrt.jar are handled. Now you have one nice re-usable jar that all you modules can use without having to worry about continuously importing helper class and maintaining them across projects. Sexy.
0
Comments
I'm seeing how great Duet is now, but man it's a whole other world for this NetLinx programmer. *sigh* I just wish they would have went the .NET route like a certain competitor. In the end, that could pull me away.
Now that I'm doing both control systems, and have been spending a lot of time with .NET doing the Certified Cyber Solution stuff, I really would like to get into DUET/JAVA more. I'm sure I'd have the same issues you're having. The other thing to is that I'm not a spring chicken anymore. It's harder for me to switch hats. It seems to take me longer to get the gears shifted.
Just a note on the custom manifests - there seems to be a bug in the eclipse jar exporter used by the latest version of Cafe Duet. You need to make sure that there's a couple of empty lines after your last key/value pair otherwise it will remove it.
Eg, if you tell it to use a custom manifest containing and then look at the manifest in the exported jar it will only contain add a couple of blank lines to the file before shooting it the jar-in-at-or however and it all plays nice.