[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=13026453#comment-13026453 ] 

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

Mickael said:
{quote} I'm just not sure about why requirement should be there [under the mars folder], as several of them are really used in multiple steams simultaneously.{quote}
The Denis *agreed* but said the opposite as far as stream categorization goes:
{quote}I'd rather put them right under mars folder{quote}.

So... while it's true that some reqs span multiple releases, these are the minority, not the majority. I still think they make sense located under their own "stream", and by separating them into snapshot/development/stable, we can in theory do future cleanup more easily.

As to moving reqs around, that seems unlikely, but may be necessary when we move from target platform CRx to Final. Thus...
* when we pull some new CI build of Tern, we put it in */snapshots/*
*  when we pull Mars M5, we put it in */development/*
* when we pull Mars RC4/R, we put it in */stable/*
* when we rename a CRx target platform to Final, we ensure that the .target files contain no /snapshots/ or /development/ entries, only /stable/. This can easily be written as some kind of string grep test, or even some xslt.

To solve the issue of a requirement used for more than one stream... we can use symlinks between mars/stable/updates/<some req>/<version> and neptune/stable/updates/<some req>/<version> so that the req is available _as if it's one for Neptune_, until a newer version arrives. (In many cases we have been known to simply DROP requirements because they don't work with the latest Eclipse, then re-add them months later when a newer version DOES appear which DOES work.)

Max, are you suggesting we do /mars/updates/requirements/\{{color:red}snapshots{color},{color:orange}staging{color},{color:blue}development{color},{color:green}stable{color}\}/ instead of /mars/\{{color:red}snapshots{color},{color:orange}staging{color},{color:blue}development{color},{color:green}stable{color}\}/updates/requirements/ ? We can do that but then we would have a *different hierarchy* for requirements vs. for targetplatforms, builds, update sites, etc.



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