<div dir="ltr"><div><div><div>Hi Tobias,<br><br></div>There is now a Release-Version-Java7 job. I moved bigdataviewer_server to this new job. Let us know if there are any problems.<br><br></div>Best,<br></div>Mark<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 13, 2015 at 10:07 AM, Curtis Rueden <span dir="ltr"><<a href="mailto:ctrueden@wisc.edu" target="_blank">ctrueden@wisc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Mark & Tobi,<span class=""><div><br></div><div><div>> I was thinking a separate Release_Version job, as opposed to</div><div>> configuration in the current job, to avoid accidentally releasing</div><div>> artifacts compiled with Java 7 that need to be Java 6 compatible...</div></div><div><br></div></span><div>Indeed, the problem is that the Release-Version job is configured to use Java 6 to build and deploy. The BigDataViewer-server job is successful is because I set it to use Java 7.</div><div><br></div><div>We could configure the Release-Version job to use a different Java version depending on the selected artifact, but it would probably not be worth the hassle. As Mark suggests, easier will be to create a Release-Version-Java7 job for the Java7-based jobs.</div><div><br></div><div>I am out of the office today, but maybe one of you guys could create that job. Or else I can do it when I return to the office on Tuesday.</div><span class=""><div><br></div><div><div>> for you to release something against java 7 we would need to ensure</div><div>> it's installed and exposed to Release-Version</div></div><div><br></div></span><div>Note that dev _does_ already have Java 7 installed. It's just not the default for Jenkins. But it's available in the list of JVMs.</div><div><br></div><div>Regards,</div><div>Curtis</div><div><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 13, 2015 at 9:51 AM, Mark Hiner <span dir="ltr"><<a href="mailto:hiner@wisc.edu" target="_blank">hiner@wisc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Hi Tobias,<br><br></div><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 13, 2015 at 9:36 AM, Tobias Pietzsch <span dir="ltr"><<a href="mailto:pietzsch@mpi-cbg.de" target="_blank">pietzsch@mpi-cbg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> invalid target release: 1.7</blockquote></div><br><br>See <a href="http://stackoverflow.com/questions/19891423/invalid-target-release-1-7" target="_blank">http://stackoverflow.com/questions/19891423/invalid-target-release-1-7</a><br><br></div><div class="gmail_extra">java -version is 1.6.0_45 for dev. So for you to release something against java 7 we would need to ensure it's installed and exposed to Release-Version<br><br></div><div class="gmail_extra">Curtis - do you have a preference on how to handle Java 7 releases? I was thinking a separate Release_Version job, as opposed to configuration in the current job, to avoid accidentally releasing artifacts compiled with Java 7 that need to be Java 6 compatible...<br></div></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>