it’s still happening? i thought it was fixed when we changed the install4j file… which install4j version are we using? I’m testing with 5.1.7… i think 5.1.8 is the latest.
in any event, it’s defenitely an install4j problem since the launcher it creates is responsible for setting up the classpath, etc. Perhaps there is a setting for “only use the bundled jre, damnit!”?
i’ve not been following lately… has the About Box patch gone in yet? The latest patch I posted showed in the about box which JRE spark was actively using… may be helpful in troubleshooting.
it’s still happening? i thought it was fixed when we changed the install4j file… which install4j version are we using? I’m testing with 5.1.7… i think 5.1.8 is the latest.
Well, as i’m using the offline installer and no java 6 installed on my system it should be the same behavior with the contact list and i haven’t noticed slow downs in the recent SVN versions. Skins will stay i think. Default one is JTattoo Luna and i don’t thin many users will change that (though i use Substance myself).
You can deactivate plugins in spark.properties file, like:
deactivatedPlugins=Reversi,Translator Plugin,Spellchecker Plugin,Spellchecker Plugin,Media Player Plugin,Fastpath,OTR Plugin
Jason, it was still happening with the 632 build, which was the latest till yesteday when Daryl changed min/max java versions in Bamboo. Current build is 642 (took a few attempts to make it working ) and it uses Java 7, even if Java 6 is installed on the system.
I believe your patch is still not applied. I think i will assign it to Mircea (have already 3 patches queued for him to commit). He is one fairly active committer now. So i hope he will push it.
I think the last thing Tim had said would be a “nice to have” would be the build number in the about box. Unfortunately I’m not familiar enough with Bamboo to make that integration. I had played around previously with ANT updating some of the properties files during compilation (to inject build date, and possibly number) but it recks the properties file’s formatting doing so
Yes, bamboo checks out what’s in subversion. I am not sure what you mean by exporting the bamboo config, I could probably give you access to bamboo to check it out. http://bamboo.igniterealtime.org
I wasn’t sure if bamboo had a config in addition to the ant/install4j scripts.
It might be worth trying out the attached install4j file. It should be updated for 5.1.9 fully, and includes the other changes you made for j7/8.
I've also attached Build.patch, which includes a patch form of the spark_install4j_5_1_9.install4j file to replace the current spark.install4j. The Build.patch also finishes iterating spark to use java 7, removes java 5 and 6 as acceptable to ant, and sets the source as java 7 and target as 7 (has to do with compiler optimizations). The patch also updates some old information in the build scripts and also updates the version number to 2.7.0-nightly (so forum nightly-build downloaders can tell a difference).
If committed in a chunk, the commit message should be along the lines of "Update Spark build scripts, and forbid old java versions"
The attached UpdatePluginsForJava7.patch file does just that... it updates all the standard Spark plugins to build with java7, forbid old java versions, and forbid old Spark versions (because java7 built plugins won't work on old spark).
Commit message would be along the lines of "Updated plugins to use java 7, forbid old versions"
pain for bamboo, or the forum? ultimately it’d be nice to have the build number somewhere in there, but that will take some creativity with bamboo and the build scripts.
Hmm, well I see notes about install4j not supporting “extra version info” like “beta”, but this may be fixed now… my builds seem ok.
If there is no significance to the current extra version number 12555, then the attached patch will replace it at build time with the bamboo build number. Bamboo would need to change its ant invocation to pass the parameter “bamboo. build” into ant.
From:
ant installer.install4j
To:
ant installer.install4j -Dbamboo.build=${bamboo.buildkey}
The bamboo builds pass the version info from the ant script directly into the install4j parameters which bypasses the version info that’s inside the spark.install4j file. So, this allows us to dynamically set the build number. If we like this patch, then ill update SPARK-33 to use this build number as well.
@daryl the current bamboo install4j build is failing because the build server doesnt have the linux-x86-1.7.0_51.tar.gz jre file… ejtech dont make one for some odd reason so its not available for automatic download. Its simple to make the package, but annoyingly enough you cant make the linux package from windows, and furthermore must make the 32bit package using a 32bit libc, which my home server doesnt have because its 64 bit… gah!
its late, so ill fix my server and make that missing package sometime tomorrow. UseBambooBuildNums.patch.zip (1255 Bytes)
Darn the RPM! That’s why I haven’t seen that issue, I don’t build the RPM over here, only the exe.
Well, the patch in post #235811 above will fix that, it just re-uses the version.extra field and does not add any textual version info.
re: the 125555 build number. I could be wrong, but i think the Client Management OF plugin may use that field as part of it’s determination of what is a “newer” client version for pushing updates. So a jump backwards for this number may cause a problem if the rest of the number isn’t updated at the same time (ie. 2.6.3 --> 2.7.0). I could be wrong, this is just off the top of my head, but seems reasonable.
it may need the quotes removed from value="${bamboo.build}" on line 33 of build.xml… I’ll play with it. I don’t have bamboo here, but last night passing a parameter into the ant cmd worked well. So long as ${bamboo.buildkey} is an actual bamboo environment variable for our version of bamboo, it should work.
Ugh is not an error message i believe. What is happening? 51 is almost month old and i had no problem running any Spark build on it.
Jason, you may be right about that build number related to Client Management plugin, though i never saw much use of such deployment. Users have to have elevated privileges to be able to install new version of Spark and this is not right So, if this brakes Client Management deployment, then we can think how to fix it, if someone really complains about that. Not a priority.