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/co... 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? 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.to... 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 =). Thanks! -- Marshall Culpepper Red Hat Developer Studio, JBoss Tools marshall(a)jboss.org