[jbosstools-issues] [JBoss JIRA] (JBDS-3208) reorg/refactor directories for consistency across JBT/JBDS

[Max Rydahl Andersen (JIRA)]

    [ https://issues.jboss.org/browse/JBDS-3208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13024252#comment-13024252 ] 

Max Rydahl Andersen commented on JBDS-3208:
-------------------------------------------

To be clear - the requirement is not necessarily that it is  a composite of multiple nightly builds; it is just the simplest way I know of providing a *stable* url for the release train that does not change just because our branch name changes.

i.e. /luna/nightly vs first its called luna/master then /luna/4.2.x 

And no, this does not mean I think master and 4.2.x are bad names for internal sanity - but the url we make public for nightly and/or snapshot testing makes sense to follow similar layout as our staging, development and stable sites for two reasons:

A) so users/testers/developers don't need to changed URL's in their test eclipse installs

B) the sites we test/build are as close to the real published content.



> reorg/refactor directories for consistency across JBT/JBDS
> ----------------------------------------------------------
>
>                 Key: JBDS-3208
>                 URL: https://issues.jboss.org/browse/JBDS-3208
>             Project: Developer Studio (JBoss Developer Studio)
>          Issue Type: Bug
>          Components: build
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Nick Boldt
>            Assignee: Nick Boldt
>             Fix For: 9.0.0.Alpha1
>
>
> Be it resolved - we should reorg directories for consistency across JBT/JBDS:
> {code}
>     download.jboss.org
>     <earlyaccess,updates,discovery>/mars
>        /snapshots [replace nightly]
>        /staging [rename content for QE, moves to development when approved]
>        /development
>        /stable (updates/mars/stable is a pointer back into updates/mars)
>       drop /integration (not used)
>     builds/<jobname>/<buildid>
>     builds/<jobname>/composite*.xml for last 2 builds
>     targetplatforms/<type>/<version>
> {code}
>     and
> {code}
>     devstudio.redhat.com
>     <earlyaccess,updates,discovery>/9.0
>        /snapshots
>        /staging
>        /development
>        /stable (updates/9.0/stable is a pointer back into updates/9.0)
>     builds/<jobname>/<buildid>
>     builds/<jobname>/composite*.xml for last 2 builds
>     targetplatforms/<type>/<version>
> {code}
> Further discussion in http://ether-man.rhcloud.com/p/build.next.20141112
> This would remove the idea of the composite staging site [1] and the composite install job [2], today used to determine when  it's time to run the aggregate builds, in favour of a new p2diff mechanism for determining if aggregates should be published. See JBIDE-18742 and JBIDE-16970. 
> [1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.2.luna/
> [2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_8.0.luna/job/jbosstools-composite-install_4.2.luna/



--
This message was sent by Atlassian JIRA
(v6.3.8#6338)