Community
Participate
Working Groups
The JPA Editor is now moved in CVS from the Incubator module to the org.eclipse.jpa module. Then next steps is to integrate it in the PDE Build. So far, Stefan added a new map file in the releng.dali project. This is the jpaeditor.map. Inside he declared the feature, the plugin and the test plugin. How do we proceed as a next step?
I assume the intention here is to include the diagram editor into the Dali build distribution. Is that correct? If so, we need to make some changes in the Dali build to include the map file and the dependencies. Can you list all (additional) dependencies required to build the diagram editor, and where these dependencies are obtained from? From there we can probably make the necessary changes to releng to make this happen.
(In reply to comment #1) > I assume the intention here is to include the diagram editor into the Dali > build distribution. Is that correct? Yes, it's correct. > If so, we need to make some changes in > the Dali build to include the map file and the dependencies. Can you list all > (additional) dependencies required to build the diagram editor, and where > these dependencies are obtained from? Here is the list of all the required bundles from the editor plugin: --------------------------- org.eclipse.ui.ide, org.eclipse.gef, org.eclipse.ui.views.properties.tabbed, org.eclipse.jdt.ui, org.eclipse.core.runtime, org.eclipse.jpt.common.ui, org.eclipse.jpt.common.utility, org.eclipse.jpt.common.core, org.eclipse.jdt.core, org.eclipse.core.resources, org.eclipse.emf.ecore, org.eclipse.emf.common, org.eclipse.wst.common.emf, org.eclipse.wst.common.modulecore, org.eclipse.wst.common.project.facet.core, org.eclipse.jdt.core.manipulation, org.eclipse.emf.transaction, org.eclipse.graphiti, org.eclipse.graphiti.mm, org.eclipse.graphiti.pattern, org.eclipse.graphiti.ui, org.eclipse.core.expressions, org.eclipse.emf.ecore.xmi, org.eclipse.jpt.jpa.ui, org.eclipse.jpt.jpa.core ------------------------------------- and from the editor test plugin: ------------------------------------ org.eclipse.core.resources, org.eclipse.jdt.core, org.easymock, org.eclipse.jpt.common.core, org.eclipse.wst.common.project.facet.core, org.eclipse.jpt.ui.diagrameditor, org.eclipse.jpt.common.utility, org.eclipse.jpt.jpa.core, org.eclipse.jpt.jpa.db, org.eclipse.jpt.jpa.ui, org.eclipse.ui, org.eclipse.gef, org.eclipse.jpt.common.ui, org.eclipse.ui.ide, org.eclipse.ui.views.properties.tabbed, org.eclipse.emf, org.junit, org.junit4, org.eclipse.emf.common, org.eclipse.emf.ecore, org.eclipse.graphiti, org.eclipse.graphiti.ui, org.eclipse.graphiti.pattern, org.eclipse.emf.edit, org.eclipse.emf.transaction, org.eclipse.wst.common.frameworks, org.eclipse.wst.common.modulecore, org.eclipse.emf.ecore.xmi ------------------------------------ Until now we had only two repositories in the releng project pom.xml: ---------------------- <repository> <id>helios</id> <url>http://download.eclipse.org/releases/helios/</url> <layout>p2</layout> </repository> <repository> <id>graphiti</id> <url>http://download.eclipse.org/graphiti/updates/0.7.1</url> <layout>p2</layout> </repository> ---------------------------- but now it seems that they are no more relevant (there is a question from me about this in dali-dev mailing list. Appears that the latest Graphiti could be found at: http://download.eclipse.org/releases/helios/ but I don't know aabout all the others.
(In reply to comment #2) > ... Appears that the latest Graphiti could be > found at: http://download.eclipse.org/releases/helios/ ... Oops, mistake: the correct link here is: http://download.eclipse.org/releases/indigo/
I've submitted the code in CVS
As discussed on the mailing list, Tran is going to work on integrating the diagram editor code into the Dali build over the weekend. Assuming the right code is checked into CVS (which Stefan has just indicated is the case), we should be able release it and proceed from there. This bug will be updated to indicate progress/problems.
After a first test it looks like that Graphity is dependent on EMF components that are not currently in Indego. org.eclipse.emf.transaction_[1.3.0,2.0.0) org.eclipse.emf.validation_[1.2.0,2.0.0) David, is this a matter of adding new dependencies the builder(i.e. to define prereq.emfxxx targets in dependency.xml, and set the prereq to be installed for Dali), or do you see other complications?
(In reply to comment #6) > After a first test it looks like that Graphity is dependent on EMF components > that are not currently in Indego. > > org.eclipse.emf.transaction_[1.3.0,2.0.0) > org.eclipse.emf.validation_[1.2.0,2.0.0) > > David, is this a matter of adding new dependencies the builder(i.e. to define > prereq.emfxxx targets in dependency.xml, and set the prereq to be installed for > Dali), or do you see other complications? Yes, mostly a matter of defining prereq.emfxxx flags and targets (with corresponding entries in .../indigo/dependencies.properties and .../indigo4/dependencies.properties. There's also some places in wtp.site that should be updated, (see displayprereqs.php) so the download pages show what is required. But, not sure what you mean by "...that are not currently in Indigo". I'm fairly sure those projects _are_ planning to have an Indigo release and currently in common repo. If that is not the case, they are not participating in Indigo release ... then that is an entirely new problem ... we could not use them if they do not participate in Indigo ... but, fairly sure they would be ... so assuming you meant "... not currently in our Indigo dependency files".
Yes I meant "not currently in our Indigo dependency files", those projects are planning to have an Indigo release. I made/released the required changes for adding org.eclipse.emf.transaction and org.eclipse.emf.validation as dependencies. You can start the build when it is convenient to you. Thanks.
Bundle org.eclipse.graphiti_0.7.1.v20110110-1225 failed to resolve.: Missing required plug-in org.eclipse.emf.transaction_[1.3.0,2.0.0). The good news, the logs shows that it succeed to download and install the emf-validation prereq. The bad news is there is no logs for the emf.transaction prereq. I am still investigating, it is almost the same code so I am not sure why it didn't run. David, do you have any thoughts.
I just saw that you made the correction and started the build. Indeed it helps to call it also :)... Thank you!
Yes, here's what I've seen so far ... not all this checked in yet ... to "test" a build is slow since so much has to be done before getting to Dali. Guess we could have resurected the standalone Dali build .... but ... here's my observations ... 1. scripts/dependency/dependency.xml [mentioned by Tran in previous comment, already] There's a list where each potential prereq target is call. prereq.emftransaction was missing. (emfvalidation was there, probably there from some past need). Without that, emftransaction is never fetched, installed. 2. dependencies.properties Better to use "repos" and "featuresToBeInstalled". For two reasons. 1) It provides a check or test that our prereqs are actually installable. Otherwise, if just unzip, then problems may not show up until much later. Better to fail fast. 2) Allows more selectivity. For example, if all of "validation" is taken, then that includes org.eclipse.emf.validation.ocl which requires org.eclipse.ocl ... doubt we need that, I assume. (I know we only display zip's in prereq section ... it'd be a nice improvement to display repos ... or, provide scripts, or something). I've added 'repo' variables and the feature.groups I think are needed. [Haven't checked in yet, will after some more tests runs.] 3. wtp.site/templateFiles/buildvariables.php I know these variables ... $prereq_emftransaction="@prereq.emftransaction@"; $prereq_emfvalidation="@prereq.emfvalidation@"; look like they should by replaced dynamically, and that's the idea ... never got to coding that ... so for now the need to be hard coded. $prereq_emftransaction="true"; $prereq_emfvalidation="true"; 4. dependencies.properties changed name/description to say "required for JPA Editor" as some might be concerned if list of pre-reqs increased ... and we shouldn't require those elsewhere, without an explicit discussion and decision. 5. dependencies.properties all those "...source..." varables are no longer used, and not needed ... though no way you could have known that. I removed them all. 6. dependencies.properties Seeing your work inspired me to clean up this file, reorgainize some of it, and make consistent from one prereq to another. I'm sure could be improved further. This'll be good long term, I think ... but will make it hard to "compare" with previous versions. [Haven't checked in yet, will after some more tests runs.] In the future ... for a big change such as this, we should figure out a way to "work in a branch" until its working ... and then merge with HEAD, so as to not leave main build broken.
I see one of the prereqs ... graphiti? has a prereq for gef [3.5,3.7) ... should be [3.5,3.8) for indigo, right? Have you created an environment (workspace and pde target) and try to "export runnable feature"? That's usually a good test to do locally.
Yep, org.eclipse.graphiti.ui has a too narrow range for Indigo. Since presumably you'll need to wait for them to change, can you back out your JPA Editor feature in assembly so we can get a good build? I'd like to make sure everything still works after my big changes to dependencies.properties file. (I have checked them in, now). 629913 [build-wtp4x-dali4x-sdk] generateScript: 629914 [build-wtp4x-dali4x-sdk] [eclipse.buildScript] Some inter-plug-in dependencies have not been satisfied. 629915 [build-wtp4x-dali4x-sdk] [eclipse.buildScript] Bundle org.eclipse.graphiti.ui: 629916 [build-wtp4x-dali4x-sdk] [eclipse.buildScript] Missing required plug-in org.eclipse.gef_[3.5.0,3.7.0). 629917 [build-wtp4x-dali4x-sdk] [eclipse.buildScript] Bundle org.eclipse.emf.validation.ocl: 629918 [build-wtp4x-dali4x-sdk] [eclipse.buildScript] Missing required plug-in org.eclipse.ocl_[1.3.0,4.0.0). 629919 [build-wtp4x-dali4x-sdk] [eclipse.buildScript] Missing required plug-in org.eclipse.ocl.ecore_[1.3.0,4.0.0). 629920 [build-wtp4x-dali4x-sdk] 629921 [build-wtp4x-dali4x-sdk] BUILD FAILED 629922 [build-wtp4x-dali4x-sdk] /home/shared/webtools/projectBuilders/wtp4x-R3.3.0-I/webtools.releng/releng.wtpbuilder/scripts/build/runbuild.xml:143: The following error occurred while executing this line: 629923 [build-wtp4x-dali4x-sdk] /home/shared/webtools/basebuilders/v20110216/org.eclipse.releng.basebuilder/plugins/org.eclipse.pde.build_3.6.100.v20110121-1730/scripts/build.xml:35: The following error occurred while executing this line: 629924 [build-wtp4x-dali4x-sdk] /home/shared/webtools/basebuilders/v20110216/org.eclipse.releng.basebuilder/plugins/org.eclipse.pde.build_3.6.100.v20110121-1730/scripts/build.xml:91: The following error occurred while executing this line: 629925 [build-wtp4x-dali4x-sdk] /home/shared/webtools/projectBuilders/wtp4x-R3.3.0-I/webtools.releng/releng.wtpbuilder/components/dali4x-sdk/customTargets.xml:103: The following error occurred while executing this line: 629926 [build-wtp4x-dali4x-sdk] /home/shared/webtools/projectBuilders/wtp4x-R3.3.0-I/webtools.releng/releng.wtpbuilder/components/dali4x-sdk/allElements.xml:37: The following error occurred while executing this line: 629927 [build-wtp4x-dali4x-sdk] /home/shared/webtools/basebuilders/v20110216/org.eclipse.releng.basebuilder/plugins/org.eclipse.pde.build_3.6.100.v20110121-1730/scripts/genericTargets.xml:107: Processing inclusion from feature org.eclipse.jpt.jpa.eclipselink.feature: Bun dle org.eclipse.graphiti.ui_0.7.1.v20110111-0756 failed to resolve.: 629928 [build-wtp4x-dali4x-sdk] Missing required plug-in org.eclipse.gef_[3.5.0,3.7.0).
(In reply to comment #13) > Yep, org.eclipse.graphiti.ui has a too narrow range for Indigo. > > Since presumably you'll need to wait for them to change, can you back out your > JPA Editor feature in assembly so we can get a good build? I'd like to make > sure everything still works after my big changes to dependencies.properties > file. (I have checked them in, now). I have backed out and released.
> > I have backed out and released. Looks like basics ran, but other parts of your code had "ordinary" compile errors ... so, still didn't get to the unit tests. I'd like to get that working ... before trying JPA Editor again ... because we should now have Ant 1.8.2 in Eclipse and in the builder ... so, just want to make sure there's no issues with that. You'll also notice your two new "prereqs" are not being displayed. Here's rough outline of what needs to happen to get that working, if you haven't already. 1. May need to add some lines in buildvariables.php. This file _is_ updated during the build, by the ant script in publish.xml, so you'll need to edit it also so it does the right "<replace" for the various transaction and validation variables. Its very tedious, but they all follow a pattern. (And, just has to be done once). This is basically the way we convert ant property values into PHP variable values (I'm sure there's easier ways :) 2. I suggest you move your pre-reqs "down" in the list, so that EMF and GEF come above them ... the idea is not appear to change priority or important of those. Good luck. Oh .. and even this PHP work should wait until we get a good run. Thanks,
David, can the compilation errors be caused by a glitch of the system? The wtp and the wtp4x builds shared the same maps (at least for Dali), and the same JPT plugins in the wtp4x build passed the compilation. Also I forgot to modify in the builder the variables that are responsible for emftransaction and emfvalidation prereqs to be installed. But I guess it does not get pulled in since no code are referencing it.
(In reply to comment #16) > David, can the compilation errors be caused by a glitch of the system? > The wtp and the wtp4x builds shared the same maps (at least for Dali), and the > same JPT plugins in the wtp4x build passed the compilation. > There were other differences ... new Platform, new version of ICU4J ... I opened bug 337699, and reverted back to M5 level of the Platform, and restarted a new wtp I build. We (i.e. you) might have to change your source to match new version of ICU ... but ... figured we'd see what they say in bug 337699. (when it rains, it pours) > Also I forgot to modify in the builder the variables that are responsible for > emftransaction and emfvalidation prereqs to be installed. But I guess it does > not get pulled in since no code are referencing it. pre-reqs are always installed whether pulled in or not but that should be fine in most cases ... and does seem fine here, since that part is apparently working now.
Ok, we did get one good build (without jpa diagram editor) and we can not move up to I20110215-0800 until bug 337743 is fixed. I hope that'll be soon ... but, in the mean time, if you had another test run to make (i.e. after gef prereq range is fixed) feel free. Unless bug 337743 is fixed first ... then I'd like to get a build with I20110215-0800 first :)
Here is the dependency hierarchy for Graphiti 0.7.1 org.eclipse.graphiti org.eclipse.graphiti.mm;bundle-version="0.7.1";visibility:=reexport, org.eclipse.emf.transaction;bundle-version="[1.3.0,2.0.0)" org.eclipse.graphiti.mm org.eclipse.emf.ecore;bundle-version="[2.5.0,3.0.0)";visibility:=reexport org.eclipse.graphiti.pattern org.eclipse.graphiti;bundle-version="0.7.1" org.eclipse.graphiti.ui org.eclipse.emf.edit.ui;bundle-version="[2.5.0,3.0.0)", org.eclipse.emf.workspace;bundle-version="[1.3.0,2.0.0)", org.eclipse.gef;bundle-version="[3.5.0,3.7.0)", org.eclipse.graphiti;bundle-version="0.7.1", org.eclipse.ui.ide;bundle-version="[3.5.0,4.0.0)", org.eclipse.ui.navigator;bundle-version="[3.4.0,4.0.0)", org.eclipse.ui.views.properties.tabbed;bundle-version="[3.5.0,4.0.0)", org.eclipse.core.expressions;bundle-version="[3.4.100,4.0.0)"
(In reply to comment #12) > I see one of the prereqs ... graphiti? has a prereq for gef [3.5,3.7) ... > should be [3.5,3.8) for indigo, right? > > Have you created an environment (workspace and pde target) and try to "export > runnable feature"? That's usually a good test to do locally. David, how do I "export runnable feature", or is it " runnable jar file"?
> > David, how do I "export runnable feature", or is it " runnable jar file"? Sorry, it's "Deployable features" under "Plugin Development" (still, from Export..." Some of this would show up, as well, if you were using a properly set up 3.7 based install ... with proper level of WTP prereqs (either in the install, or in the PDE Target runtime, depending on you you set things up). For example, In the manifest.mf of org.eclipse.graphiti.ui there should be a red-X next to org.eclipse.gef;bundle-version="[3.5.0,3.7.0)" saying "unsatisfied version constraint". Of course, I mention these two "IDE aides" just to help you ... not to scold ... I myself am guilty of sometimes just updating pre-reqs "to see what'll happen" rather than carefully prepare a runtime target with those prereqs. But, runtime targets are extremely useful and would catch "99%" of errors ... the "export deployable feature" is sort of a "hack" to test the build ... since both our PDE based build, and the export deployable feature" function both have "PDE build feature" code at their core. (But, honestly, I've seen the 'export deployable feature' thing go wrong for lots of reasons that make it hard to use in a complex setup, like many of us have for WTP IDE).
Created attachment 189559 [details] screen capture showing current "prereqs" Getting closer ... looks like one variable works, other not. (Maybe still needs changes in publish.xml? I haven't looked). But, mostly wanted to attach this screen shot to clarify ... and show just how nit picky I can be :) ... When I said "at the end" in earlier comment, I still meant "above the line", since those below the line are purely optional and required "for committers only" ... those above the line would be needed, if someone were to install "all of WTP". (previously the new additions appeared between emf and gef, which seemed odd placement ... we should list them in rough order of priority). Thanks,
(In reply to comment #21) Thanks David. I have created a new workspace and installed the latest WTP P2 repository archive file. After that I tried to install Graphiti by "install new software...", and got: Cannot complete the install because one or more required items could not be found. Software being installed: Graphiti SDK (Incubation) 0.7.1.v20110111-0756 (org.eclipse.graphiti.sdk.feature.feature.group 0.7.1.v20110111-0756) Missing requirement: Graphiti Examples Common (Incubation) 0.7.1.v20110111-0756 (org.eclipse.graphiti.examples.common 0.7.1.v20110111-0756) requires 'bundle org.eclipse.gef [3.5.0,3.7.0)' but it could not be found After installing GEF 3.6.1, Graphiti succeeded to install without problem. I have then check-out JPA Editor feature and plugin, and "export deployable feature" without any problem. It seems that org.eclipse.gef [3.5.0,3.7.0) version range in org.eclipse.graphiti.ui is the only blocking issue.
> > It seems that org.eclipse.gef [3.5.0,3.7.0) version range in > org.eclipse.graphiti.ui is the only blocking issue. Excellent. Is there a bug open there, to have them fix the prereq?
(In reply to comment #24) > Excellent. Is there a bug open there, to have them fix the prereq? Yes the bug number is 337920 Concerning the pre-reqs display problem, I made the required changes to the builder, thanks.
I don't get something... AFAIK, Graphiti 0.7.1 is the Helios-compatible release, while the Graphiti 0.8.0 is the Indigo-compatible one. Why do we try to put Graphiti 0.7.1 as a prereq for the Indigo-based WTP build? You can check Graphiti's download page for the update site with Graphiti 0.8.0 binaries. Look at the Milestones section. http://eclipse.org/graphiti/download.php
(In reply to comment #26) > I don't get something... > AFAIK, Graphiti 0.7.1 is the Helios-compatible release, while the Graphiti > 0.8.0 is the Indigo-compatible one. > Why do we try to put Graphiti 0.7.1 as a prereq for the Indigo-based WTP build? > > You can check Graphiti's download page for the update site with Graphiti 0.8.0 > binaries. Look at the Milestones section. It was the version specified by Stefan in comment #2. We can try again with Graphiti 0.8.0
Yes, but comment #2 was about M4, where it's still against Graphiti 0.7 I think.
OK, looks like some miscommunication... At the time of #c2 we were still building the JPA Editor against Helios and hence Graphiti 0.7.1. But now if we know that we should put Graphiti 0.8.0 as prereq in PDE Build, there should be no dependency problem anymore, right? Tran, could you make another attempt? I really appreciate your help in these "dark matters" with the PDE build that we don't understand :-)
David, how and when do you want to proceed with another attempt per Kaloyan's request?
How about right now?
(In reply to comment #31) > How about right now? Ok, I will perform a simple test to pull in Graphiti first. If it succeed, we will try to build the JPA Editor after.
Dependencies for Graphiti 0.8.0 - speak up if you see anything wrong org.eclipse.graphiti - 0.8.0.v20110201-1429 org.eclipse.graphiti.mm;bundle-version="0.8.0";visibility:=reexport, org.eclipse.emf.transaction;bundle-version="[1.4.0,2.0.0)" org.eclipse.graphiti.mm - 0.8.0.v20101213-1502 org.eclipse.emf.ecore;bundle-version="[2.5.0,3.0.0)";visibility:=reexport org.eclipse.graphiti.pattern - 0.8.0.v20110127-0826 org.eclipse.graphiti;bundle-version="0.8.0" org.eclipse.graphiti.ui - 0.8.0.v20110201-1429 org.eclipse.emf.edit.ui;bundle-version="[2.5.0,3.0.0)", org.eclipse.emf.workspace;bundle-version="[1.3.0,2.0.0)", org.eclipse.gef;bundle-version="[3.6.0,4.0.0)", org.eclipse.graphiti;bundle-version="0.8.0", org.eclipse.ui.ide;bundle-version="[3.5.2,4.0.0)", org.eclipse.ui.navigator;bundle-version="[3.4.2,4.0.0)", org.eclipse.ui.views.properties.tabbed;bundle-version="[3.5.0,4.0.0)", org.eclipse.core.expressions;bundle-version="[3.4.101,4.0.0)" David, I have released the test, we can restart the build when you are ready.
> > David, I have released the test, we can restart the build when you are ready. Seemed to do pretty good. Got through the compile, anyway ... that's a good sign. Installing the tests failed, since we've forgotten to update the "tobeInstalled.properties" file in 'wtp.tests' ... it needs to be changed in a way similar to the one used for compiling. (If I don't see you change it soon ... I will .... I have a fix to make for releng tests which will take 15 minutes ... then will fix that property file, if you haven't).
(In reply to comment #34) > > Installing the tests failed, since we've forgotten to update the > "tobeInstalled.properties" file in 'wtp.tests' ... it needs to be changed in a > way similar to the one used for compiling. Done. The build looks pretty good, I have downloaded and verified that it includes the Graphiti jars. I am still in the process of reviewing the editor feature and plugin. I am not close to finish so feel free to restart the build.
I have completed with the code integration, and made the changes with to the builder. Dali is ready for final test run in the build.
(In reply to comment #36) > I have completed with the code integration, and made the changes with to the > builder. Dali is ready for final test run in the build. Just as well now ... if you are confident ... since we still need a weekly integration build. Something went wrong with the previous build ... so badly wrong there is not much to diagnose the problem. But, my theory is some of my recent "clean up" scripts are a little too aggressive. (So, we've got another 24 hours before they run again :)
I am pretty confident with the code I released. Let me know if you need I look to something. I'll be up and keep you company :)
(In reply to comment #38) > I am pretty confident with the code I released. Let me know if you need I look > to something. I'll be up and keep you company :) Oh ... brought down by the 'ol 'isEmpty' mistake :) You will be up late tonight, eh? :)
(In reply to comment #39) > (In reply to comment #38) > > I am pretty confident with the code I released. Let me know if you need I look > > to something. I'll be up and keep you company :) > > Oh ... brought down by the 'ol 'isEmpty' mistake :) > > You will be up late tonight, eh? :) I can fix that. The tests did not run because of that?
> ... The tests did not run because of that? Correct. The tests won't run if there are compile errors. By policy. Waste of time.
Sorry about that, I just released it and restarted the build.
I saw that compilation passed and tests are running. How the JUnit tests look to you?
(In reply to comment #43) > I saw that compilation passed and tests are running. > How the JUnit tests look to you? The packages are just now being finished ... after that will be the critical step of "installing" the tests (where it failed before) ... so we'll know for sure in about 10/15 minutes if the tests will actually start running.
(In reply to comment #44) > ... so we'll know for > sure in about 10/15 minutes if the tests will actually start running. They are off and running ... you can go (back) to sleep now ... I know I am :)
(In reply to comment #45) > (In reply to comment #44) > They are off and running ... you can go (back) to sleep now ... I know I am :) Thanks David!
Cool, I can now take the latest build and successfully use the JPA Diagram Editor. Thanks for the great efforts and I am sorry you had a sleepless night! However, I have two questions/remarks. 1. How can we add the JUnit test suit of the JPA Diagram Editor to be executed together with the PDE Build? I don't see the test suit available in the build results. 2. I see that the Graphiti bundles are packed in the WTP-SDK ZIP package. Is this by intention? Why these bundles are not treated as the other prereqs?
(In reply to comment #47) > Cool, I can now take the latest build and successfully use the JPA Diagram > Editor. > > Thanks for the great efforts and I am sorry you had a sleepless night! > > However, I have two questions/remarks. > 1. How can we add the JUnit test suit of the JPA Diagram Editor to be executed > together with the PDE Build? I don't see the test suit available in the build > results. That work is scheduled for early next week since adding test suites to the build is always a challenge. > 2. I see that the Graphiti bundles are packed in the WTP-SDK ZIP package. Is > this by intention? Why these bundles are not treated as the other prereqs? AFAIK this is how third parties bundles are pulled into a WTP build; EclipseLink bundles are an other example.
> > 2. I see that the Graphiti bundles are packed in the WTP-SDK ZIP package. Is > > this by intention? Why these bundles are not treated as the other prereqs? > > AFAIK this is how third parties bundles are pulled into a WTP build; > EclipseLink bundles are an other example. Third party jars from Orbit always are included as part of our features. But if we want a "whole feature" of another Eclipse project, then we can pre-req it, as we do EMF Transaction and EMF Validation. The EclipseLink jars were an exception (because we don't want to, or give the appearance of pre-req'ing Eclipselink runtime). Hope that helps. I didn't mention it before because I just assumed you had your reasons. (And, there could be some reasons ... mostly depends on if things are "packaged" in a feature the way we need them ... if so, pre-req'ing a feature has one advantage ... that is the best the mechanism to get patches from other projects ... otherwise, we have to create our own patch of what ever feature 'includes' the new bundle.
(In reply to comment #49) We had a brief discussion on the PMC call about the Graphiti dependency, and the result was that the PMC thought that Graphiti should be a pre-req for the reasons mentioned in comment 49. We should make this change for M6. Tran asked that a new bug be opened to track this request. See bug 338567.
I ran into a few issues when trying to integrate the JUnit tests into the build. UI tests cannot be run in the build. So Core tests need to separated from UI tests, I suggest to use separate projects for doing that. The build can run one or multiple Core JUnit test suites from a plugin; Stefan can you provide us the class names of the Core test suites that need to be run in the build.
> > UI tests cannot be run in the build. So Core tests need to separated from UI > tests, I suggest to use separate projects for doing that. > Why is that? Not that I'm doubting it, but we do run some UI tests in our JUnit suites, so I'm wondering what is different in this case?
> Why is that? Not that I'm doubting it, but we do run some UI tests in our JUnit > suites, so I'm wondering what is different in this case? Might just be an incorrect assumption on our part. Seems we would still need to separate them so that the build could run the tests with the right arguments for headless and UI operation?
(In reply to comment #53) > > Why is that? Not that I'm doubting it, but we do run some UI tests in our JUnit > > suites, so I'm wondering what is different in this case? > > Might just be an incorrect assumption on our part. Seems we would still need > to separate them so that the build could run the tests with the right arguments > for headless and UI operation? Most people do separate, but not strictly necessary. You'd basically run the headless tests in a UI environment ... they'd just run, with nothing displayed, but when a UI test ran, it'd run and display. There could certainly be all kinds of complications, with swbot type testers, but we run "regular" tests all the time that _require_ a Display, and that's no problem at all .. and could be intermixed with tests that do not required a Display. Hope that helps, feel free to ask more questions, if I can help.
(In reply to comment #51) Sorry for the delayed answer. I was on a short vacation. > ... Stefan > can you provide us the class names of the Core test suites that need to be run > in the build. We didn't try to separate tests to Core and UI, because actually most of the editor is UI and even if it's not, it's hard to separate it from the UI. I can give you the list of the test classes, which pass even if they run as simple JUnit tests: JPAEditorPreferenceInitializerTest AddJPAEntityFeatureTest DirectEditAttributeFeatureTest JPAEditorToolBehaviorProviderTest JPASolverTest AddRelationFeatureTest AddAttributeFeatureTest ModelIntegrationUtilTest LayoutEntityFeatureTest DeleteRelationFeatureTest
David, I made the required changes to the builder to incorporate the JPA Editor tests. Let me know if we can make a test run in the next build.
(In reply to comment #56) > David, I made the required changes to the builder to incorporate the JPA Editor > tests. > Let me know if we can make a test run in the next build. In the builder? I would have thought, after my latest changes to pull out stream sensitive data from builder to releng, there wouldn't be any changes to builder ... just releng. Or, is that what you meant? And, not sure what you mean by "test run in the next build". I do appreciate your sensitivity to us needing a good build before any new stuff gets introduced, but its not exactly a "test" ... or, did you mean we should create a branch and do a test build with that branch? Even if we don't do a test build with a branch, perhaps you could put your changes in a branch for me to pull in my workspace, and then I'd know better what you mean. Let me know. Glad to help.
(In reply to comment #57) There are changes to the builder in scripts/dependency/dependency.xml and dali.tests/testdependency.xml to get the new prereqs. And in releng to update the category.xml and wtpandtests.tobeinstalledfeaturegroups. I mentioned "test run" because a new tests feature has always the chance to not pull in enough dependencies... specially ours tests :-) Can I use your "david_williams_jpade" branch?
(In reply to comment #58) > (In reply to comment #57) > > There are changes to the builder in scripts/dependency/dependency.xml and > dali.tests/testdependency.xml to get the new prereqs. And in releng to update > the category.xml and wtpandtests.tobeinstalledfeaturegroups. > Ah, that's right. > I mentioned "test run" because a new tests feature has always the chance to not > pull in enough dependencies... specially ours tests :-) > Can I use your "david_williams_jpade" branch? I'd suggest a fresh one, branched from current contents of head. maybe jpade2?
(In reply to comment #59) I have created the branch "david_williams_jpade2", and released my changes, but I have not tagged yet. Thanks David.
(In reply to comment #60) > (In reply to comment #59) > > I have created the branch "david_williams_jpade2", and released my changes, but > I have not tagged yet. Thanks David. I've seen your changes and they look fine to "test". Feel free to merge into HEAD, tag, and update build.cfg. (I did start a test build on one of my test machines ... but, it won't be done till morning ... so, if you wanted to try now, that's fine with me ... as long as you are up late, and can revert or fix :)
(In reply to comment #61) > I've seen your changes and they look fine to "test". Feel free to merge into > HEAD, tag, and update build.cfg. (I did start a test build on one of my test > machines ... but, it won't be done till morning ... so, if you wanted to try > now, that's fine with me ... as long as you are up late, and can revert or fix > :) Done. I will be up to monitor the build, hopefully not too late :)
On mailing list, you said "I have commented out the tests requiring the persistence jar because there is no mechanism currently to load it." Maybe I don't know what you mean ... but in case I do ... other dali tests.xml files use <property name="extraVMargs" value="-Dorg.eclipse.jpt.jpa.jar=${testDir}/${jpt-persistence-jar} .... And in the test dependency file, there is a general "prereq.testlibraries" target that installs a bunch of "extra" libraries we need for testing. at least one persistence jar is one of them.
(In reply to comment #63) > On mailing list, you said "I have commented out the tests requiring the > persistence jar because there is no mechanism currently to load it." Maybe I > don't know what you mean ... but in case I do ... other dali tests.xml files > use Thanks, I wasn't referring to the implementation in the build, but in the code. A mechanism needs to be implemented in the code to load an external persistence jar, which does not exist currently in the JPA Diagram Editor Tests. It looks like the build has finished, and all the tests has passed. I can go to sleep! yay
Created attachment 191026 [details] JPA Diagram Editor Tests bundle stack trace Stefan, I went ahead and made the modifications to JPA Editor tests suite, so it can be run locally and in the build. However it seems that there are some issues with using EasyMock in a multithreaded environment, and causing some tests to fail (see attached stack trace). Therefore it is not ready to be run in the build yet; Fyi, the build is running AllJpaEditorTests. Now you can run the tests locally by specifying the two following VM arguments: -Dorg.eclipse.jpt.jpa.jar="C:\xx\javax.persistence_x.x.jar" -Dorg.eclipse.jpt.eclipselink.jar="C:\xx\eclipselink-x.x.x.jar"
(In reply to comment #65) > ... However it seems that there are some issues with using EasyMock in a > multithreaded environment, and causing some tests to fail (see attached stack > trace)... I know these exceptions. I get them when I run those tests locally from Eclipse as JUnit plugin tests, but they don't seem to be a problem. The tests pass.
(In reply to comment #66) > (In reply to comment #65) > > > ... However it seems that there are some issues with using EasyMock in a > > multithreaded environment, and causing some tests to fail (see attached stack > > trace)... > > I know these exceptions. I get them when I run those tests locally from Eclipse > as JUnit plugin tests, but they don't seem to be a problem. The tests pass. If there are certain tests that are prone to intermittent failure than those tests should be left out of the test suite for the build. Once the tests can be made to reliably pass, they can be included in the build tests. Please comment these tests out for now and move ahead with the rest.
Be sure to (soon) check out the candidate "common indigo repository" at http://download.eclipse.org/releases/staging/ There were lots of changes for the jpt/jpa renames, and addition of several new jpt features. This will make the "web tools" category even longer and maybe more confusing but hopefully the feature names/descriptions will help. (I've not checked myself). The main thing to check for M6 is that all the ones you expect to show up do show up in the right category (and there are no extra). Thanks.
Fixed in M6.
