Hi Mark & Tobi, > 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...
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. 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. 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. > for you to release something against java 7 we would need to ensure > it's installed and exposed to Release-Version 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. Regards, Curtis On Fri, Feb 13, 2015 at 9:51 AM, Mark Hiner <hi...@wisc.edu> wrote: > Hi Tobias, > > On Fri, Feb 13, 2015 at 9:36 AM, Tobias Pietzsch <pietz...@mpi-cbg.de> > wrote: > >> invalid target release: 1.7 > > > > See http://stackoverflow.com/questions/19891423/invalid-target-release-1-7 > > 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 > > 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... >
_______________________________________________ ImageJ-devel mailing list ImageJ-devel@imagej.net http://imagej.net/mailman/listinfo/imagej-devel
