> > 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.