So what's the conclusion? The ignore-file feature is not IDE depended, so it could in theory move to the core module. But do we want this feature to be available in Eclipse?
If not, I would go for Saros/I with Java 1.7 and Saros/E with Java 1.6 (If there are no other reasons than backwards-compatibility - as Stefan pointed out a lot of developers can not upgrade existing installations). Regards, Holger Holger Schmeisky; holge...@fu-berlin.de Takustraße 9, Room 008, Freie Universität Berlin, 14195 Berlin +49 176 64146306 Am 16.10.2014 um 15:57 schrieb Stefan Rossbach: > It does (almost ?) not matter which JDK version you use to execute > Saros, do other stuff and whatever as long as you compile the whole > source with a JDK 1.6 version. > > The reason we use 1.6 is mainly that we do not need any 1.7 features and > so provide support especially for big companies where it sometimes ain't > that easy to install > the software you like on your development PC etc. > > On 16.10.2014 15:50, Arsenij E Solovjev wrote: >> And yes, we test do static analysis on Saros with Java 1.7, but we >> build it with 1.6 >> >> On 10/16/2014 03:04 PM, Stefan Rossbach wrote: >>> Just updated to PowerMock 1.5.6 but still get the same error. >>> >>> On 16.10.2014 14:55, Stefan Rossbach wrote: >>>> The SarosSessionManagerTest runs fine but not the SarosSessionTest >>>> >>>> java.lang.VerifyError: Inconsistent stackmap frames at branch target >>>> 167 in method >>>> de.fu_berlin.inf.dpp.concurrent.watchdog.ConsistencyWatchdogClient.runRecovery(Lorg/eclipse/core/runtime/IProgressMonitor;)V >>>> at offset 212 >>>> at java.lang.Class.getDeclaredMethods0(Native Method) >>>> at java.lang.Class.privateGetDeclaredMethods(Unknown Source) >>>> at java.lang.Class.getMethod0(Unknown Source) >>>> at java.lang.Class.getMethod(Unknown Source) >>>> at >>>> org.easymock.internal.ObjectMethodsFilter.<init>(ObjectMethodsFilter.java:55) >>>> at >>>> org.easymock.internal.MocksControl.createMock(MocksControl.java:59) >>>> at org.easymock.EasyMock.createNiceMock(EasyMock.java:139) >>>> at >>>> de.fu_berlin.inf.dpp.project.internal.SarosSessionTest.setUp(SarosSessionTest.java:330) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) >>>> at java.lang.reflect.Method.invoke(Unknown Source) >>>> at >>>> org.junit.internal.runners.MethodRoadie.runBefores(MethodRoadie.java:129) >>>> at >>>> org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:93) >>>> at >>>> org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.executeTest(PowerMockJUnit44RunnerDelegateImpl.java:294) >>>> at >>>> org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTestInSuper(PowerMockJUnit47RunnerDelegateImpl.java:127) >>>> at >>>> org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTest(PowerMockJUnit47RunnerDelegateImpl.java:82) >>>> at >>>> org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runBeforesThenTestThenAfters(PowerMockJUnit44RunnerDelegateImpl.java:282) >>>> at >>>> org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84) >>>> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49) >>>> >>>> But again the compiled Saros byte code (1.7 JVM) would not cause any >>>> problems when running in a 1.7 JVM or higher. >>>> >>>> >>>> On 16.10.2014 14:48, Zieris, Franz wrote: >>>>> >>>>> Just to get this straight: >>>>> >>>>> ·There is a bug in JAssist, which is used by PowerMock, which we >>>>> use for mocking static members in some of our test cases. >>>>> >>>>> ·You are using the same settings as I did and your JUnit test cases >>>>> run smoothly? So, where is the relevant difference in our setups? >>>>> >>>>> Franz >>>>> >>>>> *From:*Stefan Rossbach [mailto:srossb...@arcor.de] >>>>> *Sent:* Thursday, October 16, 2014 2:39 PM >>>>> *To:* Zieris, Franz >>>>> *Cc:* dpp-devel@lists.sourceforge.net >>>>> *Subject:* Re: [DPP-Devel] Can the IntelliJ plugin target Java 7+ >>>>> >>>>> Fine, but this has nothing to do with Saros. Just look at the stack >>>>> trace. >>>>> >>>>> https://code.google.com/p/powermock/issues/detail?id=355 >>>>> >>>>> The bug is marked as fixed in JAssist >>>>> https://issues.jboss.org/browse/JASSIST-160 >>>>> >>>>> And still it does not work. >>>>> >>>>> On 16.10.2014 14:32, Zieris, Franz wrote: >>>>> >>>>> Hi Stefan, >>>>> >>>>> Concerning the failing JUnit tests, here is what I did: >>>>> >>>>> ·Used recent master version (commit 07e0c1e) >>>>> >>>>> ·Changed the target version of dpp.core and Saros/E >>>>> (right-click > “Build Path” > “Configure Build Path …” > Tab >>>>> “Libraries” > Select “JRE System Library [JavaSE-1.6]” > “Edit >>>>> …” > Change to “JavaSE-1.7”) >>>>> >>>>> ·Cleaned the workspace and re-build everything àno compiler errors >>>>> >>>>> ·Ran the SarosCoreTestSuite àall green >>>>> >>>>> ·Ran the SarosEclipseTestSuite à10 errors >>>>> (SarosSessionManagerTest, SarosSessionTest) >>>>> >>>>> See below for the copy-pasted error message of the failing test >>>>> class SarosSessionManagerTest. >>>>> >>>>> Franz >>>>> >>>>> Details: java.lang.VerifyError: Bad <init> method call from >>>>> inside of a branch >>>>> >>>>> Exception Details: >>>>> >>>>> Location: >>>>> >>>>> >>>>> de/fu_berlin/inf/dpp/project/internal/SarosSession.<init>(Lde/fu_berlin/inf/dpp/net/xmpp/JID;Ljava/lang/String;Ljava/lang/String;IILde/fu_berlin/inf/dpp/ISarosContext;)V >>>>> @99: invokespecial >>>>> >>>>> Reason: >>>>> >>>>> Error exists in the bytecode >>>>> >>>>> Bytecode: >>>>> >>>>> 0000000: 2a19 062b 1504 1505 2c2d 3a0d 3a0c 360b >>>>> >>>>> 0000010: 360a 3a09 3a08 3a07 1300 4fb8 0016 1006 >>>>> >>>>> 0000020: bd00 0459 0319 0853 5904 1909 5359 05bb >>>>> >>>>> 0000030: 0051 5915 0ab7 0054 5359 06bb 0051 5915 >>>>> >>>>> 0000040: 0bb7 0054 5359 0719 0c53 5908 190d 5313 >>>>> >>>>> 0000050: 0056 b800 1eb8 005a 3a0f 190f b200 2aa5 >>>>> >>>>> 0000060: 000a 2ab7 005c a700 1619 0719 0819 0915 >>>>> >>>>> 0000070: 0a15 0b19 0c19 0db7 005e 0157 b1 >>>>> >>>>> Stackmap Table: >>>>> >>>>> >>>>> full_frame(@105,{UninitializedThis,Object[#103],Object[#75],Object[#75],Integer,Integer,Object[#77],UninitializedThis,Object[#77],Object[#103],Integer,Integer,Object[#75],Object[#75],Top,Object[#4]},{}) >>>>> >>>>> >>>>> full_frame(@124,{Object[#2],Object[#103],Object[#75],Object[#75],Integer,Integer,Object[#77],Object[#2],Object[#77],Object[#103],Integer,Integer,Object[#75],Object[#75],Top,Object[#4]},{}) >>>>> >>>>> at java.lang.Class.getDeclaredMethods0(Native Method) >>>>> >>>>> at java.lang.Class.privateGetDeclaredMethods(Unknown Source) >>>>> >>>>> at java.lang.Class.getMethod0(Unknown Source) >>>>> >>>>> at java.lang.Class.getMethod(Unknown Source) >>>>> >>>>> at >>>>> >>>>> org.easymock.internal.ObjectMethodsFilter.<init>(ObjectMethodsFilter.java:55) >>>>> >>>>> at >>>>> org.easymock.internal.MocksControl.createMock(MocksControl.java:59) >>>>> >>>>> at >>>>> org.powermock.api.easymock.PowerMock.doCreateMock(PowerMock.java:2212) >>>>> >>>>> at >>>>> org.powermock.api.easymock.PowerMock.doMock(PowerMock.java:2163) >>>>> >>>>> at >>>>> >>>>> org.powermock.api.easymock.PowerMock.createNiceMock(PowerMock.java:187) >>>>> >>>>> at >>>>> >>>>> de.fu_berlin.inf.dpp.project.SarosSessionManagerTest.setUp(SarosSessionManagerTest.java:97) >>>>> >>>>> […] >>>>> >>>>> *From:*Stefan Rossbach [mailto:srossb...@arcor.de] >>>>> *Sent:* Thursday, October 16, 2014 2:23 PM >>>>> *To:* Zieris, Franz; dpp-devel@lists.sourceforge.net >>>>> <mailto:dpp-devel@lists.sourceforge.net> >>>>> *Subject:* Re: [DPP-Devel] Can the IntelliJ plugin target Java 7+ >>>>> >>>>> On 16.10.2014 14:09, Zieris, Franz wrote: >>>>> >>>>> Hi there, >>>>> >>>>> I would favor having the same Java support for all Saros >>>>> versions, so if we’d actually rely on Java 7 for Saros/I, >>>>> Saros/E should no longer support Java 6, too. >>>>> >>>>> I see two immediate technical issues here: >>>>> >>>>> (1)One change that would be necessary is in our test and >>>>> build infrastructure (“saros-build”), which currently uses >>>>> Java 7 for doing some code analysis, but Java 6 for >>>>> compilation (am I right, Arsenij?). >>>>> >>>>> (2)The second one involves our source code itself. Quick >>>>> test: Changing the target version for the Core and Saros/E >>>>> currently leads to no compilation errors, but some Saros/E >>>>> JUnit tests fail. This needs to be investigated first. >>>>> >>>>> Which JUnit tests are failing ? I am running Java JDK 1.7 and >>>>> get no failures when running a local regression ? >>>>> >>>>> >>>>> I have no idea how many Saros (actual or potential) users >>>>> out there still rely on Java 6. >>>>> >>>>> Does anyone have any numbers that could suit as a proxy? >>>>> >>>>> Stefan: Do our anonymous statistics contain the used Java >>>>> version? >>>>> >>>>> Yes they do, only spotted Java 1.7 and 1.8 so far. >>>>> >>>>> But the question is: In which module should Grahams changes be >>>>> implemented ? If it is only IntelliJ then their is no problem >>>>> to use Java 1.7 for IntelliJ and >>>>> Java 1.6 for Eclipse. >>>>> >>>>> >>>>> Franz >>>>> >>>>> *From:*Graham Allan [mailto:grundlefl...@gmail.com] >>>>> *Sent:* Wednesday, October 15, 2014 7:37 PM >>>>> *To:* dpp-devel@lists.sourceforge.net >>>>> <mailto:dpp-devel@lists.sourceforge.net> >>>>> *Subject:* [DPP-Devel] Can the IntelliJ plugin target Java 7+ >>>>> >>>>> Hi all, >>>>> >>>>> Is there any reason that the IntelliJ plugin should not >>>>> target Java 7+ as the runtime environment? >>>>> >>>>> The specific motivation for me is to be able to use Java >>>>> NIO's glob matching, in order to evaluate the rules >>>>> specified in a .gitignore file. This was previously >>>>> fulfilled by JGit, but having that dependency was seen as >>>>> undesirable, I think due to file size concerns. Not having >>>>> to reimplement glob matching (the equivalent of the POSIX >>>>> fnmatch function) would save a lot of effort and maintenance. >>>>> >>>>> Another approach would be to pull out the part of JGit >>>>> which did this, which targeted Java 5 I believe, and >>>>> include this source code in Saros. That code is under the >>>>> Eclipse Public License, I'm not 100% sure on the legality >>>>> of that, or the impact of including something non-GPL in >>>>> the Saros distributable, but I think that's valid. >>>>> >>>>> Cheers, >>>>> Graham >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> Comprehensive Server Monitoring with Site24x7. >>>>> >>>>> Monitor 10 servers for $9/Month. >>>>> >>>>> Get alerted through email, SMS, voice calls or mobile push >>>>> notifications. >>>>> >>>>> Take corrective actions from your mobile device. >>>>> >>>>> http://p.sf.net/sfu/Zoho >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> >>>>> DPP-Devel mailing list >>>>> >>>>> DPP-Devel@lists.sourceforge.net >>>>> <mailto:DPP-Devel@lists.sourceforge.net> >>>>> >>>>> https://lists.sourceforge.net/lists/listinfo/dpp-devel >>>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Comprehensive Server Monitoring with Site24x7. >>>> Monitor 10 servers for $9/Month. >>>> Get alerted through email, SMS, voice calls or mobile push notifications. >>>> Take corrective actions from your mobile device. >>>> http://p.sf.net/sfu/Zoho >>>> >>>> >>>> _______________________________________________ >>>> DPP-Devel mailing list >>>> DPP-Devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/dpp-devel >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Comprehensive Server Monitoring with Site24x7. >>> Monitor 10 servers for $9/Month. >>> Get alerted through email, SMS, voice calls or mobile push notifications. >>> Take corrective actions from your mobile device. >>> http://p.sf.net/sfu/Zoho >>> >>> >>> _______________________________________________ >>> DPP-Devel mailing list >>> DPP-Devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/dpp-devel >> >> >> >> ------------------------------------------------------------------------------ >> Comprehensive Server Monitoring with Site24x7. >> Monitor 10 servers for $9/Month. >> Get alerted through email, SMS, voice calls or mobile push notifications. >> Take corrective actions from your mobile device. >> http://p.sf.net/sfu/Zoho >> >> >> _______________________________________________ >> DPP-Devel mailing list >> DPP-Devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dpp-devel > > > > ------------------------------------------------------------------------------ > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > > > > _______________________________________________ > DPP-Devel mailing list > DPP-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dpp-devel > ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ DPP-Devel mailing list DPP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dpp-devel
