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

[Nick Boldt (JIRA)]

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

Nick Boldt commented on JBDS-3208:
----------------------------------

Better suggestion from Mickael:

{quote}can we move the mars segment to the start?{quote}

I'm good with that, as it will mean that dir structures under the train-name folder should be identical for both JBT and JBDS, making mirroring even easier.

Max also asked if we could move the target platforms under the same structure.

If we did that we'd get this:



* /\{mars,9.0}/
**  /\{{color:red}snapshots{color},{color:orange}staging{color},{color:blue}development{color},{color:green}stable{color}\}/
***    /*updates*/
****     /\{core,coretests,webtools,hibernatetools,discovery,central,earlyaccess,integration-stack,integration-stack-earlyaccess}/
*****     /<build-version = 4.3.0.Alpha1, 4.3.0.Final...>/
***    /*targetplatforms*/
****    /\{jbosstoolstarget,jbtcentraltarget,...}/
*****    /<build-version = 4.41.\*,4.50.\*,...>/
***    /*builds*/
****    /<job-name>/
*****     /<build-version = B123, B124, B125...>/

For /static/ bits (Akamai caching), we would use the same tree structure but only put content in there for stable releases (.Final and .GA)

> 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)