[jbosstools-issues] [JBoss JIRA] (JBIDE-20993) http://download.jboss.org/jbosstools/ and https://devstudio.redhat.com contain symlinks to map relationship between Eclipse & JBDS versions

[Nick Boldt (JIRA)]

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

Nick Boldt commented on JBIDE-20993:
------------------------------------

You misunderstand me.

I was suggesting that instead of using:

* /mars/ and /neon/ for JBT and 
* /9.0/ and /10.0/ for JBDS (see how they're different?)
 
we could instead use:

* /mars/ and /neon/ for JBT and 
* /mars/ and /neon/ for JBDS (see how they're the same?).

So, no more symlinks would be needed, since it'd be the same path segment on both servers.

That said, obviously the stable URL for JBDS 9 would have to stay as https://devstudio.redhat.com/9.0/stable/updates/

But we could have this for JBDS 10:

https://devstudio.redhat.com/neon/stable/updates/
https://devstudio.redhat.com/neon/development/updates/
https://devstudio.redhat.com/neon/staging/updates/
https://devstudio.redhat.com/neon/snapshots/updates/

which would map nicely to the URLs for JBT 4.4:

http://download.jboss.org/jbosstools/neon/stable/updates/
http://download.jboss.org/jbosstools/neon/development/updates/
http://download.jboss.org/jbosstools/neon/staging/updates/
http://download.jboss.org/jbosstools/neon/snapshots/updates/

--

As to where/how I have scripts which require a different variable depending on which product is being published/released, well, here's an example:

https://github.com/jbdevstudio/jbdevstudio-product/blob/master/results/pom.xml#L154 (uses devstudioReleaseVersion = 10.0)
vs.
https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregate/site/pom.xml#L196 (uses eclipseReleaseName = neon)

If they both used *eclipseReleaseName* in the path, there'd be fewer places to have the code deviate.

Similarly the release guide for JBT/JBDS, pushing bits to (or from staging) uses nearly-identical scriptlets to copy bits around. But to further automate that via an actual script, we need more synchronicity between the releases so less things are different and the same script can be used for multiple purposes.

Thus a script like https://github.com/jbosstools/jbosstools-build-ci/pull/137/files could simply use `-eclipseReleaseName neon` instead of needing a different path segment for JBDS.

---

So, TL;DR: are you cool with these URLs for JBDS 10? Or do you need to see a /10.0/ path segment in there instead of /neon/ (cc: [~akazakov] ) ?

https://devstudio.redhat.com/neon/stable/updates/
https://devstudio.redhat.com/neon/development/updates/
https://devstudio.redhat.com/neon/staging/updates/
https://devstudio.redhat.com/neon/snapshots/updates/


> http://download.jboss.org/jbosstools/ and https://devstudio.redhat.com contain symlinks to map relationship between Eclipse & JBDS versions
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBIDE-20993
>                 URL: https://issues.jboss.org/browse/JBIDE-20993
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: build
>            Reporter: Max Rydahl Andersen
>            Assignee: Nick Boldt
>             Fix For: 4.3.1.Beta1
>
>
> while discussing download.jboss.org with [~dgolovin] we found 
> http://download.jboss.org/jbosstools/9.0/
> http://download.jboss.org/jbosstools/10.0/
> These look to be links to mars and neon.
> This is mixing in devstudio versioning with jbosstools which is just really confusing. 
> No idea what they are for and I haven't seen/noticed any mails or jiras about introducing a new versioning scheme.
> I suggest we delete these ASAP since download.jboss.org is already utterly overloaded with different schemes. 



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