Bugzilla – Full Text Bug Listing
| Summary: | Update the build of org.eclipse.equinox.console.supportability project in equinox incubator | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Lazar Kirchev <l.kirchev> |
| Component: | Incubator | Assignee: | equinox.incubator-inbox <equinox.incubator-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | kim.moir, pwebster, tjwatson |
| Version: | 3.7 | ||
| Target Milestone: | Juno M7 | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
| Attachments: | |||
Lazar, I noticed that that eclipse build from HEAD is failing recently due to incubator feature issues and I suspect these changes are the cause. Thanks for the patch. Is there CQs to use the new ever version of Apache Felix Gogo and easymock? Tom, I assume that we shouldn't be making these changes for the 3.7 release since we are in the last day of RC4? (In reply to comment #1) > Tom, I assume that we shouldn't be making these changes for the 3.7 release > since we are in the last day of RC4? Correct, this should not disrupt RC4 builds. Problem is we do not plan to have 3.8 I-Builds for some time, right? Not sure how to proceed in a timely manner. Created attachment 197277 [details]
orbit.map patch
I release some changes to head to get the existing org.eclipse.equinox.console.supportability to build successfully. But we still need the orbit.map updated to pick up the new gogo version. Here is what I think the map should be.
(In reply to comment #1) > Lazar, I noticed that that eclipse build from HEAD is failing recently due to > incubator feature issues and I suspect these changes are the cause. Thanks for > the patch. > > Is there CQs to use the new ever version of Apache Felix Gogo and easymock? > > Tom, I assume that we shouldn't be making these changes for the 3.7 release > since we are in the last day of RC4? Hi Kim, Following are the CQs: CQ for using Apache Felix Gogo version 0.8.0 - CQ5083 CQ for using Apache Mina core version 2.0.2 - CQ5092 CQ for using Apache SSHD version 0.5.0 - CQ5091 CQ for using Easymock version 3.0 - CQ5246 CQ for using SLF4J API version 1.6.1 - CQ5176 CQ for using SLF4J log4j-over-slf4j Version: 1.6.1 - CQ5177 The last two are necessary for Apache Mina core and Apache SSHD. Lazar Created attachment 197306 [details]
Update for the proposed patch for equinox-incubator.map file
Update with a changed tag for the supportability and supportability.tests projects.
Well, we don't have any builds scheduled next week toward 3.7RC4. Perhaps we could branch HEAD for R3_7_maintenance at that time and continue with 3.8 development in HEAD. Tom, what do you think? (In reply to comment #6) > Well, we don't have any builds scheduled next week toward 3.7RC4. Perhaps we > could branch HEAD for R3_7_maintenance at that time and continue with 3.8 > development in HEAD. Tom, what do you think? Yes, it looks like I will need to branch equinox projects a bit earlier for 3.7.x and allow HEAD to continue on for 3.8. Would also like to move to git, but that is a separate and much more involved topic. Yes, the git migration is covered in bug 345479. Lazar, what is the complete set of extra bundles needed to get the tests to run. For example, I think you need slf4j from orbit also to get the tests to run. I would really like to use EazyMock 2.4 if possible. I think all you are using from 3.0 is andDelegateTo which I think can be replaced by the more brittle andAnswer method. I am quite concerned about the fan out of dependencies we are adding to the console support now. Is there any way this login support and ssh stuff can be done in a separate bundle? Perhaps it is better suited in Virgo? (In reply to comment #9) Answers are inline: > Lazar, what is the complete set of extra bundles needed to get the tests to > run. For example, I think you need slf4j from orbit also to get the tests to > run. The following bundles are necessary (this is almost the same set of bundles necessary to run the shell with its full functionality): - Gogo runtime and Gogo shell, - the console supportability bundle and the jaas fragment, - mina-core and shhd-core, - slf4j-api and slf4j-api implementation, - org.eclipse.equinox.cm with its dependencies, - easymock and junit I would really like to use EazyMock 2.4 if possible. I think all you are > using from 3.0 is andDelegateTo which I think can be replaced by the more > brittle andAnswer method. I use andDelegateTo only in one place, but the problem is that I just couldn't get andAnswer to work there. I really tried - I myself preferred to use andAnswer - but there were compilation problems regarding the parametrization of ServiceRegistration - it seems that EasyMock API could not recognize correctly the parameter of this class when it should be returned by andAnswer. That is why I had to use andDelegateTo. I already have an approved CQ for Easymock 3.0. If we are to use 2.4 (if we could work around the issue with andAnswer, or just drop this test), then I will open a new CQ for version 2.4. > I am quite concerned about the fan out of dependencies we are adding to the > console support now. Is there any way this login support and ssh stuff can be > done in a separate bundle? Perhaps it is better suited in Virgo? I also do not like very much all these dependencies. That is why I made almost everything optional, except only the most basic imports - in this way, if the user does not need ssh and so on, the user will need only with the Gogo bundles. But I included the ssh support for the general case, not especially for Virgo - everyone to be able to use more secure connection if desired. Certainly, it is possible to move this to Virgo, but the goal was not this. If you think that the equinox console should not provide such support, then we could discuss to move it to Virgo. It is possible to isolate the ssh in another bundle, but this will not change much the situation with the dependencies. If we want to keep the functionality in the shell, there will just be two bundles instead of one, with the same combined set of dependencies. (In reply to comment #10) > (In reply to comment #9) > > Answers are inline: > > > Lazar, what is the complete set of extra bundles needed to get the tests to > > run. For example, I think you need slf4j from orbit also to get the tests to > > run. > The following bundles are necessary (this is almost the same set of bundles > necessary to run the shell with its full functionality): > > - Gogo runtime and Gogo shell, > - the console supportability bundle and the jaas fragment, > - mina-core and shhd-core, > - slf4j-api and slf4j-api implementation, This is where I am running into issues. The slf4j-api and log4j-over-slf4j implementation does not allow the slf4j-api bundle from orbit to resolve. I need to have the following logback bundles to get things to work: ch.qos.logback.core_0.9.27.v20110224-1110 ch.qos.logback.classic_0.9.27.v20110224-1110 ch.qos.logback.slf4j_0.9.27.v20110224-1110 Created attachment 197441 [details]
patch for master equinox feature to fetch new orbit bundles
The test build is failing with /builds/N201106061434/org.eclipse.releng.basebuilder/plugins/org.eclipse.pde.build_3.7.0.v20110512-1320/scripts/genericTargets.xml:111: A cycle was detected when generating the classpath org.eclipse.equinox.http.jetty_2.0.100.N20110606-1434, org.mortbay.jetty.util_6.1.23.v201012071420, org.slf4j.api_1.6.1.v20100831-0715, ch.qos.logback.classic_0.9.27.v20110224-1110, org.slf4j.api_1.6.1.v20100831-0715. It looks like org.mortbay.jetty.util requires org.slf4j.api which requires ch.qos.logback.classic which imports org.slf4j. (In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > > Answers are inline: > > > > > Lazar, what is the complete set of extra bundles needed to get the tests to > > > run. For example, I think you need slf4j from orbit also to get the tests to > > > run. > > The following bundles are necessary (this is almost the same set of bundles > > necessary to run the shell with its full functionality): > > > > - Gogo runtime and Gogo shell, > > - the console supportability bundle and the jaas fragment, > > - mina-core and shhd-core, > > - slf4j-api and slf4j-api implementation, > This is where I am running into issues. The slf4j-api and log4j-over-slf4j > implementation does not allow the slf4j-api bundle from orbit to resolve. I > need to have the following logback bundles to get things to work: > > ch.qos.logback.core_0.9.27.v20110224-1110 > ch.qos.logback.classic_0.9.27.v20110224-1110 > ch.qos.logback.slf4j_0.9.27.v20110224-1110 It's my fault - while developing and testing I used the original slf4j, not the one from Orbit. I thought they should not differ, but it turns out that the one in Orbit is modified - it has an added Eclipse-GenericRequire header in the manifest, with which it requires a class, which is not present in the log4j implementation. I am not sure how to proceed - should we use logback, or open a CQ for an unmodified version of slf4j-api and another slf4j implementation? Created attachment 197498 [details]
patch to add org.eclipse.equinox.slf4j.stub
Kim, I released a bundle org.eclipse.equinox.slf4j.stub which should allow the org.slf4j.api bundle to resolve at build time. I added the org.eclipse.equinox.slf4j.stub bundle to the master-equinox feature with this patch. I have added the org.eclipse.equinox.slf4j.stub bundle to the equinox-incubator.map file in HEAD.
(In reply to comment #15) > Created attachment 197498 [details] > patch to add org.eclipse.equinox.slf4j.stub > > Kim, I released a bundle org.eclipse.equinox.slf4j.stub which should allow the > org.slf4j.api bundle to resolve at build time. I added the > org.eclipse.equinox.slf4j.stub bundle to the master-equinox feature with this > patch. I have added the org.eclipse.equinox.slf4j.stub bundle to the > equinox-incubator.map file in HEAD. I opened CQs to use logback - CQ5270 and CQ5271. Created attachment 197511 [details] failing tests. (In reply to comment #10) > > I would really like to use EazyMock 2.4 if possible. I think all you are > > using from 3.0 is andDelegateTo which I think can be replaced by the more > > brittle andAnswer method. > > I use andDelegateTo only in one place, but the problem is that I just couldn't > get andAnswer to work there. I really tried - I myself preferred to use > andAnswer - but there were compilation problems regarding the parametrization > of ServiceRegistration - it seems that EasyMock API could not recognize > correctly the parameter of this class when it should be returned by andAnswer. > That is why I had to use andDelegateTo. > > I already have an approved CQ for Easymock 3.0. If we are to use 2.4 (if we > could work around the issue with andAnswer, or just drop this test), then I > will open a new CQ for version 2.4. > We already got approval for using Easymock version 2.4 and are already using it in other tests during the build. I released several changes to the org.eclipse.equinox.console.supportability.tests to get it to work with EasyMock 2.4. Part of this change was to make org.eclipse.equinox.console.supportability.tests a fragment to org.eclipse.equinox.console.supportability which seemed necessary to gain package level access to the implementation details of org.eclipse.equinox.console.supportability. Otherwise I could not run the tests. Moving back to incubator until we can get the tests figured out. Lazar I made changes to use EasyMock 2.4, but there are still test failures that I am not convinced are an issue with the use of EasyMock 2.4. Please have a look. We now have the org.eclipse.equinox.console.supportability bundle build successfully in HEAD again. So it should be built in the first 3.8 nightly build scheduled for tonight. (In reply to comment #18) > Moving back to incubator until we can get the tests figured out. Lazar I made > changes to use EasyMock 2.4, but there are still test failures that I am not > convinced are an issue with the use of EasyMock 2.4. Please have a look. We > now have the org.eclipse.equinox.console.supportability bundle build > successfully in HEAD again. So it should be built in the first 3.8 nightly > build scheduled for tonight. I found four failing tests - SshCommandTests, TelnetCommandTests, UserAdminCommandTests and SecureUserStoreTests. On my machine these failed. Are these all failing tests, or there are others? I fixed them - two needed a fix in the test, and the other two - a fix in the implementation. Now all should pass. I tagged both projects - the console and the tests - with v20110608. I also submitted user documentation for the shell in the incubator project documentation, on the page about the console. I see that org.eclipse.equinox.console.jaas.fragment bundle is excluded from the build. Is this on purpose? Because without this bundle JAAS authentication used by ssh will not work. (In reply to comment #20) > I see that org.eclipse.equinox.console.jaas.fragment bundle is excluded from > the build. > > Is this on purpose? Because without this bundle JAAS authentication used by ssh > will not work. yes, we have left the new bundle and the tests out of the build until we could stabilize HEAD and getting it building successfully for the Juno builds. Move all 3.8 bugs to Juno. I'm going to close this bug out for Juno. Lazar could you open a now bug if there are still bundles we need to build. Will likely have to defer the building of any new bundles until kepler. (In reply to comment #23) > I'm going to close this bug out for Juno. Lazar could you open a now bug if > there are still bundles we need to build. Will likely have to defer the > building of any new bundles until kepler. Tom, do you know if org.eclipse.equinox.console.tests and org.eclipse.equinox.console.ssh.tests are built? All other console related projects are built - I see them in the equinox SDK archive. But for the test projects I am not sure how to check. If they are not built, I will open a new bug for Kepler for these two. (In reply to comment #24) > (In reply to comment #23) > > I'm going to close this bug out for Juno. Lazar could you open a now bug if > > there are still bundles we need to build. Will likely have to defer the > > building of any new bundles until kepler. > > Tom, do you know if org.eclipse.equinox.console.tests and > org.eclipse.equinox.console.ssh.tests are built? All other console related > projects are built - I see them in the equinox SDK archive. But for the test > projects I am not sure how to check. If they are not built, I will open a new > bug for Kepler for these two. The tests currently are not running and I am not sure if they are built. Please open a bug so we can get the tests online in Kepler. Thanks. |
Created attachment 197235 [details] Proposed patch for equinox-incubator.map file Hi, There are new features in the console supportability project, so the build should be updated with the new version tag of the source code. Also, the current code uses a newer version of Apache Felix Gogo - version 0.8.0, which is already add in tools/org.eclipse.orbit/org.apache.felix.gogo.runtime. The new features use two other Apache libraries as well - mina-core-2.0.2 and sshd-core-0.5.0. Both are approved for use in the project, and also approved to be added to orbit. Since currently orbit is closed, the two libraries are submitted locally in the console supportability project. The build should use them from there until orbit is open for submissions again and the two libraries are added there. There is also another project related to the console supportability project - org.eclipse.equinox.console.jaas.fragment - which is located also in incubator/console and should be added to the incubator build. There is a new incubator project - org.eclipse.equinox.console.supportability.tests - with tests for the console supportability project. It is located in incubator/console, just as org.eclipse.equinox.console.supportability project. I suppose it also should be added to the incubator build. The tests project uses easymock-3.0. It is approved for use and add to orbit, but similar to the above mentioned libraries, cannot be submitted in orbit right now. Therefore it is temporarily submitted in the tests project and should be used from there. I attach a proposed patch for the changes in equinox-incubator.map file. If there are necessary any other changes in other files, please let me know to make them as well.