automated install-grinder install tests for JBDS will always fail because Jenkins can't see https://devstudio.jboss.com ----------------------------------------------------------------------------------------------------------------------- Key: JBDS-2455 URL: https://issues.jboss.org/browse/JBDS-2455 Project: Developer Studio (JBoss Developer Studio) Issue Type: Bug Security Level: Public(Everyone can see) Components: central Affects Versions: 6.0.0.GA, 7.0.0.Alpha1 Reporter: Nick Boldt Assignee: Nick Boldt Install-grinder tests [1] attempt to install from JBDS Central, via this URL [2] [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-4.0_stabl... [2] http://www.qa.jboss.com/binaries/RHDS/builds/staging/devstudio-6.0_stable... -> plugins/com.jboss.jbds.central.discovery_6.0.1.GA-v20130130-1759-B206.jar When you look in the discovery jar [3], you see that the URLs referenced within the plugin.xml are on devstudio.jboss.com [4], rather than www.qa.jboss.com [5]. [3] http://www.qa.jboss.com/binaries/RHDS/builds/staging/devstudio-6.0_stable... [4] https://devstudio.jboss.com/updates/6.0/central/core/ [5] http://www.qa.jboss.com/binaries/RHDS/builds/staging/devstudio-6.0_stable... So, we need to implement Central somehow so that the plugin.xml (with a plugin.properties) can have those URLs overridden by a commandline flag. This is somewhat already done for the SOA Tooling discovery plugin, using %jboss.soa.update.url: https://svn.jboss.org/repos/devstudio/branches/devstudio-6.0.x/product-so... However, IIRC it's only implemented at BUILD time, not RUN time, which means we would have to manually adjust the plugin within the Jenkins job workspace (with unzip, sed, zip) to make the change stick at RUN time, or wed have to rebuild it as part of the test run. Is there a better way?