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).

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

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:

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.

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

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

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?

We are working on an automated nightly build aswell as controlled release builds. They will appear onweb 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.

Hi I commit a change the main build script that copies a few files across to a dist dir and zips them up, it leaves the originals where they were (bin, lib and src/tests/controller), as/when this automated nightly build thing happens it can easily be removed, it effects no other target (except clean, easy to remove again). Is it ok to leave it in for now?

Cheers

Endolf

P.S. the plugin has *never* ended up under bin or lib, it's always been under src/tests/controller, from what your saying this is a mistake as it should be under bin or lib, correct?

Hi I commit a change the main build script that copies a few files across to a dist dir and zips them up, it leaves the originals where they were (bin, lib and src/tests/controller),

Cool thats fine for now Thanks

Quote

as/when this automated nightly build thing happens it can easily be removed, it effects no other target (except clean, easy to remove again). Is it ok to leave it in for now?

Cheers

Endolf

P.S. the plugin has *never* ended up under bin or lib, it's always been under src/tests/controller, from what your saying this is a mistake as it should be under bin or lib, correct?

Um yeah sure sounds like it but i find it hard to believe. Are you SURE there isn't a jar file being built and copied to the appropriate bin or lib under the plug-in branch? (Ill check it on monday but i'd be astounded if this slipped through.)

JK

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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.

Thanks

JK

Can we get a document that shows the expected directory layout of the core projects? (If it exists in CVS and I've missed it, just clue me in.)If something was agreed on it should be documented.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org