Details
-
Type:
Sub-task
-
Status: Resolved (View Workflow)
-
Priority:
Major
-
Resolution: Done
-
Affects Version/s: 3.3.0.M2
-
Component/s: updatesite
-
Labels:None
Description
I assume we'll do something like:
Core: http://download.jboss.org/jbosstools/updates/nightly/trunk
SOA Tooling: http://download.jboss.org/jbosstools/updates/nightly/soa-tooling/trunk
And, for the next milestone:
Core: http://download.jboss.org/jbosstools/updates/development/indigo/
SOA Tooling: http://download.jboss.org/jbosstools/updates/development/soa-tooling/indigo/
And, once it's available in JBDS, we'll composite the sites together here:
http://devstudio.jboss.com/updates/5.0/staging/
and
http://devstudio.jboss.com/updates/5.0/
Does that make sense?
From http://devstudio.pad.engineering.redhat.com/5
"On updatesites we do a compositecontent split <root>/soa <root>/core (names to be decided)
We do that for both jbt and jbds
In JBT:
we do the updatesite split for composite-component
In JBDS:
we create two features:
JBoss Developer Studio Web
JBoss Developer Studio SOA Pack
(for those wanting to install sub-features they can use the "uncategorized
option" which we currently would not say is fully supported)"
Meaning we would have something like:
Core: http://download.jboss.org/jbosstools/updates/nightly/trunk/core
SOA Tooling: http://download.jboss.org/jbosstools/updates/nightly/trunk/soa
combined: http://download.jboss.org/jbosstools/updates/nightly/trunk/
Core: http://download.jboss.org/jbosstools/updates/development/indigo/core
SOA Tooling: http://download.jboss.org/jbosstools/updates/development/indigo/soa
combined: http://download.jboss.org/jbosstools/updates/development/indigo
For JBDS its separate locations too and merged into the main site.
The "extra" in JBDS is that there will be a SOA and Core feature for easy/restrained updates.
Its SOA's tasks to ensure what gets "aggregated" into the core sites are consistent (i.e. compatible)