Replies inlined below:
Robert Goodman wrote:
> 1) Why are the URLs for feature JARs and plugins so radically
> Shouldn't the features / plugins dirs be in sync with each other?
The URLs are based on history which really doesn't matter at this
point. This could potentially change.
I guess my main question here was why
aren't they in a standard update
site format so users can point Eclipse their independently of ATF (or
any other tools that depend on XULRunner for that matter)
> 2) Why is XULRunner packaged as 3 seperate features? This becomes hell
> for dependency management purposes. It was easier for me to just write
> one simple feature and put platform/OS conditions on each XULRunner
> plugin. You can find my feature.xml here:
ATF installs XULRunner two ways, automatically downloaded using
updated manager and in ATF's platform specific "All-in-one" zip files.
1. Update manager
The basic requirement when installing ATF by update manager was to
only download the version of XULRunner for the platform. As I remember
I couldn't figure out a way to have one feature and not get all
versions of XULRunner downloaded. XULRunner for all three platforms
supported today is 33 MB in size. We already have request for a 64 bit
linux build which would increase the by another 8-10 meg. I'm not a
feature/update manager expert, so there may be a way around this
problem when using only one feature.
This is what I was trying to reference in my
link above. A single
feature fixes this problem rather elegantly, all you need to do is put
platform/operating system constraints on each plugin, and only the
plugins for the relevant platform will be downloaded when it comes time
to install via update site.
One of the comments that ATF received was that the download size
(eclipse, wtp, and dependences) was too big. Working with the WTP and
other eclipse team changes were made that allows us to create an
"All-In-One" package for each platform with only the functionality
needed by Web Developers (no JDT, PDE, etc.). Packaging all platform
versions of XULRunner in each "All in One" would significantly
increase the size of the download. Any XULRunner feature layout would
need to allow ATF to package only the platform version of XULRunner
needed and not show any errors in the "Manage Configuration" wizard
when all the versions of not there.
Again, see above
I'm not a feature expert, so there may be a way around my
when just having one XULRunner feature.
> 3) Why isn't ATF depending on XULRunner feature/plugins like it is with
> XPCOM? With the feature linked above we were able to have our feature
> depend on it, and use external plugin/feature jar linking (ala the
> current ATF update site) to have Eclipse auto-check XULRunner when the
> user presses "Select Required"
This was done so a person can use ATF with an installed version of
XULRunner and not use the version packaged in a plugin. This allowed
the person to install a version of ATF without XULRunner. We probably
need to relook at the requirement. It may be possible to handle the
problem using the "optional" option on the feature.
If the user already
has XULRunner installed, then there will be no need
for them to check it in the update site. The hard requirement only
affects the user when they _don't_ have XULrunner already installed.
I'll look forward to chatting about it on the call tomorrow =).