<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Replies inlined below:<br>
<br>
Robert Goodman wrote:<br>
<blockquote
cite="mid:OF3E4AF683.C639F086-ON8625739F.00641E1C-8625739F.006A401F@us.ibm.com"
type="cite"><tt><font size="2"><br>
> <br>
> 1) Why are the URLs for feature JARs and plugins so radically
different?
<br>
> Shouldn't the features / plugins dirs be in sync with each other?</font></tt>
<br>
<br>
<tt><font size="2">The URLs are based on history which really doesn't
matter at this point. This could potentially change. </font></tt></blockquote>
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)<br>
<blockquote
cite="mid:OF3E4AF683.C639F086-ON8625739F.00641E1C-8625739F.006A401F@us.ibm.com"
type="cite"><br>
<tt><font size="2"><br>
> 2) Why is XULRunner packaged as 3 seperate features? This becomes
hell <br>
> for dependency management purposes. It was easier for me to just
write
<br>
> one simple feature and put platform/OS conditions on each
XULRunner
<br>
> plugin. You can find my feature.xml here:<br>
> - <br>
> <a class="moz-txt-link-freetext" href="http://anonsvn.jboss.org/repos/jbosstools/trunk/vpe/features/org">http://anonsvn.jboss.org/repos/jbosstools/trunk/vpe/features/org</a>.<br>
> jboss.tools.xulrunner.feature/feature.xml</font></tt>
<br>
<br>
<tt><font size="2">ATF installs XULRunner two ways, automatically
downloaded
using updated manager and in ATF's platform specific "All-in-one"
zip files. </font></tt>
<br>
<br>
<tt><font size="2">1. Update manager</font></tt>
<br>
<br>
<tt><font size="2">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. </font></tt></blockquote>
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. <br>
<blockquote
cite="mid:OF3E4AF683.C639F086-ON8625739F.00641E1C-8625739F.006A401F@us.ibm.com"
type="cite"><br>
<br>
<tt><font size="2">2. "All-in-one"</font></tt>
<br>
<br>
<tt><font size="2">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. </font></tt>
<br>
<br>
</blockquote>
Again, see above<br>
<blockquote
cite="mid:OF3E4AF683.C639F086-ON8625739F.00641E1C-8625739F.006A401F@us.ibm.com"
type="cite"><tt><font size="2">I'm not a feature expert, so there may
be a way around
my concerns when just having one XULRunner feature. </font></tt>
<br>
<tt><font size="2"><br>
> 3) Why isn't ATF depending on XULRunner feature/plugins like it is
with <br>
> XPCOM? With the feature linked above we were able to have our
feature
<br>
> depend on it, and use external plugin/feature jar linking (ala the
<br>
> current ATF update site) to have Eclipse auto-check XULRunner when
the <br>
> user presses "Select Required"<br>
> </font></tt>
<br>
<br>
<tt><font size="2">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. </font></tt>
<br>
</blockquote>
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.<br>
<br>
I'll look forward to chatting about it on the call tomorrow =).<br>
</body>
</html>