Re: [atf-dev] XULRunner / ATF Update site

[Robert Goodman <goodmanr@xxxxxxxxxx>]

Comments below.

   Thanks
      bob


atf-dev-bounces@xxxxxxxxxxx wrote on 11/19/2007 12:08:12
PM:

> Hey everyone..
> 
> Recently I was looking over ATF's update site format to get a clue
for 
> how dependency on Mozilla's XPCOM and XULRunner plugins was handled.
I 
> found that the main ATF feature itself does depend on org.mozilla.xpcom,
> but not any of the XULRunner features/plugins. I also ran into another
> interesting problem. XULRunner has been bundled as a seperate feature
> for each platform implementation, and the plugins themselves live
at a 
> different URL than the features that I found.
> 
> The 3 platform-dependent XULRunner plugins live at the following URL:
> - 
> http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.
> 1.3/contrib/eclipse/
> 
> And the 3 platform-dependent XULRunner features live at the following
URL:
> - http://ftp.mozilla.org/pub/mozilla.org/xulrunner/eclipse/features/
> But the plugins listed at the corresponding "plugins" dir
are outdated!
> - http://ftp.mozilla.org/pub/mozilla.org/xulrunner/eclipse/plugins/
> 
> I have a few questions since this was rather confusing..
> 
> 1) Why are the URLs for feature JARs and plugins so radically different?
> 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. 

> 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:
> - 
> http://anonsvn.jboss.org/repos/jbosstools/trunk/vpe/features/org.
> jboss.tools.xulrunner.feature/feature.xml

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. 

2. "All-in-one"

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. 

I'm not a feature expert, so there may be a way around
my concerns 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. 

> Just hoping to get some clarity on how ATF depends on XULRunner and
> how/if we can reuse that knowledge for our project =).
> Thanks!
> 
> -- 
> Marshall Culpepper
> Red Hat Developer Studio, JBoss Tools
> marshall@xxxxxxxxx
> 
> _______________________________________________
> atf-dev mailing list
> atf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/atf-dev


I will add this to the agenda for the next public
status call. 


Robert Goodman
goodmanr@xxxxxxxxxx