Community
Participate
Working Groups
Created attachment 215892 [details] p2.test.diff The file rt.equinox.p2/bundles/org.eclipse.equinox.p2.tests/download.eclipse.platform.for.p2.migration.tests.xml seems to point to a URL that no longer exist causing the download to fail. http://mirror.csclub.uwaterloo.ca/eclipse/eclipse/downloads/drops/R-3.7.1-201109091335/eclipse-platform-3.7.1-linux-gtk.tar.gz Attached diff shows the modifications I made to get around this issue.
Created attachment 215893 [details] p2.test.diff Update to use same mirror as original.
The problem is that the 3.7.1 release was moved to the archive in preparation for the Juno release. Updating to 3.7.2 seems reasonable.. it's odd that we're explicitly depending on the Waterloo computer science club mirror though :)
Created attachment 221921 [details] Patch to use mirror URL I decided to improve the patch so that it no longer depends on University of Waterloo mirror.
(In reply to comment #3) > Created attachment 221921 [details] > Patch to use mirror URL > > I decided to improve the patch so that it no longer depends on University of > Waterloo mirror. Very cool. Not only that, but by the time it moves to "archives" it should still find it there! (Even though, by then, we will likely want to move up to a more recent version of "previous release" ... but just wanted to compliment your attention to "doing it right"). Thank you!
(In reply to comment #4) > (In reply to comment #3) > > Created attachment 221921 [details] > > Patch to use mirror URL > > > > I decided to improve the patch so that it no longer depends on University of > > Waterloo mirror. > > Very cool. Not only that, but by the time it moves to "archives" it should > still find it there! (Even though, by then, we will likely want to move up > to a more recent version of "previous release" ... but just wanted to > compliment your attention to "doing it right"). > > Thank you! I think ability to find archived download is a requirement for LTS, no?
Ian, could i get you to include this patch in your 4.2.2/3.8.2 stream? PW
I think that tests should not download anything - because the eclipse may be built in an environment with network restrictions (pretty common in corporations). From the security point of view, an unverified, unsigned executable is being downloaded... I'd rather push that bug towards tests refactoring.
If the tests are testing network behaviour too - one can easily use some mocking framework to simulate the needed traffic.
These tests are not about testing network connectivity but release to release updates, therefore they need to obtain an existing Eclipse from somewhere.
The current URL breaks the build. To avoid local build failure can we apply the patch with the change of the URL? Looks trivial and should allow for a clean build. Afterwards the improvements of the tests can be continued to discuss IMHO.
I've applied this patch and pushed it to eclipse.org for the R38 maintenance branch. Can someone who has a local CBI running try this and see if it works? http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?h=R3_8_maintenance&id=1cbf73a51be304079404b277c10fe50832bab4d7
Thanks Ian, Platform CBI build works now fine for me. I'm leaving this bug open in case the test should still be adjusted to cover the non-network connect case.
(In reply to comment #12) > Thanks Ian, Platform CBI build works now fine for me. I'm leaving this bug > open in case the test should still be adjusted to cover the non-network > connect case. I don't think we should handle that case. To fully test all aspects of p2 some network access will be required -- this is why we have 'integration' tests. However, I don't think that users should necessarily need to run the full suite of integration tests locally. IMHO we should focus our efforts on allowing users to run the unit tests locally, and only the fully end-to-end integration tests if they really want to. That is, if the setup is not in place for a full end-to-end integration tests, the user can disable these tests and still get a working Eclipse install. I'm marking this bug closed since the originally problem has been addressed.
