I reproduced the issue you mention here ... and after clicking a bunch of things "it worked"! But I may have been just engaging in superstitious behavior (driven by trial and error), so we'll see if you get similar results. And then you can open a bug :)
When adding a site, there's a checkbox that says "include required software", checked by default. I _unchecked_ it, and then (after pressing ok) it actually started reading the repository! And took _foorrreeevvveer_ to finish. Almost as if it was downloading everything, except I explicitly disabled all other software locations, except for the three local zipped repos (which, btw, I had unzipped). I don't know ... think there could be a bug in P2? :) I'm pretty sure "include required software" works as expected when installing ... but, maybe something in targeting makes it backwards? Or, with further playing, sometimes the state of the button seemed to matter, sometimes just changing its state seemed to be the trigger. So, I think bottom line is P2 is not "refreshing" the target's data when it should, or as completely as it should, and some actions must force it to ... and then it can find everything. (But still takes ridiculously, unusable long time ... takes way longer than an install?!). I hope you can find some good steps to report for a bug. I was thinking the zipped repos would be more for builds or installs, not targets. My hope is that URL based repositories will work well as "targets", since then ... once our releng team implements it ... committers could, say, have a target repo for "webtools/integration" and update their target every week to all the latest, without any other steps (once set up). Instead, I might have to tone down that comment about the zips disappearing. :) From: Brian Vosburgh <[email protected]> To: [email protected] Date: 03/19/2010 12:47 PM Subject: Re: [wtp-dev] new downloads page Sent by: [email protected] Thanks for the thorough response, David. Comment inline: > I'm not sure what that means. :-) I guess I'm supposed to unzip > them and see what happens? Where 'ya been? :) Avoiding P2? Keeping things simple? :) Off hand, I'm not sure where this is documented well, but there's a lot of mailing list and bugzillas about them. They are exactly like a repository you'd get via HTTP, but zipped up. The original goals were 1) provide a P2 repo that builds or adopters could use that they could "hang on to" instead of trusting HTTP get's to return exactly the same thing each time (some projects are more reliable than others ;) and 2) give users a repo since it has all the artifact and metadata computed already, so in theory should be better and faster to install that. (Traditional unzipping has to compute the metadata "on the fly" and will not give as good of diagnostics, if something is not right). Sorry, man. I didn't mean for you to respond so fully to my flip question. :) > I unzip all the prereq zip files into an eclipse folder. I unzip the 3 > zipped P2 repositories into separate folders. (Do I need to unzip > them? Not sure.) You don't have to, you can even drag and drop them on top of "install new software" wizard. But, honestly, I find it seems faster, if I unzip them in separate folder first. Also, In some cases, you will want to "reuse" some, while swapping in new versions for something else, so in those cases, overall, there is less unzipping going on (happens just once per repo). I'll say up front, I haven't tried your exact scenario, but have done similar things, with out these issues you found. So, let's check the basics ... When adding it to software locations, you do tell the wizard it is a "software site", right? Not a "directory"? You can, by the way, unzip a normal zip file, and add it to software sites list ... but in that case you of course say it is a directory, and b. all the metadata has to be computed on the fly (but, still get better diagnostics this way). Yes, I do add a "Software Site" in the wizard. And now I see how I can add an "Archive" repository; so I don't need to unzip the downloaded repositories. One less step. :) [The layout of the Add Repository dialog maybe isn't the most intuitive. The "Local..." button is next to the "Name:" text field; the "Archive..." button is next to the "Location:" text field - seems like both buttons are related to the "Location:" text field. Oh well, just playing Stupid User here.... :) ] Second, you do have all the other pre-reqs installed already, that WTP needs, right? I don't think you need them all in your target (some can still come from your workbench, I think ... but, I'd have to check. I normally have "everything" in the target. That's how I test if there are compile or versioning errors, before moving up pre-reqs in the build. Well, over the last few years, I haven't had any problems having all the WTP pre-reqs in my target workspace :) but here is what I downloaded and unzipped into my target workspace directory: dtp-sdk-1.8.0M6-201003120500.zip eclipse-SDK-3.6M6-win32.zip emf-runtime-2.6.0M6.zip emf-sourcedoc-2.6.0M6.zip GEF-SDK-3.6.0M6.zip xsd-runtime-2.6.0M6.zip The Target Definition finds and loads this target workspace just fine; indicating it has 702 plug-ins available. > Then I add 3 > Software Sites, one for each of the new P2 directories from the > P2 zip files. When using the wizard to add a Software Site, ... sounds right so far. > I'm not > sure which content to add. The WST repository has two options - > I guess I only need the "SDK" option(?). I'm not sure what I'm > supposed to do with the "Project Provided Components" option in > the JST repository. Oh, just pick 'em all. :) In effect, that would be a little redundant, but picking them ends up being the same thing as unzipping the whole WTP SDK traditional zip. Redundant in a couple of ways ... SDK's contain minimal code also, so no real need to pick minimal versions if you want SDK (but, you might pick minimal if you really wanted minimal. But ... here could be bugs. I normally pick everything, OK, I picked 'em all. What the hell. :) The "Project Provided Components" was at one point going to be a place to pick "stand alone" components, like faceted project features. The separate "server adapters" currently there looks like its fading from Helios. (That is, won't be separate). So, that whole category may just go away this release. Oh, another basic ... you are using a recent base build, like M6 or something, right? *Now* I am. :) [I was hoping this was my problem. No such luck.] > Once I add all this content, I have a number of problems listed in the > Edit Target Definition dialog: > Under the WST repository: > Cannot satisfy dependency: > Cannot satisfy dependency: > Missing requirement: Eclipse JavaScript Development Tools... This is the smoking gun that something is really messed up. JSDT depends on almost nothing, so indicates your files are corrupt, or you are trying to use an M6 target with a Galileo Dev. Env., or something. Now that I am using an M6 host workspace I get slightly different errors. See the attached screen shot. Its good to know people are trying these new workflows. In theory, should be easier/faster than traditional zips, once we get used to them, ... but ... you know how that goes. I'm not seeing how this is going to be "easier/faster" than traditional zips; but I'll keep trying. :) I hope others can report success or similar problems and maybe get the issues narrowed down. As far as I know, there could be order effects, or something. Thanks, David! Brian [attachment "p2.JPG" deleted by David M Williams/Raleigh/IBM] _______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
