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:
And the 3 platform-dependent XULRunner features live at the following URL:
But the plugins listed at the corresponding "plugins" dir are outdated!
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?
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:
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"
Just hoping to get some clarity on how ATF depends on XULRunner and
how/if we can reuse that knowledge for our project =).
Red Hat Developer Studio, JBoss Tools