Bugzilla – Full Text Bug Listing
| Summary: | build org.eclipse.test.performance.ui | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | David Williams <david_williams> |
| Component: | Releng | Assignee: | David Williams <david_williams> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 4.5 | ||
| Target Milestone: | 4.5 M4 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 374441 | ||
|
Description
David Williams
Now that I'm looking at this ... there are come confusing parts ... or, else bundles we "lost" back in CVS still? Both org.eclipse.test.performance.ui and org.eclipse.test.performance have optional dependencies on following: org.apache.derby;resolution:=optional, Cloudscape;resolution:=optional, org.eclipse.test.performance.derby;bundle-version="10.4.2";resolution:=optional, I'm pretty sure we can just drop "Cloudscape" as I believe that was "previous" name of 'derby'. The biggest question is what is (or what was in) org.eclipse.test.performance.derby For "org.apache.derby" ... I'm sure that is what used to be in Orbit ... and 1) I don't plan to put current version in Orbit, but just have as "build-time" dependency. I've not done a package by package compare, but from a quick glance, would like to rename this "org.apache.derby.core" simply because that's what the apache project calls it, when the following jars are "combined" (which I suspect is what org.apache.derby used to be?): derby.jar derbyclient.jar derbynet.jar derbytools.jar So, if anyone has any "old memories" of what org.eclipse.test.performance.derby was, that'd be great ... otherwise, I'll do for forensics, eventually. (In reply to David Williams from comment #1) > ... would like to rename this "org.apache.derby.core" > simply because that's what the apache project calls it, when the following > jars are "combined" (which I suspect is what org.apache.derby used to be?): > > derby.jar > derbyclient.jar > derbynet.jar > derbytools.jar I've confirmed from original "CQ" (https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5813) that "org.apache.derby" in orbit had the server-side (derby.jar) and client-side (derbyclient.jar) in it. derbytool.jar may be debatable, but am assuming we need "derbynet.jar" now, since we will (eventually) have multiple tests running on various Hudson servers, and accessing one common database over the network (not on same machine, which I assume is the way they used to be ran on IBM hardware?) (In reply to David Williams from comment #2) > (In reply to David Williams from comment #1) > > ... would like to rename this "org.apache.derby.core" > > simply because that's what the apache project calls it, when the following > > jars are "combined" (which I suspect is what org.apache.derby used to be?): > > > > derby.jar > > derbyclient.jar > > derbynet.jar > > derbytools.jar > > I've confirmed from original "CQ" > (https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5813) that > "org.apache.derby" in orbit had the server-side (derby.jar) and client-side > (derbyclient.jar) in it. > > derbytool.jar may be debatable, but am assuming we need "derbynet.jar" now, > since we will (eventually) have multiple tests running on various Hudson > servers, and accessing one common database over the network (not on same > machine, which I assume is the way they used to be ran on IBM hardware?) Doh, clearly documented at http://wiki.eclipse.org/Performance/Automated_Tests#Getting_and_installing_Derby that "org.apache.derby" does consist of the 4 jars! So, I'd still like to name it "org.apache.derby.core" as Apache does, themselves, in their documentation. Plus, I will be creating a new "OSGi" style bundle, instead of having the libraries in the plugin.xml, as documented in http://wiki.eclipse.org/Performance/Automated_Tests#Getting_and_installing_Derby (In reply to David Williams from comment #3) > > Doh, clearly documented at > http://wiki.eclipse.org/Performance/ > Automated_Tests#Getting_and_installing_Derby > that "org.apache.derby" does consist of the 4 jars! Double Doh! the document actually lists these as the jars to include: <runtime> <library name="db2jcc.jar"> <export name="*"/> </library> <library name="db2jcc_license_c.jar"> <export name="*"/> </library> <library name="derby.jar"> <export name="*"/> </library> <library name="derbynet.jar"> <export name="*"/> </library> <library name="derbytools.jar"> <export name="*"/> </library> </runtime> The db2jcc* jars do not seem to be part of "Derby", but did see them mention in their test documentation that they are "IBM Universal JDBC Driver classes." and the URL they give, to developerworks, no longer exists, but did find mention of them, on the web, at http://www-01.ibm.com/support/docview.wss?uid=swg21363866 I'm hoping we can do without them? (In reply to David Williams from comment #4) > > I'm hoping we can do without them? I would like to do without them and not sure what we were using them for, but have noticed that the current performance.ui code has only two cases where it refers to something from "org.apache.derby" ... org.apache.derby.jdbc.EmbeddedDriver (is in derby.jar) org.apache.derby.jdbc.ClientDriver (is in derbyClient.jar) Not this second jar was not in original list "derby core" jars, but I have added it, following the Derby "instructions" on Apache site. [So, I'm guessing, "ClientDriver" used to be part of db2jcc.jar.) (In reply to David Williams from comment #5) > (In reply to David Williams from comment #4) > > > > > I'm hoping we can do without them? > > I would like to do without them and not sure what we were using them for, > but have noticed that the current performance.ui code has only two cases > where it refers to something from "org.apache.derby" ... > > org.apache.derby.jdbc.EmbeddedDriver (is in derby.jar) > org.apache.derby.jdbc.ClientDriver (is in derbyClient.jar) > > Not this second jar was not in original list "derby core" jars, but I have > added it, following the Derby "instructions" on Apache site. > > [So, I'm guessing, "ClientDriver" used to be part of db2jcc.jar.) Well, nevermind, sort of, I also see "com.ibm.db2.jcc.DB2Driver" in part of the code that looked like one of several alternatives ... it appears this driver, in particular, was jused for "net://" access ... so may have to find the Derby equivalent ... if/when we implement that. This is now building, along with the rest of our "build tools" (custom ant tasks, etc.). The build is done at https://hudson.eclipse.org/hudson/view/Eclipse%20and%20Equinox/job/Eclipse%20Build%20Tools/ The output is only a p2 repository, which I "hand copy" to the composite p2 repo at http://build.eclipse.org/eclipse/buildtools/ It can be installed along with the rest of the build tools, using org.eclipse.releng.build.tools.feature.feature.group Or, (with p2Director) the individual bundle IU org.eclipse.test.performance.ui It does "depend on" having the Platform installed. It also, optionally, depends on org.apache.derby.core, which we do not install automatically, since it is a "workswith" (not for distribution) bundle, but in reality, it is available in the same repo. I've opened bug 450422 to update the documentation on org.apache.derby.core. Just to document it, discovered small glitch, in trying to use "performance.ui" from "build tools". It depends on "o.e.test.performance". And rather than install "test framework" along with "build tools" decided for now just to include "most recently" built version of o.e.test.performance with build tools. I opened bug 450592 to perhaps improve upon this in future. |