Why does the build.xml file generate controller.jar for the core API of jinput? I can understand the plugins having various names per platform, but I don’t see any reason for the JInput core API to build into anything other than jinput.jar the same way jogl jars into jogl.jar.
I’ll post something to javadev for vote shortly, but this seems to be something that we should not have any issues changing (I already have in fact done so for the OSX release).
Just historic.
JK
Anyone have any objections to me making it generate jinput.jar?
Hi
Sounds good to me, it’s a
:%s/controller.jar/jinput.jar/g
for me 
Sounds fine. One of you guys want to change the ANT script and put it back?
JK – ducking work 
I’ll catch it tonight with my next (hopefully alpha) update of the JInput OSX code. Ran across a snag where certain fields were only available sometimes and passing back those empty strings through the JNI call was causing bus errors - oops
Hi
I’ve just done the core changes and the DX8 ones as I needed to do them so I could do the linux change.
Cheers
Endolf
I think I may have added a change to your changes The output of the build.xml is /dist/jinput.jar. Maybe we should agree on some standard layout for project directories. Here in my shop I’ve pushed through:
/src <- source files go here
/lib <- libs needed to build go here
/classes <- intermediate build files go here
/res <- any resource files for the .jar go here
/dist <- final distributables go here
/doc <- autogenerated and regular docs go here
build.xml
Would just make things easier if all of the projects followed some similar patter of where things are supposed to go.
Hi
Maybe it jinput.jar needs to be in both bin and dist, as it’s needed for the tests (hence bin) but is also the distributable, aslo, but changeing this already in the build scripts you broke the linux build. Oh, and the main coreAPI build file you checked in was broken. Shoudln’t we be sticking to the java.net common directories rather than imposing our own, makes sence for jogl, jinput an djoal to have the same node structure.
/me tries to get it working, fix proper later
Cheers
Endolf
The only file I changed was the build.xml in coreAPI. I have since checked it in with the redundant target removed.
Hi
Exactly :), having changed that one file all the other plugins that depend on files in the coreAPI (jinput.jar) then break if the file no longer exists (DX cheats and copies it as aprt of the coreAPI build which is why it didn’t break).
I’m guessing your not on the CVS mailing list for jinput otherwise you would have noticed me checking the change for the extra ‘all’ target, and checkin fixes for the linux build, having changed the location of the jinput jar the linux build is broken again :), i’ve just commited the fix again as it stands in cvs linux and windows builds work again
Cheers
Endolf
Nah, I’m not on the CVS list. Why doesn’t the Linux port cheat? The OSX port will
Note, I’m also not seeing a linux port in CVS under plugins. Are you checking into CVS?
Hi
it’s there, make sure you are doing a checkuot as update will only update files you already have (depening on your cvs client), if you look at jinput.dev.java.net and then source, it’s all there under plugin and linux. The linux build script doesn’t copy the jar around as there is no need, as long as it doesn’t get deleted the jinput.jar will always be in one place, coreAPI/(insert where ever we decide here)/jinput.jar :), it keeps the coreAPI ant script a little cleaner if it doesn’t have to copy the jinput.jar into plugin specific directories, that was my take on it anyway
Cheers
Endolf
I really like the idea of the core not being installed into plugin specific directories and would prefer that the directory it ends up in be called dist - I’d actually like one big master build file to generate joal.jar, jutils.jar, jinput.jar and jogl.jar into dist as well, but that’s just a dream aat this point.
Hi
Thats not a bad idea, I was thinking about the build dirs last night, hows about a compromise, leave jinput.jar in bin, but add the build target of dist, this will copy jutils.jar, jinput.jar, and the contents of coreAPI/lib/controller/* to the dist directory and zip it up that way you have the bin directory for the textest and readtest, but also have (if you choose to run it) ready made binary distribution for sticking up on a website or including with your game?, I’ve just checked my own rady built files and they didn’t work, the plugin bits need to be in controller directory from where ever you run it (how it works from lib/controller in the tests I dunno, but thats what I found), so I’ve updated them, I suggest any dist we build with ant sticks to this, so jinput.jar and jutils.jar go in dist, and the plugin goes in dist/controller, then zip it all up?
Cheers
Endolf
[quote]I suggest any dist we build with ant sticks to this, so jinput.jar and jutils.jar go in dist, and the plugin goes in dist/controller, then zip it all up?
[/quote]
That seems like the right way to do it to me. But where do the native libraries go? They won’t be loaded from the controller directory will they?
Bah, just give me a Web Start extension installer.
Hi
they will indeed, the plugin environment stuff in jinput sets the lib path to the controller directory for you
I checked with the two distro’s i’ve built, linux and windows, and both work for java -cp jinput.jar(;/:)jutils.jar net.games.input.test.Controller(Read/Text)Test
which is nice
Unless someone complains I will update the main build.xml to reflect this, it shouldn’t break any other build files as it is a separte addition.
Cheers
Endolf
Finally there are Win32 binaries available.
Well a big thanks from me. Now I can explore JInput myself.
Hey Guys,
Youve gotten ahead of us with the dist stuff.
We are working on an automated nightly build as
well as controlled release builds. They will appear on
web pages all their own.
I appreciate your enthusiasm but I kinda need to leave the build target directories as they were as thats a standard that was agreed on for all the “core” APIs and i don’t want to get out of synch with them. Also, the folks working behind the scenes on things like the automated build systems expect this uniformity.
Can you make sure that what is built ends up in bin and lib? If you want to add a dist and ANT task for local builds thats fine but having those built copies in the soruce CVS is likely to cause some real confusion.
Also, although we’re running things pretty loosely I’d really appreciate it if you got my check-off as project manager before changing fundemental things like the build scripts.
(If someone else would like to take over project management, we can talk about that, as its not like I don’t have lots else to do.)
Thanks
JK