[jbosstools-issues] [JBoss JIRA] (JBIDE-17536) JBoss Tools Core Nightly update site fails to install if a new build is published during install

[Nick Boldt (JIRA)]

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

Nick Boldt commented on JBIDE-17536:
------------------------------------

"Best" depends on your usecase. The reason a Swiss Army knife has many tools in it is that there are many tools needed for all life's eventualities.

Some people want a simple, single, aggregate site from which to install JBT, or to build JBDS.
Some people want a larger, complex, composite site which includes the last N builds of JBT, but which would be slower to use for the average user (way more metadata to read).

I build solutions. What you do with them is up to your specific needs. JBDS builds want the /update/nightly/master; but some users may prefer to use /builds/nightly/master because it's less likely to change suddenly while you're using it.

That said, I've changed the aggregate build jobs so that they ONLY re-publish content when there's new upstream changes, like it USED to be before Mickael changed it to ALWAYS publish.

So, as a result, we now see builds only when something changes, eg between two versions of Base:

{code:title=https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-base_master/changes}
#497 (Jun 16, 2014 8:48:13 AM)
    JBDS-3048 : hard-code better default.version value (commit: 71780bb6b96218e7a0c48f5da6b5cb31d3d23080) — Fred Bricon / detail
{code}

{code:title=https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite-install_master/8805/console}
@@ -1899,12 +1899,12 @@
-plugins/org.jboss.tools.stacks.core_1.1.0.Beta3-v20140613-2208-B496.jar
-plugins/org.jboss.tools.stacks.core.source_1.1.0.Beta3-v20140613-2208-B496.jar
-plugins/org.jboss.tools.stacks.core.test_1.1.0.Beta3-v20140613-2208-B496.jar
-plugins/org.jboss.tools.stacks.core.test.source_1.1.0.Beta3-v20140613-2208-B496.jar
+plugins/org.jboss.tools.stacks.core_1.1.0.Beta3-v20140616-1249-B497.jar
+plugins/org.jboss.tools.stacks.core.source_1.1.0.Beta3-v20140616-1249-B497.jar
+plugins/org.jboss.tools.stacks.core.test_1.1.0.Beta3-v20140616-1249-B497.jar
+plugins/org.jboss.tools.stacks.core.test.source_1.1.0.Beta3-v20140616-1249-B497.jar
{code}


> JBoss Tools Core Nightly update site fails to install if a new build is published during install
> ------------------------------------------------------------------------------------------------
>
>                 Key: JBIDE-17536
>                 URL: https://issues.jboss.org/browse/JBIDE-17536
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: build
>    Affects Versions: 4.2.0.Beta2
>            Reporter: Martin Malina
>            Assignee: Nick Boldt
>             Fix For: 4.2.x
>
>
> When you install JBT nightly from http://download.jboss.org/jbosstools/updates/nightly/core/master/ into Eclipse and during the build, a new nightly build replaces the old one, you can get a failure like this:
> {code}http://download.jboss.org/jbosstools/updates/nightly/core/master/features/org.jboss.tools.wtp.runtimes.tomcat.feature_1.1.0.Beta3-v20140603-0027-B526.jar cannot be found{code}
> This is because during your install, the old jars were replaced with the new jars, i.e. different filenames.
> I'm not sure if it's something we really need to fix, it's open for discussion. But it happened to me yesterday and it wasn't the first time, so I'm throwing it on the table.
> Nick offered this alternative:
> install from a specific build folder instead of the "latest nightly"
> http://download.jboss.org/jbosstools/builds/nightly/core/master/2014-06-04_06-40-59-B8878/all/repo/
> http://download.jboss.org/jbosstools/builds/nightly/core/master/2014-06-04_09-46-40-B8879/all/repo/
> But obviously that's just a workaround, not a real solution.
> One way this could be achieved is this: plugins/ and features/ would contain jars from both the latest and previous builds. This way if you start installing (latest=build N) and in the middle of your installation there is a new build (N+1), there would still be jars for both N and N+1 builds.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)