Community
Participate
Working Groups
Created attachment 187922 [details] Changes to wtpbuilder Modify the Web Tools build to incorporate the new DBWS dependencies.
David, I have attached some preliminary changes to wtpbuilder. I am not sure how the new property .tobeinstalledfeaturegroups works. I presume that EclipseLink will need to define one but I don't know how to set it. Can you point me to where I can get some info. Thanks.
tobeinstalledfeaturegroups is not really documented, except in the code itself, but is pretty straightforward ... if a repo is provided as a prereq, then the exact features to be installed from that repo must also be specified. But, let's backup here. Last I heard about, we were not going to add a pre-req dependency on eclispelink features ... but, instead, an eclipselink jar would be re-packaged with one of your wtp.eclispelink features ... similar to how we package and ship orbit 3rd party bundles. If that is the case, I can show you ways that are (probably) easier, involving maps files with p2 format entries. If I've misunderstood, or if this is something else, then I'd like to learn more about what the big picture is first. Like ... what's DBWS? :) Thanks,
That is correct David, we want to include EclipseLink jars. However we don't have access to EclipseLink map files. Please can you elaborate more. Thanks.
(In reply to comment #3) > That is correct David, we want to include EclipseLink jars. However we don't > have access to EclipseLink map files. Please can you elaborate more. > Thanks. Yep, while we get map files from Orbit, they just happen to be nice enough to provide them for us :) For others, you can "make your own" entries, either in a separate map file, if that's easier for you, or one of your existing map files. I'd have to research it to know all possibilities for exact format, but seems a good starting point is just to mimic an entry from Orbit map files, say plugin@com.ibm.icu,4.4.2=p2IU,id=com.ibm.icu,version=4.4.2.v20110115,repository=http://download.eclipse.org/tools/orbit/downloads/drops/S20110124210048/repository Could be abstracted to following (assuming you want their 2.2.0 RC3 repo ... I don't know all possibilities there ... you may have to ask EclipseLink team? ... I just saw this one browsing around). plugin@<bundlename>,<bundle3partVersion>=p2IU,id=<bundlename>,version=<bundle4partversion>,repository=http://download.eclipse.org/rt/eclipselink/milestone-updates/2.2.0.v20110114-r8831_RC3/ Perhaps, plugin@org.eclipse.persistence.dbws,2.2.0=p2IU,id=org.eclipse.persistence.dbws,version=2.2.0.v20110114-r8831,repository=http://download.eclipse.org/rt/eclipselink/milestone-updates/2.2.0.v20110114-r8831_RC3/ Then in your feature you want this packaged with, you'd have something similar to <plugin id="org.eclipse.persistence.dbws" version="2.2.0.qualifier" unpack="false"/> And that's it. No change to builder or anything is required (since we already specify "transformedRepo" property, etc.). Naturally, you'll have to adjust repo, version, and qualifier as you need and as they provide new versions; but hopefully that's not often. HTH
It appears the basic mechanism works with your changes to maps/features ... but, perhaps not pulling in enough? The build of dali fails with a message similar to that pasted below. If org.eclipse.persistence.dbws does not really need those other two bundles, then it should list them as optional? Otherwise, you'll need to pull them in too. Right? = = = = = 741824 [build-wtp-dali-sdk] /opt/public/webtools/basebuilders/R37_M4/org.eclipse.releng.basebuilder/plugins/org.eclipse.pde.build_3.6.100.v20101122/scripts/genericTargets.xml:107: Processing inclusion from feature org.eclipse.jpt.eclipselink.feature: Bundle org.eclipse.persistence.dbws_2.3.0.v20110122-r8865 failed to resolve.: 741825 [build-wtp-dali-sdk] Missing required plug-in org.eclipse.persistence.core_2.3.0.v20110122-r8865. 741826 [build-wtp-dali-sdk] Missing required plug-in org.eclipse.persistence.asm_2.3.0.v20110122-r8865.
moving this over to dali component project, since I think all changes are in Dali ... but, let me know if I can help further.
Thanks David, I am looking into it now, and probably releasing and restarting the build in half hour.
Guess you'll see it yourself, but if not yet, the latest build failed with an error that I've pasted below. Apparently could not find an Eclipselink "nightly build"? Not sure if there's a typo? Or it disappeared already? (I don't know what Eclipselink nightlies are ... but, care is needed when using nightlies, in most cases). Thanks, = = = = = 740983 [build-wtp-dali-sdk] 740984 [build-wtp-dali-sdk] FetchIUsFromRepo: 740985 [build-wtp-dali-sdk] [echo] Fetching IUs from http://download.eclipse.org/rt/eclipselink/nightly-updates/2.3.0.v20110122-r8865/ to /shared/webtools/projects/wtp-R3.3.0-I/workdir/transformedRepo. 740986 [build-wtp-dali-sdk] 740987 [build-wtp-dali-sdk] BUILD FAILED 740988 [build-wtp-dali-sdk] /shared/webtools/projectBuilders/wtp-R3.3.0-I/webtools.releng/releng.wtpbuilder/scripts/build/runbuild.xml:150: The following error occurred while executing this line: 740989 [build-wtp-dali-sdk] /opt/public/webtools/basebuilders/R37_M4/org.eclipse.releng.basebuilder/plugins/org.eclipse.pde.build_3.6.100.v20101122/scripts/build.xml:34: The following error occurred while executing this line: 740990 [build-wtp-dali-sdk] /opt/public/webtools/basebuilders/R37_M4/org.eclipse.releng.basebuilder/plugins/org.eclipse.pde.build_3.6.100.v20101122/scripts/build.xml:78: The following error occurred while executing this line: 740991 [build-wtp-dali-sdk] /shared/webtools/projectBuilders/wtp-R3.3.0-I/webtools.releng/releng.wtpbuilder/components/dali-sdk/customTargets.xml:103: The following error occurred while executing this line: 740992 [build-wtp-dali-sdk] /shared/webtools/projectBuilders/wtp-R3.3.0-I/webtools.releng/releng.wtpbuilder/components/dali-sdk/allElements.xml:37: The following error occurred while executing this line: 740993 [build-wtp-dali-sdk] /opt/public/webtools/basebuilders/R37_M4/org.eclipse.releng.basebuilder/plugins/org.eclipse.pde.build_3.6.100.v20101122/scripts/genericTargets.xml:59: The following error occurred while executing this line: 740994 [build-wtp-dali-sdk] /shared/webtools/projects/wtp-R3.3.0-I/workdir/fetch_org.eclipse.jpt_sdk.assembly.feature.xml:11: The following error occurred while executing this line: 740995 [build-wtp-dali-sdk] /shared/webtools/projects/wtp-R3.3.0-I/workdir/fetch_org.eclipse.jpt_sdk.assembly.feature.xml:30: The following error occurred while executing this line: 740996 [build-wtp-dali-sdk] /shared/webtools/projects/wtp-R3.3.0-I/workdir/fetch_org.eclipse.jpt.eclipselink_sdk.feature.xml:11: The following error occurred while executing this line: 740997 [build-wtp-dali-sdk] /shared/webtools/projects/wtp-R3.3.0-I/workdir/fetch_org.eclipse.jpt.eclipselink_sdk.feature.xml:29: The following error occurred while executing this line: 740998 [build-wtp-dali-sdk] /shared/webtools/projects/wtp-R3.3.0-I/workdir/fetch_org.eclipse.jpt.eclipselink.feature.xml:10: The following error occurred while executing this line: 740999 [build-wtp-dali-sdk] /shared/webtools/projects/wtp-R3.3.0-I/workdir/fetch_org.eclipse.jpt.eclipselink.feature.xml:63: The following error occurred while executing this line: 741000 [build-wtp-dali-sdk] /shared/webtools/projects/wtp-R3.3.0-I/workdir/fetch_org.eclipse.jpt.eclipselink.feature.xml:85: Error occurred while transforming repository: No repository found at http://download.eclipse.org/rt/eclipselink/nightly-updates/2.3.0.v20110122-r8865/.. 741001 [build-wtp-dali-sdk] 741002 [build-wtp-dali-sdk] Total time: 1 minute 36 seconds 741003 [build-wtp-dali-sdk] An error has occurred. See the log file 741004 [build-wtp-dali-sdk] /opt/public/webtools/projects/wtp-R3.3.0-I/workdir/I-3.3.0-20110201055903/buildworkspaces/workspace-runbuild-dali-sdk/.metadata/.log. 741005 [build-wtp-dali-sdk] Java Result: 13
This is strange because the same repository works a few hour before. I have switch to more recent nightly build, and verified that it is available.
(In reply to comment #9) > This is strange because the same repository works a few hour before. > I have switch to more recent nightly build, and verified that it is available. I thought I saw this go by yesterday...EclipseLink just released an M build for 2.3.0, so we can probably start using that instead of the nightly's, which were the only option previously for v2.3.0. Take a look at the EL download page and click the milestone builds link and you will see it there.
signing seems slow today ... lots of builds going on for two deadlines this week ... but, on my local build (which is not signed), the currently released content built ok. Just thought I'd let you know ... of course, I have no idea if it runs correctly ... but, it did get though the build and on to locally running the unit tests. Keep your fingers crossed. :)
Thanks David this is very good news; we can start to check in Dbws phase 2 now.
I have downloaded the build and verified that the EclipseLink bundles are pulled into it. I have released Dbws phase 2.
I'm sure you'd see this yourselves ... but since I looked, and have it handy, thought I'd paste the log messages I see related to latest failure; classpath cycle? I'm assuming that's not needed/intentional? 741861 [build-wtp-dali-sdk] generateScript: 741862 [build-wtp-dali-sdk] 741863 [build-wtp-dali-sdk] BUILD FAILED 741864 [build-wtp-dali-sdk] /shared/webtools/projectBuilders/wtp-R3.3.0-I/webtools.releng/releng.wtpbuilder/scripts/build/runbuild.xml:150: The following error occurred while executing this line: 741865 [build-wtp-dali-sdk] /opt/public/webtools/basebuilders/R37_M4/org.eclipse.releng.basebuilder/plugins/org.eclipse.pde.build_3.6.100.v20101122/scripts/build.xml:35: The following error occurred while executing this line: 741866 [build-wtp-dali-sdk] /opt/public/webtools/basebuilders/R37_M4/org.eclipse.releng.basebuilder/plugins/org.eclipse.pde.build_3.6.100.v20101122/scripts/build.xml:91: The following error occurred while executing this line: 741867 [build-wtp-dali-sdk] /shared/webtools/projectBuilders/wtp-R3.3.0-I/webtools.releng/releng.wtpbuilder/components/dali-sdk/customTargets.xml:103: The following error occurred while executing this line: 741868 [build-wtp-dali-sdk] /shared/webtools/projectBuilders/wtp-R3.3.0-I/webtools.releng/releng.wtpbuilder/components/dali-sdk/allElements.xml:37: The following error occurred while executing this line: 741869 [build-wtp-dali-sdk] /opt/public/webtools/basebuilders/R37_M4/org.eclipse.releng.basebuilder/plugins/org.eclipse.pde.build_3.6.100.v20101122/scripts/genericTargets.xml:107: A cycle was detected when generating the classpath org.eclipse.jpt.dbws.eclipselink.core.gen_1.0.0.v201102010002, org.eclipse.persistence.dbws_2.3.0.v20110129-r8902, org.eclipse.persistence.core_2.3.0.v20110129-r8902, org.eclipse.persistence.dbws.builder_2.3.0.v20110129-r8902, org.eclipse.persistence.core_2.3.0.v20110129-r8902. 741870 [build-wtp-dali-sdk] 741871 [build-wtp-dali-sdk] Total time: 2 minutes 48 seconds 741872 [build-wtp-dali-sdk] An error has occurred. See the log file 741873 [build-wtp-dali-sdk] /opt/public/webtools/projects/wtp-R3.3.0-I/workdir/I-3.3.0-20110202122806/buildworkspaces/workspace-runbuild-dali-sdk/.metadata/.log. 741874 [build-wtp-dali-sdk] Java Result: 13
David, I am currently looking into it. In the development environment, the PDE Cycle dependency analysis do not reveal any problem. I am investigating further.
(In reply to comment #14) > A cycle was detected when generating the classpath > org.eclipse.jpt.dbws.eclipselink.core.gen_1.0.0.v201102010002, > org.eclipse.persistence.dbws_2.3.0.v20110129-r8902, > org.eclipse.persistence.core_2.3.0.v20110129-r8902, > org.eclipse.persistence.dbws.builder_2.3.0.v20110129-r8902, > org.eclipse.persistence.core_2.3.0.v20110129-r8902. The persistence.dbws.builder is re-exporting its dependencies, so I am not sure if that caused the problem in the build, but I changed Dali dependencies to require persistence.dbws.builder instead of persistence.dbws.
I have pull out the DBWS support until we can resolve this issue with referencing EclipseLink bundles.
Bug 336179 has been created for this issue.
It is best if bundles have no cycles, but ... there _might_ be a hack we can put in the builder, somewhere. There is a allowBinaryCycles property that is poorly documented and only partially implemented. Such as see bug 208011 and bug 308070. I've not read much about it, but if you wanted to experiment, allowBinaryCycles=true could be added to your bundles build.properties (I think). We might have to add it to build.properties in dali-sdk component of builder, so it applies to "whole dali build" (not just that one bundle). If you can read and make sense of the referenced bugs about allowBinaryCycles, let me know if you want to try anything that I can help with.
(In reply to comment #19) > It is best if bundles have no cycles, but ... there _might_ be a hack we can > put in the builder, somewhere. There is a allowBinaryCycles property that is > poorly documented and only partially implemented. > Such as see bug 208011 and bug 308070. > > I've not read much about it, but if you wanted to experiment, > allowBinaryCycles=true > could be added to your bundles build.properties (I think). > We might have to add it to build.properties in dali-sdk component of builder, > so it applies to "whole dali build" (not just that one bundle). > > If you can read and make sense of the referenced bugs about allowBinaryCycles, > let me know if you want to try anything that I can help with. I think we will want to give this a try, since I think the fix may not be immediately available from the EclipseLink team. I would like this to be a temporary fix so the next time there is a cycle in our dependencies we will discover it. There doesn't appear to be any harm in this approach other than that though, since runtime operation should not be affected. It looks like the change should be made at the dali-sdk component level so that it applies to the whole build, but perhaps we should try it at the bundle level since that would be more isolated.
David, I made the modification to build.properties in dali-sdk, and put back the DBWS feature into our code. Let me if you want me to tag and update build.cfg, or anything else before we restart the build. Thanks.
(In reply to comment #21) > David, I made the modification to build.properties in dali-sdk, and put back > the DBWS feature into our code. Let me if you want me to tag and update > build.cfg, or anything else before we restart the build. Thanks. I'm game. Go ahead, tag and update build.cfg. As long as only for Indigo, I think this is a good time. (I need to make another fix later this afternoon, primarily for Helios, but can do that after you start your test build).
(In reply to comment #22) > I'm game. Go ahead, tag and update build.cfg. As long as only for Indigo, I > think this is a good time. (I need to make another fix later this afternoon, > primarily for Helios, but can do that after you start your test build). Unfortunately Tran just stepped out for a couple of hours. Can you make this change for us so we can get the build started sooner? Or remind me how to do this (since it has been a couple of years). I guess you just tag build.cfg and then update the version number in the same file?
(In reply to comment #23) > (In reply to comment #22) > > > I'm game. Go ahead, tag and update build.cfg. As long as only for Indigo, I > > think this is a good time. (I need to make another fix later this afternoon, > > primarily for Helios, but can do that after you start your test build). > > Unfortunately Tran just stepped out for a couple of hours. Can you make this > change for us so we can get the build started sooner? Or remind me how to do > this (since it has been a couple of years). I guess you just tag build.cfg and > then update the version number in the same file? I have tagged releng.wtpbuilder, updated build.cfg, and committed build.cfg to head (that's the procedure :) and restarted the I-build. Remember this might not fix the problem, (unless you know otherwise ... that flag seemed poorly documented and only partially implemented) ... so please keep an I open to back out dbws changes if breaks this afternoon. I'd hate to be "down" all weekend. Thanks much,
(In reply to comment #24) > so please > keep an I open to back out dbws changes if breaks this afternoon. I'd hate to > be "down" all weekend. > > Thanks much, Thank you...and yes, we will be watching closely.
Setting the property allowBinaryCycles to true permitted the build to pass, but the DBWS features and plugins are not packaged into the build. Also the EclipseLink bundles are not pulled in into the build. However it compiles the DBWS code, as it shows in the build compile logs. I am not sure what it going on, but the circular problem might still be the cause of this.
Created attachment 188389 [details] org.eclipse.jpt.dbws.eclipselink.feature
You are closer than you realize. :) It is being compiled and put into a "hidden" dali repo that's created during the main build ... but ... our final "repo" and zip files are created in a post-build step (this is done, partially to allow mirror checks, and partially to end up with one big repo, instead of several smaller ones, and partially because of changes in pde build that changed behavior and rules about assembly features). I didn't realize you were adding a feature to your "assembly feature" (or, would have told you about this earlier). I thought you would have 'included' this in your "org.eclipse.jpt.eclipselink_sdk.feature" ... and if you do, that'd make following info irrelevant, but I've no idea what is the right thing to do, so fine if you don't ... we'll just have more to work out. (We'd have to do similar things for the JPA Editor, so ... good to learn about/document these things now ... not sure if/where I've documented any of it before, so as you go through it, feel free to add to wtp's "build wiki" if you don't see anything there]. When features are added to assembly feature, there are two other updates that must be made: [Note: most of this info is "from memory" so may be a few details wrong or left out]. 1. To get your new feature pulled into "main" repo (during the post-build step) you need to update your category.xml file, so that new feature is in your "standard" category just like other entries in that category.xml file. That category.xml file is (currently) in dali-sdk component, in wtpbuilder. But (complication) now that the two streams (Indigo and Helios) differ, we should move that category.xml file to "releng" project/folder since that's where "stream sensitive" things go, so wtpBuilder can be same in all streams. Feel free to "get it working" first, then we can worry about making wtpBuilder "stream insensitive". 2. To get your new feature installed during JUnit tests, you need to wtpFeatureIUs property in build.cfg file. (already stream sensitive).
Thanks David, I knew that you would have an explanation :) I have made the changes and I'll try to review the build wiki.
Implemented in M6.
