Or wait, where do you add this? It has to be in the build file of the java project, not the module, right?
normen said:
Or wait, where do you add this? It has to be in the build file of the java project, not the module, right?
No the wrapper module, Thinking that the suite will build the module, so the module will build the jar and wrap it. The module calls the build file in the JAR like this.
[xml]
<property name="original.project.dir" value="../InspectorAppState"/>
<property name="original.project.jar"
value="${original.project.dir}/dist/InspectorAppState.jar"/>
<target name="release" depends="projectized-common.release">
<echo message="Building ${original.project.dir}"/>
<ant dir="${original.project.dir}" target="jar"/>
<copy todir="${cluster}/modules/ext"
file="${original.project.jar}"/>
</target>
[/xml]
The call “ant dir …” already creates a completely new ant environment. Just put the variable I mentioned in that projects properties file and it should work.
normen said:
The call "ant dir ..." already creates a completely new ant environment. Just put the variable I mentioned in that projects properties file and it should work.
It does, but it also inherits all the properties of the caller (i.e. inheritAll="true" which is the default).
"Parent" build file
[xml]<project name="InheritTest" default="build" basedir=".">
<property name="inherited.property" value="From parent" />
<target name="build">
<ant dir="child" target="showprop" />
</target>
</project>[/xml]
Child build file
[xml]<project name="InheritTestChild" default="build" basedir=".">
<target name="showprop">
<echo>Inherited: ${inherited.property}</echo>
</target>
</project>[/xml]
Output:
$ ant
Buildfile: build.xml
build:
showprop:
[echo] Inherited: From parent
BUILD SUCCESSFUL
Yes… But if you import all properties then the sub-project cannot set them with its values and issues might arise (as hinted at in the NetBeans tuto, properties in ANT are immutable). So just put the libs reference in the java project, module projects get the jme libs else as said 
I have a suggestion on how to handle the library properties. Let me describe my CI build first:
I get jMonkeyEngine from SVN. Build it straigt up with “build”. I’m using jenkins to build, so the source and the built binaries ends up in a “workspace” directory, let’s call that SDKDIR.
When building my suite I do the following trickery:
I start by copying the everything from SDKDIR/sdk/build/cluster to SDKDIR/netbeans/jmonkeyplatform. This sets up the netbeans clusters to look like the installed SDK.
I pass the following flag to my ant -Duser.properties.file=/jenkinsbuild/build.properties
Now this file is a massaged copy of an ordinary user build.properties. It contains stuff like:
nbplatform.default.netbeans.dest.dir=SDKDIR/netbeans
nbplatform.default.harness.dir=${nbplatform.default.netbeans.dest.dir}/harness
libs.jme3.dir=${nbplatform.default.netbeans.dest.dir}/jmonkeyplatform/libs
libs.jme3-libraries-networking.classpath=${libs.jme3.dir}/jME3-networking.jar
libs.jme3-libraries-physics.classpath=${libs.jme3.dir}/jME3-jbullet.jar:${libs.jme3.dir}/jbullet.jar:${libs.jme3.dir}/stack-alloc.jar:${libs.jme3.dir}/vecmath.jar
…
and so on for all libs.
So my suggestion is to do the same in the contribution-repo build. This sets up the libraries in the same way as when building in the SDK (i.e. user build.properties). With this setup I do not have to do anything special in my modules to find the engine JAR files, no property files to fix, no hardcoded paths in all modules et c. I can build my wrapper module as suggested in the NB FAQ (i.e. inheritAll=false).
With the following disclaimer: I haven’t tested this as another user so there might be some more environment stuff that needs to be setup for the CI build.
On the build server the SDK modules are included, no need to copy them, they can be referenced in the cluster variable.
The issue is that the single library projects are not in any way part of the module suite and also should not inheritAllRefs. I could still set up a variable in the suite that references the class path for normal projects in the suite so that one can pass that when calling the build file of the project, so something like:
[xml]
<antcall target="build" inheritrefs=false>
<ref id="libs.jme.classpath" value="${suite.jme.classpath.ref}"/>
</antcall>
[/xml]
(no idea if the syntax is right but you get the idea)
normen said:
On the build server the SDK modules are included, no need to copy them, they can be referenced in the cluster variable.
Yes, I just included that part as reference and if someone wants to setup a build on their own. The contrib repo has all that.
normen said:
The issue is that the single library projects are *not* in any way part of the module suite and also *should not* inheritAllRefs. I could still set up a
Indeed. But if I build from inside the SDK and have my wrapper module call ant build (inheritAll=false, inheritRefs=false) it works. Because the user build.properties is sourced even for ordinary java-jar builds so even ordinary nothing-to-do-with-modules-or-suites-projects have the jme3 libs properties defined. My wish is that the CI build should work the same as when building from inside the SDK.
But your version with a ref is good also. I actually tried a version of that with inlining the properties for the jme-libs but didn't get it to work - might have done something wrong tho'
Yeah, if they are normal NetBeans projects I could somehow add it to the ant environment as the build-impl checks for this stuff. Thing is I can’t know where these projects are and when/how they are built. I’d basically have to check the whole repo for normal NetBeans projects and add a private properties file (which references the global build imports when you build with netbeans). Or do you see another option to make it work out of the box?
Yes, when building as a normal user in the SDK, netbeans has created a ~/.jmonkeyplatform/3.0RC2/build.properties which contain the library definitions.
The problem is that the hudson/jenkins user do not have that. So my solution is to point hudson to such a file by using:
-Duser.properties.file=/jenkinsbuild/build.properties as argument in the build configuration.
Then the CI build works the same as when building inside the SDK. You don’t have to know the type of project or fiddle with any properties file. If it works in the SDK it works on the build machine.
@jmaasing said:
Yes, when building as a normal user in the SDK, netbeans has created a ~/.jmonkeyplatform/3.0RC2/build.properties which contain the library definitions.
The problem is that the hudson/jenkins user do not have that. So my solution is to point hudson to such a file by using:
-Duser.properties.file=/jenkinsbuild/build.properties as argument in the build configuration.
Then the CI build works the same as when building inside the SDK. You don't have to know the type of project or fiddle with any properties file. If it works in the SDK it works on the build machine.
Again, that doesn't go to the build files of your normal projects, you keep going in a circle ;)
@normen said:
Again, that doesn't go to the build files of your normal projects, you keep going in a circle ;)
Let's spin around and see which one of us falls down first :D
Here is my build.xml in an ordinary java-library project, can anyone in the audience please investigate this build file and see that there is nothing unusual with it and that I have no properties-file up my sleeve :)
[xml]
<project name="InspectorTerrainAppState" default="default" basedir=".">
<description>Builds, tests, and runs the project InspectorTerrainAppState.</description>
<import file="nbproject/build-impl.xml"/>
[/xml]
Aha! let's see what that build-impl contains:
[xml] <target depends="-pre-init,-init-private" name="-init-user">
<property file="${user.properties.file}"/>
<!-- The two properties below are usually overridden -->
<!-- by the active platform. Just a fallback. -->
<property name="default.javac.source" value="1.4"/>
<property name="default.javac.target" value="1.4"/>
</target>
<target depends="-pre-init,-init-private,-init-user" name="-init-project">
[/xml]
Weeeeell, what is this here then (said he knowingly) it appears to read a "user.properties.file" - I wonder what that may contain in an ordinary installation on just about any jMonkey computer.
libs.jme3-libraries-plugins.classpath=/home/johan/.jmonkeyplatform/3.0RC2/libs/jME3-plugins.jar
libs......
PRESTO!
Stunned monkey audience --> :o :o :o :o
In other words, they do go to the build files of your normal projects :)
But we don’t have a folder called home/johan and NetBeans does not commit the private project properties? Your SDK/NetBeans creates it.
Again, the projects on the server that are not modules are not built with the jme ecosystem but you just call them via ant. You can get properties out of the main module project (which is built by netbeans) over by explicitly specifying it like I indicated.
normen said:
But we don't have a folder called home/johan and NetBeans does not commit the private project properties? Your SDK/NetBeans creates it.
Again, the projects on the server that are not modules are *not* built with the jme ecosystem but you just call them via ant. You can get properties out of the main module project (which *is* built by netbeans) over by explicitly specifying it like I indicated.
Which is exactly my point.
When building plain java projects in the server they are not built with the jme ecosystem.
When building plain java projects in the SDK they are built with the jme ecosystem.
There is a difference between building in the SDK and on the server, I know that. But there is no need to have this difference, it serves no purpose.
@jmaasing said:
There is a difference between building in the SDK and on the server, I know that. But there is no need to have this difference, it serves no purpose.
I don't get what you are saying. Should we tell Skye to manually build the nightly in his SDK or what? We don't build normal projects on that server, only the module project. How should we provide the info about what projects to build and where to put their results?
I’ll give you a rundown on how this works in case anything is unclear, I know you probably know a lot of this:
There is three project types in NetBeans that are relevant for us:
- “Normal” library or game/app projects
- Module “plugin” projects
- Suite projects containing multiple Module plugins
All of these can be built via ant but will fail to build after a svn checkout because the private properties file is missing. Actually the first only fails if it uses referenced libraries instead of a lib folder, referenced libraries are e.g. the jme ones so they get updated automatically. If you open one of these project types with a compatible NetBeans or SDK version, the properties file(s) will be created.
They contain in the case of…
- A reference to the build import file (user.properties.file) which contains a complete path for your computer and is stored in the settings folder of the SDK.
- Nothing, the module has a reference to your suite (in case its a suite member, else its the same as 3))
- A reference to your build import file plus a file that references the location of a complete netbeans install for the module imports and the harness folder which contains further needed build files.
Now, the nightly build center is only one suite project really that gets built. Its private properties file is created when the main build file is executed to reference the correct location of the netbeans folder. The suites platform.properties itself contains a link to the actual SDK Modules so that they can be found to resolve the Module references. So after checking out jmp-contrib you only need to change “…/…/jME3-SDK-3.0RC2-nightly/workspace/sdk/build/cluster” to the build/cluster folder of a compile of the SDK that you did locally to build the whole contrib suite.
So, there is only one project that is being built. That is the only thing that we can “inject” anything to. Again and again, the other “library” projects are only built if you do that manually from one of the modules build files, so the only place you can inject anything to those builds is at exactly that moment.
Can we stop spinning? I get a little dizzy too now I have to admit
Edit: That said, we can use the said properties file location and have a “version” of that as a property in the suite, people would still have to assign it to the build of the other project in their own modules build files tho.
Yes we can stop running in circles. We agree on how it works.
I presented a solution to library handling for normal projects, by making a fake server-version of “user.properties.file”, which makes the server build work exactly like as if Skye built the contrib repo in his SDK.
Even though I think that is a better way it is far from the only way and I’m a pragmatic guy, whatever works
Thanks for listening. Now go back to JOGL and XCode
@jmaasing said:
Yes we can stop running in circles. We agree on how it works.
I presented a solution to library handling for normal projects, by making a fake server-version of "user.properties.file", which makes the server build work exactly like as if Skye built the contrib repo in his SDK.
Even though I think that is a better way it is far from the only way and I'm a pragmatic guy, whatever works :)
Thanks for listening. Now go back to JOGL and XCode :)
The property user.properties.file is non-accesible for me, its in a library project that I don't build. I CAN NOT SET THAT PROPERTY IN THOSE PROJECTS, I CAN ONLY SET THOSE OF THE SUITE!!
To make it perfectly clear, you will *HAVE TO* build your projects by extending your module build file like this, *even if* I add a user.properties.file variable to the suite:
[xml]
<target name="init" depends="basic-init,files-init,build-init,-javac-init,-build-subproject"/>
<target name="-build-subproject">
<ant dir="MySubProject" inheritall="false" inheritrefs="false" target="jar">
<property name="user.properties.file" location="${user.properties.file}"/>
</ant>
</target>
[/xml]
So I now added a user.properties.file property to the build and you can try around and see that what I say is true, it only works if you modify the module build script like in the post above. I added this info to the wiki as well:
https://wiki.jmonkeyengine.org/legacy/doku.php/sdk:development:setup#building_library_jar_files_on_the_server
Thanks. I’ll try it out. I have no problem with being proven wrong
In any case I think this is a better way than adding a file path pointing to the library location in the project.properties where we started. This saves a lot of duplication and is less error prone.