[ https://issues.jboss.org/browse/JBIDE-16128?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-16128: ------------------------------------ If you're not going to consume the sites, when why bother? How will you know what the performance pros/cons are if we don't stress-test the system? Is the point of this to publish just milestones and .Final bits? Or every single nightly build? If the former, that's semi-reasonable, especially if we are planning to move toward the IS model of "components can release their Final earlier than the rest of the stack". Thus instead of these sites: http://download.jboss.org/jbosstools/updates/stable/kepler/core/ http://download.jboss.org/jbosstools/builds/staging/ we'd have the equivalent bits in Nexus: https://repository.jboss.org/nexus/content/groups/public/org/jboss/tools/ https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... What exactly does moving to nexus get us? Automated cleanup of snapshots? We have that already. Fast downloads of both sites and zips? We have that already. Seems like all we'd be getting is another checkpoint process (deploy to staging then release from staging to public) which in a sense we already have [1], except the existing job can publish a nightly to release or a milestone to stable, not just a staged build to public. [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-promote/ Also, are you assuming that component owners will be responsible for doing their own promotes from nexus-staging to nexus-public? If that is your assumption, I challenge it. Chances are good the real person who'll be performing that step is YOU. Because realistically, many component leads don't even know how (or want to know how) to kick their own BUILD JOBS, much less play with Nexus to promote bits. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira