I would tend to agree that if you are going to do this by hand,
the old way of unzipping the distros to create a target is going to be hard to
beat. The p2 way is more flexible, but that certainly doesn’t make it
easier. Plus you really don’t want to install stuff via target platform
UI every time you need to refresh what you are working against. It’s just
too much work.
Where p2-based repository zips shine is if you’ve scripted
the whole process. As compared to unzipping, you get a lot more flexibility in
what you install and if there is something wrong p2 will fail at this stage.
This is much better than starting up Eclipse and then sitting there scratching
your head wondering why chunks of functionality are missing.
If people would find this useful and know where we’d stick
it, I would be willing to take some of the p2 scripting goodness that we’ve
developed at OEPE and re-purpose it for creating WTP installs and targets from
pre-built binaries. It would be even slicker if it could download WTP and
dependencies given a build page, but I’ve given up trying to maintain
that screen scraper a long time ago. The pages change too quickly.
- Konstantin
From: wtp-dev-bounces@xxxxxxxxxxx
[mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Brian Vosburgh
Sent: Friday, March 19, 2010 9:22 AM
To: wtp-dev@xxxxxxxxxxx
Subject: Re: [wtp-dev] new downloads page
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