Community
Participate
Working Groups
Many modeling project have Java 1.5 set as minimum requirement. As Graphiti is bound to Java 1.6 this makes it harder to integrate it with other projects. Thus it would be nice to lower the minimum required setup for Graphiti.
Apparently, Java 6's javac allows to generate Java 5 binaries, even from Java-6 source code, so that it would be feasible to provide some (alternative) Java-5 compatible jars? See http://stackoverflow.com/questions/987973/eclipse-complaining-about-override/987992#987992
(In reply to comment #1) > Apparently, Java 6's javac allows to generate Java 5 binaries, even from Java-6 > source code, so that it would be feasible to provide some (alternative) Java-5 > compatible jars? See > http://stackoverflow.com/questions/987973/eclipse-complaining-about-override/987992#987992 This would probably solve the issues with running Graphiti on Java 1.5, but when I think about that I have some doubts if that will really help: - Will it solve the incompatibility in pack200 between Java 1.6 and Java 1.5 Martin originally had trouble with, see index.php?t=rview&goto=748244#msg_748244 - The plugin metadata still point out that the plugin needs Java 1.6, not sure about any side effects... - How to pass that option to our Buckminster build? (Could possibly be done using a template workspace?)
(In reply to comment #0) > Many modeling project have Java 1.5 set as minimum requirement. As Graphiti is > bound to Java 1.6 this makes it harder to integrate it with other projects. > Thus it would be nice to lower the minimum required setup for Graphiti. This would definitely lower the integration barrier for other modeling projects and from that point of view I would like to do it. On the downside we have around @override tags spread accross most classes of the framework that would need to be removed and the Eclipse quick fix seems not to be capable of fixing multiple issues at once...
I understand the value of @Override tags on interface methods and if Graphiti would like to try the combination of 1.6 source compatibility plus 1.5 BREE we (the CDO project) could test whether the build output of that still requires modified consumer builds.
Thanks Eike for offering that! So, I will do that change (1.5 BREE, compiler compliance 1.6, class and source compatibility 1.5 as described in the forum Hernan linked). I will let you know as soon as we have a build result available.
Great Micheal! BTW. we've found out how to cope with 1.6 packed bundles in our Buckminster build: <target name="provision" depends="-init.tools,-init.buildinfos,-init.workspace" description="Imports projects and binaries"> <echo message="Importing projects into ${ws}" /> <echo message="Importing binaries into ${tp}" /> <mkdir dir="${tp}" /> <buckminster command="import"> <cmdargs> *<jvmarg value="-Dorg.eclipse.update.jarprocessor.pack200=/shared/common/jdk-1.6.0_26.x86_64/bin" />* <arg value="-B" /> <arg value="${hudson.WORKSPACE}/bom.xml" /> <arg value="-P" /> <arg value="${basedir}/build.properties" /> <!-- Last argument: --> <arg value="${basedir}/build.mspec" /> </cmdargs> </buckminster> </target> But it took us hours and hopefully your change will spare that for other projects ;-)
Change is checked-in to head: commit ce4a132ea0547dd1303994883fdcffaa02824cd0 Author: mwenz <michael.wenz@sap.com> 2011-10-26 14:01:28 Committer: mwenz <michael.wenz@sap.com> 2011-10-26 14:01:28 Parent: 85c329ec26bd7c48a804c28b8b50b23c7e6bbb19 (Enhanced JavaDoc ) Branches: origin/master, master
We're currently consuming Graphiti via http://download.eclipse.org/graphiti/updates/milestones . I guess we'll see a new drop there after November 8, right?
(In reply to comment #8) > We're currently consuming Graphiti via > http://download.eclipse.org/graphiti/updates/milestones . I guess we'll see a > new drop there after November 8, right? We had some trouble with our build, but that's fixed now. A dev build already went through and will be published in about an hour to our nightly update site (http://download.eclipse.org/graphiti/updates/nightly). Alternatively I can provide an integration build (signed etc.) tomorrow.
Hi Michael, we will try your nightly build. Just let us know when your build is ready, then we will modify ours ;)
Our nightly update site at http://download.eclipse.org/graphiti/updates/nightly/ is filled now and contains the Java 1.5 compatible JARs.
Hi Michael, the import phase of our build succeed. The build finally failed, but I think the only happened because of some differences between the last Graphiti Milestone and the nightly build. I guess that the org.eclipse.graphiti.ui.editor.DiagramEditorFactory has been removed or rename. I'll try to fixed this and also check the 1.5 compatibility in my local workspace. But I am quite optimistic that it worked ;) ---------------------------- [java] Error: file /opt/public/jobs/emf-cdo-integration/workspace/git/plugins/org.eclipse.emf.cdo.dawn.graphiti/src/org/eclipse/emf/cdo/dawn/graphiti/editors/DawnGraphitiDiagramEditorFactory.java, line 17: The import org.eclipse.graphiti.ui.editor.DiagramEditorFactory cannot be resolved [java] Error: file /opt/public/jobs/emf-cdo-integration/workspace/git/plugins/org.eclipse.emf.cdo.dawn.graphiti/src/org/eclipse/emf/cdo/dawn/graphiti/editors/DawnGraphitiDiagramEditorFactory.java, line 23: DiagramEditorFactory cannot be resolved to a type [java] Error: file /opt/public/jobs/emf-cdo-integration/workspace/git/plugins/org.eclipse.emf.cdo.dawn.graphiti/src/org/eclipse/emf/cdo/dawn/graphiti/editors/DawnGraphitiDiagramEditorFactory.java, line 26: The method createElement(IMemento) of type DawnGraphitiDiagramEditorFactory must override a superclass method [java] Warning: file /opt/public/jobs/emf-cdo-integration/workspace/git/features/org.eclipse.emf.cdo.dawn.examples-feature/feature.xml, line 39: Feature reference 'org.eclipse.emf.cdo.dawn.examples.source' cannot be resolved
(In reply to comment #12) > Hi Michael, > the import phase of our build succeed. The build finally failed, but I think > the only happened because of some differences between the last Graphiti > Milestone and the nightly build. I guess that the > org.eclipse.graphiti.ui.editor.DiagramEditorFactory has been removed or rename. Great to hear! Yes, the DiagramEditorFactory has been renamed to DiagramEditorInputFactory. That reflects what it really is and was part of our editor API cleanup.
Hi Michael, bad news. I changed name of the DiagramEditorInputFactory which made our build pass. That's actually good. But then I tried to run a example from a 1.5 workspace and got the attached exception. It seems that the compiled code is not compatible to the Java 1.5 API as String.isEmpty() is only available in Java 1.6 :( java.lang.NoSuchMethodError: java.lang.String.isEmpty()Z at org.eclipse.graphiti.internal.services.impl.MigrationServiceImpl.shouldMigrate080To090(MigrationServiceImpl.java:90) at org.eclipse.graphiti.ui.internal.editor.DiagramEditorInternal.migrateDiagramModelIfNecessary(DiagramEditorInternal.java:1107) at org.eclipse.graphiti.ui.internal.editor.DiagramEditorInternal.init(DiagramEditorInternal.java:1094) at org.eclipse.emf.cdo.dawn.graphiti.editors.DawnGraphitiDiagramEditor.init(DawnGraphitiDiagramEditor.java:68) at org.eclipse.ui.internal.EditorManager.createSite(EditorManager.java:828) at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:647) at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:465) at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:595) at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:315) at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:180) at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java:270) at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65) at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:473)
(In reply to comment #14) > Hi Michael, > bad news. I changed name of the DiagramEditorInputFactory which made our build > pass. That's actually good. > But then I tried to run a example from a 1.5 workspace and got the attached > exception. It seems that the compiled code is not compatible to the Java 1.5 > API as String.isEmpty() is only available in Java 1.6 :( > java.lang.NoSuchMethodError: java.lang.String.isEmpty()Z That's really bad news. Strangely enough, I don't get a compile error for Graphiti as long as I use JDK 1.6 (which I need to use for the @override tags), although I said my source shall be 1.5 compatible... Seems as if the elegant and easy solution does not work out...
I have just re-checked this and I see only one option to get Java 1.5 compliant: the complete removal of all interface @override tags and the removal of all Java 1.6 API usages (actually 4 usages of String.length()). The tried solution does not work out, because we do not see any potential issues of accidentally using Java 1.6 APIs with these settings. Let me know if there is anything I missed or should try additionally. So I would propose for now (M3 being right in front of us) to revert the changes done for this and go for the full blown solution (maybe in M4) if we get it fit in. Please let me know what you think of this.
Hi Michael, I've not yet tried it myself but lately I've stumbled about these JRE system library profiles: http://eclipseandjazz.blogspot.com/2011/10/of-invalid-references-to-system.html Maybe that helps?
(In reply to comment #17) > Hi Michael, I've not yet tried it myself but lately I've stumbled about these > JRE system library profiles: > http://eclipseandjazz.blogspot.com/2011/10/of-invalid-references-to-system.html > Maybe that helps? Eike, thanks for digging that out. Looks very promising at first glance. I will give it a try. Michael
(In reply to comment #17) > > Hi Michael, I've not yet tried it myself but lately I've stumbled about these > > JRE system library profiles: > > http://eclipseandjazz.blogspot.com/2011/10/of-invalid-references-to-system.html > > Maybe that helps? It seems I managed to set everything correctly, so now we get error markers for using stuff only available in Java 1.6 while the @override tags are still allowed. We are using JDK 1.6 to build against, but are creating Java 1.5 compatible class files. I needed to enable the API tooling for our examples and test plugins which we had not so far because they are no API. But since everything is nicely configurable this not an issue. One thing that is not that nice is that every Graphiti framework developer needs to set up the supported environment descriptions; if ha has not installed them he will get cryptical build errors (plugin can only be build if other plugin's classpath is fixed, although other plugin build...). But I think we can live with that; I added a note to our workspace setup description at http://wiki.eclipse.org/GMP/Graphiti#Workspace_Settings and will send around an email to the dev mailing list. Martin: A dev build already went through, but is not promoted yet. I want to provide a first milestone build for M3 today, so you might use that for trying as soon as it's available (I will post a note here).
(In reply to comment #19) > > Martin: A dev build already went through, but is not promoted yet. I want to > provide a first milestone build for M3 today, so you might use that for trying > as soon as it's available (I will post a note here). This sounds really great! Thanks Michael for your help. Just give me a note if the build is available and I'll test it.
(In reply to comment #20) > This sounds really great! Thanks Michael for your help. Just give me a note if > the build is available and I'll test it. Ok, here's the note... ;-) It's part of our first M3 milestone version and available via our milestones update site at http://download.eclipse.org/graphiti/updates/milestones
My local testing passed. I had no trouble when playing with the diagrams in a workspace that is operating on Java 1.5. I recently started our build. It is not finished yet, but the important phase (import and the compiling) succeeded. :)
I noticed some issue with an RCP app running on JDK 1.5, so the solution seemed not to work completely. Also there were issues with the PDE update classpath functionality: it reset the compliance settings each time. Another point were the strange compiler errors that caused more confusion than actually helped. So, I decided to this time really go and make Graphiti Java 1.5 compliant. I have removed all the override annotations on interface method implementations and correted the compiler settigns accordingly. Now the frameworks smoothly works on top of Java 1.5 and should easily integrate with other Java 1.5 modeling projects. Graphiti framework developers will now need to install a JDK 1.5 for their local development, otherwise they will get compile errors (this time they actually tell what's wrong). The fix is comitted and pushed to Eclipse.org. commit 2d6f1a943d3c0373855bc148a3f1a8af28e305c9 Author: mwenz <michael.wenz@sap.com> 2011-11-09 16:29:31 Committer: mwenz <michael.wenz@sap.com> 2011-11-09 16:29:31 Parent: 913ce8cddf8d0a71c593e9c26d0745bc12484245 (Bug 352440: Fixed some more warnings) Branches: origin/master, master A first build is available via our nightly update site at http://download.eclipse.org/graphiti/updates/nightly
That's bad news because we planned to go with 1.6 source compliance, too, in CDO ;-(
(In reply to comment #24) > That's bad news because we planned to go with 1.6 source compliance, too, in > CDO ;-( Well, it won't harm in that: Java 1.6-based users of Graphiti are not affected by this change. And this change might enable other usages of Graphiti in Java 1.5-based environments...
I was not talking about your users but about my own edvelopers (and myself) why would also have liked to add @Override to our interface methods ;-)
Bookkeeping: Set target release
Part of Graphiti 0.9.0 (Eclipse Juno)
