[jbosstools-issues] [JBoss JIRA] (JBIDE-21233) remove need for a targetplatforms/jbosstoolstarget/neon site

[Nick Boldt (JIRA)]

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

Nick Boldt edited comment on JBIDE-21233 at 12/18/15 9:55 AM:
--------------------------------------------------------------

a) All aggregates & composites would be affected: /snapshots, /staging, /development and /stable. By having all 4 delivery types built & released the same way, we ensure more reliable releases.

b) Yes, I agree. The VISIBLE TP URL should not be there (nor should the 2 extra IS URLs). How do we get rid of it? We get rid of the associate sites and stick to just a composite site, since composites allow you to see the content of all the children but don't add extra URLs into the list of Available Software Sites. This is evident in JBDS (we only have one assoc site and it's a pointer to https://devstudio.redhat.com/$\{devstudioReleaseVersion}/stable/updates/ ), but not (yet) there in JBT since we have an assoc site link to our "latest TP" directly rather than hiding that under a composite site.

Re: 'too many sites visible in Available Software Sites' vs. 'uncategorized content' ... you can't have both. You can have one or the other. You mostly complain about URLs in the Available Software Sites preference page, so I have to assume that's the more important (*visible*) problem. But the side effect of building composite sites is that target platform content IS available from that same URL (but it's uncategorized). Same's true for JBDS. It has to be or else p2 wouldn't be able to find it.

I don't understand "lower level p2 concept". Please clarify. 

c) I refute that it's a problem. I also refute that we're actively moving in that direction, unless you count projects moving from JBoss to Eclipse. m2e, docker tools, angular, jsdt... sure, those release semi-independently of the JBT release cycle. But the rest of the components? Not so much. 

If that's a priority for JBDS 10, we should call that out as something that devs *need* to do. Last year I proposed doing CI builds for all the components, then having devs CHOOSE when to release a CI to "integration" and have ONLY those tagged released aggregated into the larger JBT/JBDS sites. No one adopted it. Instead we decided that QE and Dev should work more closely together and use CI builds more frequently... which seems like the opposite of the integration build model (which is comparable to what Eclipse does with map files). We're set up already so if devs want to have us build from tags instead of branches we can do that. Has anyone asked to do that? Not yet, because it's less overhead (more agile) to simply build CI from a branch than to deal with tags/mapfiles/integration builds. If you want it, it has to start at the dev level. Releng will support it (even if it's more overhead) but there needs to first be buy-in from the devs. Do they see the value? It does not (yet) seem that way. Convince them of the value, incentivize them to actually work differently, and we can move to a new development model. 


was (Author: nickboldt):
a) All aggregates & composites would be affected: /snapshots, /staging, /development and /stable. By having all 4 delivery types built & released the same way, we ensure more reliable releases.

b) Yes, I agree. The VISIBLE TP URL should not be there (nor should the 2 extra IS URLs). How do we get rid of it? We get rid of the associate sites and stick to just a composite site, since composites allow you to see the content of all the children but don't add extra URLs into the list of Available Software Sites. This is evident in JBDS (we only have one assoc site and it's a pointer to https://devstudio.redhat.com/${devstudioReleaseVersion}/stable/updates/ ), but not (yet) there in JBT since we have an assoc site link to our "latest TP" directly rather than hiding that under a composite site.

Re: 'too many sites visible in Available Software Sites' vs. 'uncategorized content' ... you can't have both. You can have one or the other. You mostly complain about URLs in the Available Software Sites preference page, so I have to assume that's the more important (*visible*) problem. But the side effect of building composite sites is that target platform content IS available from that same URL (but it's uncategorized). Same's true for JBDS. It has to be or else p2 wouldn't be able to find it.

I don't understand "lower level p2 concept". Please clarify. 

c) I refute that it's a problem. I also refute that we're actively moving in that direction, unless you count projects moving from JBoss to Eclipse. m2e, docker tools, angular, jsdt... sure, those release semi-independently of the JBT release cycle. But the rest of the components? Not so much. 

If that's a priority for JBDS 10, we should call that out as something that devs *need* to do. Last year I proposed doing CI builds for all the components, then having devs CHOOSE when to release a CI to "integration" and have ONLY those tagged released aggregated into the larger JBT/JBDS sites. No one adopted it. Instead we decided that QE and Dev should work more closely together and use CI builds more frequently... which seems like the opposite of the integration build model (which is comparable to what Eclipse does with map files). We're set up already so if devs want to have us build from tags instead of branches we can do that. Has anyone asked to do that? Not yet, because it's less overhead (more agile) to simply build CI from a branch than to deal with tags/mapfiles/integration builds. If you want it, it has to start at the dev level. Releng will support it (even if it's more overhead) but there needs to first be buy-in from the devs. Do they see the value? It does not (yet) seem that way. Convince them of the value, incentivize them to actually work differently, and we can move to a new development model. 

> remove need for a targetplatforms/jbosstoolstarget/neon site
> ------------------------------------------------------------
>
>                 Key: JBIDE-21233
>                 URL: https://issues.jboss.org/browse/JBIDE-21233
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: build, target-platform
>    Affects Versions: 4.4.0.Alpha1
>            Reporter: Nick Boldt
>            Assignee: Nick Boldt
>             Fix For: 4.4.0.Alpha1
>
>         Attachments: jbt-creeping-update-sites.png
>
>
> For the last few years, we've had an associate site ref inside the JBT agg site, pointing at "the latest maximum TP", eg., http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/mars/
> But since we now always co-release JBT with its TP in the same URL, this is only useful for someone who wants to do an OFFLINE install using the zip, which will then go ONLINE to resolve TP dependencies. It's at best a broken use case, and at worst it's unnecessary cruft to maintain. 
> Therefore I propose we stop linking to this site.
> We can build the aggregates using a specific TP (the one in the parent pom, natch), and simply NOT use an associate site in the JBT aggregate site build.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)