[jbosstools-issues] [JBoss JIRA] (JBIDE-13288) discovery URLs should use major/minor/service/milestone convention

Tue Apr 23 10:34:54 EDT 2013

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

Nick Boldt edited comment on JBIDE-13288 at 4/23/13 10:34 AM:
--------------------------------------------------------------

Since this request has been fleshed out as something that needs to be implemented in Central (not the discovery site), I'm assigning this to [~snjeza] to investigate. I don't frankly see the value if having an automatic cascade of URLs to ping every time we start up Central in order to automatically find the latest directory.xml file, which would then point to the latest discovery plugin jar, but if Max can explain why this has value, then perhaps we should consider it for 7.0.

Today the way Central works is this:

1. directory.xml (hard coded URL in the Central plugin, or value set in jbdevstudio.ini, or commandline override) -> 
2. plugin jar (listed in the directory.xml file) -> 
3. plugin.xml (inside the Discovery plugin jar) -> 
4. 1 embedded URL for each connector

Whereas it sounds like you're suggesting that we instead do this:

1. Check version of discovery plugin jar (using default directory.xml?) -> 
2. Use that to find the latest directory.xml (up to 3 404'd requests looking for a file, stopping on the oldest one (7/0/0/Beta1 before 7/0/0 before 7/0)) -> 
3. Use 2nd directory.xml to get URL of plugin jar (which might be the same as the one we started with in (1)) -> 
4. plugin.xml -> 
5. 1 embedded URL for each connector

The other problem with this is that if the Discovery plugin gets respun out of band, and you have a 7/0/0/Beta2a (after Beta2 is done but before CR1) or a 7/0/0/GA-1 (after GA but before 7/0/1) you need to ensure that you have a way of telling existing users that there's a new URL to scan. How will JBDS know there's a new discovery URL? 

---

Isn't it much easier to just update the existing static URL, https://devstudio.jboss.com/updates/7.0-development/devstudio-directory.xml or https://devstudio.jboss.com/updates/7.0/devstudio-directory.xml to include a newer jar? To date we have never seen a use case where we wanted to allow a user to install from an older collection of Central updates; on the contrary, we started doing Central (and eliminated the com.jboss.jbds.*.features) so that users could get NEWER 3rd party updates than what we had in an older JBDS version. 

I would like to close this REJECTED but I'll wait for more feedback from [~snjeza] and [~maxandersen] on why making things more complicated is warranted.

Please explain your userstory, "you potentially break already released versions". Has this ever happened? 

      was (Author: nickboldt):
    Since this request has been fleshed out as something that needs to be implemented in Central (not the discovery site), I'm assigning this to [~snjeza] to investigate. I don't frankly see the value if having an automatic cascade of URLs to ping every time we start up Central in order to automatically find the latest directory.xml file, which would then point to the latest discovery plugin jar, but if Max can explain why this has value, then perhaps we should consider it for 7.0.

Today the way Central works is this:

1. directory.xml (hard coded URL in the Central plugin, or value set in jbdevstudio.ini, or commandline override) -> 
2. plugin jar (listed in the directory.xml file) -> 
3. plugin.xml (inside the Discovery plugin jar) -> 
4. 1 embedded URL for each connector

Whereas it sounds like you're suggesting that we instead do this:

1. Check version of discovery plugin jar (using default directory.xml?) -> 
2. Use that to find the latest directory.xml (up to 3 404'd requests looking for a file, stopping on the oldest one (7/0/0/Beta1 before 7/0/0 before 7/0)) -> 
3. Use 2nd directory.xml to get URL of plugin jar (which might be the same as the one we started with in (1)) -> 
4. plugin.xml -> 
5. 1 embedded URL for each connector

The other problem with this is that if the Discovery plugin gets respun out of band, and you have a 7/0/0/Beta2a (after Beta2 is done but before CR1) or a 7/0/0/GA-1 (after GA but before 7/0/1) you need to ensure that you have a way of telling existing users that there's a new URL to scan. How will JBDS know there's a new discovery URL? 

---

Isn't it much easier to just update the existing static URL, https://devstudio.jboss.com/updates/7.0-development/devstudio-directory.xml or https://devstudio.jboss.com/updates/7.0/devstudio-directory.xml to include a newer jar? To date we have never seen a use case where we wanted to allow a user to install from an older collection of Central updates; on the contrary, we started doing Central (and eliminated the com.jboss.jbds.*.features) so that users could get NEWER 3rd party updates than what we had in an older JBDS version. 

I would like to close this REJECTED but I'll wait for more feedback from [~snjeza] and [~maxandersen] on why making things more complicated is warranted.

> discovery URLs should use major/minor/service/milestone convention 
> -------------------------------------------------------------------
>
>                 Key: JBIDE-13288
>                 URL: https://issues.jboss.org/browse/JBIDE-13288
>             Project: Tools (JBoss Tools)
>          Issue Type: Feature Request
>          Components: central
>    Affects Versions: 4.1.0.Alpha1
>            Reporter: Nick Boldt
>            Assignee: Snjezana Peco
>            Priority: Minor
>             Fix For: 4.1.0.Beta1
>
>
> Instead of 
> https://devstudio.jboss.com/updates/6.0/devstudio-directory.xml
> We should consider using something like
> https://devstudio.jboss.com/discovery/6/1/0/Alpha1/devstudio-directory.xml

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira