[JBoss JIRA] (JBDS-3465) Consider using SpringIDE 3.7 (or 3.6.4?)
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3465?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-3465:
----------------------------------
You can get Zest 1.6 (and earlier versions too) from here, if it's not in Mars:
http://download.eclipse.org/tools/gef/updates/releases/
Please try again after installing Zest.
> Consider using SpringIDE 3.7 (or 3.6.4?)
> ----------------------------------------
>
> Key: JBDS-3465
> URL: https://issues.jboss.org/browse/JBDS-3465
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: central, target-platform
> Affects Versions: 9.0.0.Beta2
> Reporter: Nick Boldt
> Assignee: Marián Labuda
> Fix For: 9.0.0.Beta2
>
>
> There are new versions of SpringIDE available:
> {code:title=http://dist.springsource.com/release/TOOLS/update/e4.5}
> org.springframework.ide.eclipse.feature.feature.group 3.6.4.201503051146-RELEASE{code}
> {code:title=http://dist.springsource.com/snapshot/TOOLS/nightly/e4.5}
> org.springframework.ide.eclipse.feature.feature.group 3.7.0.201506181755-CI-B262{code}
> Which would we like to include in Central?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (JBIDE-20171) buildinfo.json reader fails if upstream MANIFEST.MF contains no SHA
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20171?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-20171:
------------------------------------
OK, so what would you call the plugins? They already have 4-part qualifiers like 1.9.2.16 or 1.9.2.19pre.
Maybe the simpler approach (which also solves the question of why the linux plugins aren't being built) is to not worry about re-tagging xulrunner every time we do a release.
Remember, this all started with your wanting to ensure we have tags for all the projects going into 4.3.0.Beta1 and future releases: JBIDE-20168
Would that work for you?
> buildinfo.json reader fails if upstream MANIFEST.MF contains no SHA
> -------------------------------------------------------------------
>
> Key: JBIDE-20171
> URL: https://issues.jboss.org/browse/JBIDE-20171
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: build
> Affects Versions: 4.3.0.Beta2
> Reporter: Nick Boldt
> Assignee: Max Rydahl Andersen
> Fix For: 4.3.0.Beta2
>
>
> Since the addition of a check that verifies exactly this condition:
> https://github.com/jbosstools/jbosstools-maven-plugins/commit/916f4521ba6...
> I've now got a situation where it's OK to have no SHA in the MANIFEST.MF, but a SHA in buildinfo.json.
> {code:title=https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build-sites.aggregate.site_master/10216/console}
> [ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:fetch-sources-from-manifests (fetch-sources) on project org.jboss.tools.site.core: Problem occurred checking upstream buildinfo.json files!
> [ERROR] /mnt/hudson_workspace/workspace/jbosstools-build-sites.aggregate.site_master/sources/aggregate/site/target/buildinfo/buildinfo_jbosstools-xulrunner.json
> [ERROR] contains 2edce933f7d64efbb4d7a5b16be8dadae8de766e, but upstream project's MANIFEST.MF has Eclipse-SourceReferences
> [ERROR] commitId .
> [ERROR] If you have locally built projects which are aggregated here,
> [ERROR] ensure they are built from the latest SHA from HEAD, not a local topic branch.
> [ERROR] Or, use -DskipCheckSHAs=true to bypass this check.
> [ERROR] -> [Help 1]{code}
> This happened after I put a buildinfo.json file here:
> http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
> I've since moved the file here to temporarily work around the build failure:
> http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (JBIDE-20171) buildinfo.json reader fails if upstream MANIFEST.MF contains no SHA
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20171?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-20171:
---------------------------------------------
im fine our tools catches issues and we fix them based on that.
but "Doesn't really matter if we rebuild it w/ new qualifiers or not", of course it does. It changes which JDK was used to build it, what dependences it was build against etc. thus not updating at least qualifiers for this is misleading IMO.
> buildinfo.json reader fails if upstream MANIFEST.MF contains no SHA
> -------------------------------------------------------------------
>
> Key: JBIDE-20171
> URL: https://issues.jboss.org/browse/JBIDE-20171
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: build
> Affects Versions: 4.3.0.Beta2
> Reporter: Nick Boldt
> Assignee: Max Rydahl Andersen
> Fix For: 4.3.0.Beta2
>
>
> Since the addition of a check that verifies exactly this condition:
> https://github.com/jbosstools/jbosstools-maven-plugins/commit/916f4521ba6...
> I've now got a situation where it's OK to have no SHA in the MANIFEST.MF, but a SHA in buildinfo.json.
> {code:title=https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build-sites.aggregate.site_master/10216/console}
> [ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:fetch-sources-from-manifests (fetch-sources) on project org.jboss.tools.site.core: Problem occurred checking upstream buildinfo.json files!
> [ERROR] /mnt/hudson_workspace/workspace/jbosstools-build-sites.aggregate.site_master/sources/aggregate/site/target/buildinfo/buildinfo_jbosstools-xulrunner.json
> [ERROR] contains 2edce933f7d64efbb4d7a5b16be8dadae8de766e, but upstream project's MANIFEST.MF has Eclipse-SourceReferences
> [ERROR] commitId .
> [ERROR] If you have locally built projects which are aggregated here,
> [ERROR] ensure they are built from the latest SHA from HEAD, not a local topic branch.
> [ERROR] Or, use -DskipCheckSHAs=true to bypass this check.
> [ERROR] -> [Help 1]{code}
> This happened after I put a buildinfo.json file here:
> http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
> I've since moved the file here to temporarily work around the build failure:
> http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (JBIDE-20141) Define which vanity URLs to use for publishing JBT/JBDS nightlies & dev sites
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20141?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-20141:
------------------------------------
{quote}I don't follow what you mean with index copied or symlinked. The html should just say something like "This is updatesite for JBoss Tools snapshot/development/release".{quote}
I was suggesting a page like this one: http://download.jboss.org/jbosstools/static/mars/development/updates/core...
Rather than a simple one like this: http://download.jboss.org/jbosstools/mars/development/updates/README.html
If you're happy w/ a static one rather than one that changes w/ every release, that's even easier for me. :)
{quote}
What content is it that you expect to be needing accurate/current ? The list of features/bundles ? just listing the one from from jboss tools core would not be correct anyway - it would just show what is in the raw core site.
{quote}
Good point - if you don't want the JBT feature listing (because the site's actually a composite of JBT+TP+Central+TP), then again, that makes the requirement to have a pretty HTML page simpler.
{quote}
I thought you said you wanted the core raw site to be browsable so you could navigate it to more easy check its content ? {quote}
No, I didn't mean that. But it doesn't matter. The point of this jira was to define which vanity URLs to use and what to locate in them. I've stopped arguing for what *I* want and instead will simply do what *you* want. :D
> Define which vanity URLs to use for publishing JBT/JBDS nightlies & dev sites
> -----------------------------------------------------------------------------
>
> Key: JBIDE-20141
> URL: https://issues.jboss.org/browse/JBIDE-20141
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, updatesite
> Affects Versions: 4.3.0.Beta1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.0.Beta2
>
>
> Today, we produce a lot of artifacts w/ every CI (snapshot), staging, development, & stable build.
> But sometimes, finding these artifacts can be a daunting task.
> Below are some URLs where things can be found.
> *CI builds / SNAPSHOTS / nightlies*
> * http://download.jboss.org/jbosstools/updates/nightly/master/ -> ../../mars/snapshots/builds/jbosstools-discovery.central_master/latest/all/repo/ (composite of Core + Central, *OLD URL PATTERN*)
> * http://download.jboss.org/jbosstools/updates/nightly/mars -> ../../mars/snapshots/builds/jbosstools-discovery.central_master/latest/all/repo/ (composite of Core + Central, *OLD URL PATTERN*)
> * http://download.jboss.org/jbosstools/mars/nightly/updates/ -> ../../mars/snapshots/builds/jbosstools-discovery.central_master/latest/all/repo/ (composite of Core + Central)
> * http://download.jboss.org/jbosstools/mars/snapshots/updates/ (individual projects' update sites)
> ** http://download.jboss.org/jbosstools/mars/snapshots/updates/core/master/
> ** http://download.jboss.org/jbosstools/mars/snapshots/updates/core/4.3.mars/
> ** http://download.jboss.org/jbosstools/mars/snapshots/updates/webtools/master/
> ** http://download.jboss.org/jbosstools/mars/snapshots/updates/webtools/4.3....
> ** ..
> * http://download.jboss.org/jbosstools/mars/snapshots/builds/ (individual timestamped CI builds)
> *Staging Sites*
> * http://download.jboss.org/jbosstools/mars/staging/builds/
> * http://download.jboss.org/jbosstools/mars/staging/updates/
> *Development Milestones*
> * http://download.jboss.org/jbosstools/updates/development/mars/ -> ../../mars/development/updates/ (*OLD URL PATTERN*)
> * http://download.jboss.org/jbosstools/mars/development/updates/ (composites & content that isn't *static*)
> * http://download.jboss.org/jbosstools/static/mars/development/updates/ (actual update sites, moved here for Akamai performance)
> ----
> For JBDS, we follow the same pattern as above but use https://devstudio.redhat.com/9.0/ instead of http://download.jboss.org/jbosstools/mars/ ... but we also have a /builds/installer/ folder because the public JBDS site now includes the standalone installer:
> * https://devstudio.redhat.com/9.0/development/builds/installer/
> Also, for JBDS we don't have to differentiate between /static/ and non-static content, since Akamai set up the entire server to be mirrored to their servers.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (JBIDE-20171) buildinfo.json reader fails if upstream MANIFEST.MF contains no SHA
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20171?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-20171 at 7/2/15 9:39 AM:
------------------------------------------------------------
Doesn't really matter if we rebuild it w/ new qualifiers or not; it'll still be published to the same folder and built from the same SHA at github. So the only difference between the version from 2012-11-26 @ 18:50:16 (build # 155) and a new rebuild will be the inclusion of Eclipse-SourceReferences in the MANIFEST.MF files. I agree w/ Max that we should use a new qualifier in the build.
HOWEVER... the current build has hardcoded qualifiers for the plugins, but fully-generated ones for the features:
* http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
* http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
So... is that acceptable? Same plugin versions, new feature versions?
{quote}By "expected & good" you mean "expected and issue should be fixed" or "expected, but it is okey to have this SHA missing" ? {quote}
I mean "it's expected that a missing SHA causes the comparison between 'SHA in buildinfo.json' and 'SHA in MANIFEST.MF' to fail the build.
If you think it's acceptable that the JBT aggregate build should allow a SHA check to PASS if there's no SHA in the manifest, then I can change the code to allow that. But I'd rather that the build fail if no Eclipse-SourceReference can be found.
See also https://github.com/jbosstools/jbosstools-maven-plugins/commit/916f4521ba6...
was (Author: nickboldt):
Doesn't really matter if we rebuild it w/ new qualifiers or not; it'll still be published to the same folder and built from the same SHA at github. So the only difference between the version from 2012-11-26 @ 18:50:16 (build # 155) and a new rebuild will be the inclusion of Eclipse-SourceReferences in the MANIFEST.MF files. I agree w/ Max that we should use a new qualifier in the build.
{quote}By "expected & good" you mean "expected and issue should be fixed" or "expected, but it is okey to have this SHA missing" ? {quote}
I mean "it's expected that a missing SHA causes the comparison between 'SHA in buildinfo.json' and 'SHA in MANIFEST.MF' to fail the build.
HOWEVER... the current build has hardcoded qualifiers for the plugins, but fully-generated ones for the features:
* http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
* http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
If you think it's acceptable that the JBT aggregate build should allow a SHA check to PASS if there's no SHA in the manifest, then I can change the code to allow that. But I'd rather that the build fail if no Eclipse-SourceReference can be found.
See also https://github.com/jbosstools/jbosstools-maven-plugins/commit/916f4521ba6...
> buildinfo.json reader fails if upstream MANIFEST.MF contains no SHA
> -------------------------------------------------------------------
>
> Key: JBIDE-20171
> URL: https://issues.jboss.org/browse/JBIDE-20171
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: build
> Affects Versions: 4.3.0.Beta2
> Reporter: Nick Boldt
> Assignee: Max Rydahl Andersen
> Fix For: 4.3.0.Beta2
>
>
> Since the addition of a check that verifies exactly this condition:
> https://github.com/jbosstools/jbosstools-maven-plugins/commit/916f4521ba6...
> I've now got a situation where it's OK to have no SHA in the MANIFEST.MF, but a SHA in buildinfo.json.
> {code:title=https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build-sites.aggregate.site_master/10216/console}
> [ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:fetch-sources-from-manifests (fetch-sources) on project org.jboss.tools.site.core: Problem occurred checking upstream buildinfo.json files!
> [ERROR] /mnt/hudson_workspace/workspace/jbosstools-build-sites.aggregate.site_master/sources/aggregate/site/target/buildinfo/buildinfo_jbosstools-xulrunner.json
> [ERROR] contains 2edce933f7d64efbb4d7a5b16be8dadae8de766e, but upstream project's MANIFEST.MF has Eclipse-SourceReferences
> [ERROR] commitId .
> [ERROR] If you have locally built projects which are aggregated here,
> [ERROR] ensure they are built from the latest SHA from HEAD, not a local topic branch.
> [ERROR] Or, use -DskipCheckSHAs=true to bypass this check.
> [ERROR] -> [Help 1]{code}
> This happened after I put a buildinfo.json file here:
> http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
> I've since moved the file here to temporarily work around the build failure:
> http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (JBIDE-20171) buildinfo.json reader fails if upstream MANIFEST.MF contains no SHA
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20171?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-20171 at 7/2/15 9:38 AM:
------------------------------------------------------------
Doesn't really matter if we rebuild it w/ new qualifiers or not; it'll still be published to the same folder and built from the same SHA at github. So the only difference between the version from 2012-11-26 @ 18:50:16 (build # 155) and a new rebuild will be the inclusion of Eclipse-SourceReferences in the MANIFEST.MF files. I agree w/ Max that we should use a new qualifier in the build.
{quote}By "expected & good" you mean "expected and issue should be fixed" or "expected, but it is okey to have this SHA missing" ? {quote}
I mean "it's expected that a missing SHA causes the comparison between 'SHA in buildinfo.json' and 'SHA in MANIFEST.MF' to fail the build.
HOWEVER... the current build has hardcoded qualifiers for the plugins, but fully-generated ones for the features:
* http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
* http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
If you think it's acceptable that the JBT aggregate build should allow a SHA check to PASS if there's no SHA in the manifest, then I can change the code to allow that. But I'd rather that the build fail if no Eclipse-SourceReference can be found.
See also https://github.com/jbosstools/jbosstools-maven-plugins/commit/916f4521ba6...
was (Author: nickboldt):
Doesn't really matter if we rebuild it w/ new qualifiers or not; it'll still be published to the same folder and built from the same SHA at github. So the only difference between the version from 2012-11-26 @ 18:50:16 (build # 155) and a new rebuild will be the inclusion of Eclipse-SourceReferences in the MANIFEST.MF files. I agree w/ Max that we should use a new qualifier in the build.
{quote}By "expected & good" you mean "expected and issue should be fixed" or "expected, but it is okey to have this SHA missing" ? {quote}
I mean "it's expected that a missing SHA causes the comparison between 'SHA in buildinfo.json' and 'SHA in MANIFEST.MF' to fail the build.
See also https://github.com/jbosstools/jbosstools-maven-plugins/commit/916f4521ba6...
If you think it's acceptable that the JBT aggregate build should allow a SHA check to PASS if there's no SHA in the manifest, then I can change the code to allow that. But I'd rather that the build fail if no Eclipse-SourceReference can be found.
> buildinfo.json reader fails if upstream MANIFEST.MF contains no SHA
> -------------------------------------------------------------------
>
> Key: JBIDE-20171
> URL: https://issues.jboss.org/browse/JBIDE-20171
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: build
> Affects Versions: 4.3.0.Beta2
> Reporter: Nick Boldt
> Assignee: Max Rydahl Andersen
> Fix For: 4.3.0.Beta2
>
>
> Since the addition of a check that verifies exactly this condition:
> https://github.com/jbosstools/jbosstools-maven-plugins/commit/916f4521ba6...
> I've now got a situation where it's OK to have no SHA in the MANIFEST.MF, but a SHA in buildinfo.json.
> {code:title=https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build-sites.aggregate.site_master/10216/console}
> [ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:fetch-sources-from-manifests (fetch-sources) on project org.jboss.tools.site.core: Problem occurred checking upstream buildinfo.json files!
> [ERROR] /mnt/hudson_workspace/workspace/jbosstools-build-sites.aggregate.site_master/sources/aggregate/site/target/buildinfo/buildinfo_jbosstools-xulrunner.json
> [ERROR] contains 2edce933f7d64efbb4d7a5b16be8dadae8de766e, but upstream project's MANIFEST.MF has Eclipse-SourceReferences
> [ERROR] commitId .
> [ERROR] If you have locally built projects which are aggregated here,
> [ERROR] ensure they are built from the latest SHA from HEAD, not a local topic branch.
> [ERROR] Or, use -DskipCheckSHAs=true to bypass this check.
> [ERROR] -> [Help 1]{code}
> This happened after I put a buildinfo.json file here:
> http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
> I've since moved the file here to temporarily work around the build failure:
> http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (JBIDE-20171) buildinfo.json reader fails if upstream MANIFEST.MF contains no SHA
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20171?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-20171 at 7/2/15 9:35 AM:
------------------------------------------------------------
Doesn't really matter if we rebuild it w/ new qualifiers or not; it'll still be published to the same folder and built from the same SHA at github. So the only difference between the version from 2012-11-26 @ 18:50:16 (build # 155) and a new rebuild will be the inclusion of Eclipse-SourceReferences in the MANIFEST.MF files. I agree w/ Max that we should use a new qualifier in the build.
{quote}By "expected & good" you mean "expected and issue should be fixed" or "expected, but it is okey to have this SHA missing" ? {quote}
I mean "it's expected that a missing SHA causes the comparison between 'SHA in buildinfo.json' and 'SHA in MANIFEST.MF' to fail the build.
See also https://github.com/jbosstools/jbosstools-maven-plugins/commit/916f4521ba6...
If you think it's acceptable that the JBT aggregate build should allow a SHA check to PASS if there's no SHA in the manifest, then I can change the code to allow that. But I'd rather that the build fail if no Eclipse-SourceReference can be found.
was (Author: nickboldt):
Doesn't really matter if we rebuild it w/ new qualifiers or not; it'll still be published to the same folder and built from the same SHA at github. So the only difference between the version from 2012-11-26 @ 18:50:16 (build # 155) and a new rebuild will be the inclusion of Eclipse-SourceReferences in the MANIFEST.MF files.
{quote}By "expected & good" you mean "expected and issue should be fixed" or "expected, but it is okey to have this SHA missing" ? {quote}
I mean "it's expected that a missing SHA causes the comparison between 'SHA in buildinfo.json' and 'SHA in MANIFEST.MF' to fail the build.
See also https://github.com/jbosstools/jbosstools-maven-plugins/commit/916f4521ba6...
If you think it's acceptable that the JBT aggregate build should allow a SHA check to PASS if there's no SHA in the manifest, then I can change the code to allow that. But I'd rather that the build fail if no Eclipse-SourceReference can be found.
> buildinfo.json reader fails if upstream MANIFEST.MF contains no SHA
> -------------------------------------------------------------------
>
> Key: JBIDE-20171
> URL: https://issues.jboss.org/browse/JBIDE-20171
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: build
> Affects Versions: 4.3.0.Beta2
> Reporter: Nick Boldt
> Assignee: Max Rydahl Andersen
> Fix For: 4.3.0.Beta2
>
>
> Since the addition of a check that verifies exactly this condition:
> https://github.com/jbosstools/jbosstools-maven-plugins/commit/916f4521ba6...
> I've now got a situation where it's OK to have no SHA in the MANIFEST.MF, but a SHA in buildinfo.json.
> {code:title=https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build-sites.aggregate.site_master/10216/console}
> [ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:fetch-sources-from-manifests (fetch-sources) on project org.jboss.tools.site.core: Problem occurred checking upstream buildinfo.json files!
> [ERROR] /mnt/hudson_workspace/workspace/jbosstools-build-sites.aggregate.site_master/sources/aggregate/site/target/buildinfo/buildinfo_jbosstools-xulrunner.json
> [ERROR] contains 2edce933f7d64efbb4d7a5b16be8dadae8de766e, but upstream project's MANIFEST.MF has Eclipse-SourceReferences
> [ERROR] commitId .
> [ERROR] If you have locally built projects which are aggregated here,
> [ERROR] ensure they are built from the latest SHA from HEAD, not a local topic branch.
> [ERROR] Or, use -DskipCheckSHAs=true to bypass this check.
> [ERROR] -> [Help 1]{code}
> This happened after I put a buildinfo.json file here:
> http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
> I've since moved the file here to temporarily work around the build failure:
> http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (JBIDE-20171) buildinfo.json reader fails if upstream MANIFEST.MF contains no SHA
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20171?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-20171:
------------------------------------
Doesn't really matter if we rebuild it w/ new qualifiers or not; it'll still be published to the same folder and built from the same SHA at github. So the only difference between the version from 2012-11-26 @ 18:50:16 (build # 155) and a new rebuild will be the inclusion of Eclipse-SourceReferences in the MANIFEST.MF files.
{quote}By "expected & good" you mean "expected and issue should be fixed" or "expected, but it is okey to have this SHA missing" ? {quote}
I mean "it's expected that a missing SHA causes the comparison between 'SHA in buildinfo.json' and 'SHA in MANIFEST.MF' to fail the build.
See also https://github.com/jbosstools/jbosstools-maven-plugins/commit/916f4521ba6...
If you think it's acceptable that the JBT aggregate build should allow a SHA check to PASS if there's no SHA in the manifest, then I can change the code to allow that. But I'd rather that the build fail if no Eclipse-SourceReference can be found.
> buildinfo.json reader fails if upstream MANIFEST.MF contains no SHA
> -------------------------------------------------------------------
>
> Key: JBIDE-20171
> URL: https://issues.jboss.org/browse/JBIDE-20171
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: build
> Affects Versions: 4.3.0.Beta2
> Reporter: Nick Boldt
> Assignee: Max Rydahl Andersen
> Fix For: 4.3.0.Beta2
>
>
> Since the addition of a check that verifies exactly this condition:
> https://github.com/jbosstools/jbosstools-maven-plugins/commit/916f4521ba6...
> I've now got a situation where it's OK to have no SHA in the MANIFEST.MF, but a SHA in buildinfo.json.
> {code:title=https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build-sites.aggregate.site_master/10216/console}
> [ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:fetch-sources-from-manifests (fetch-sources) on project org.jboss.tools.site.core: Problem occurred checking upstream buildinfo.json files!
> [ERROR] /mnt/hudson_workspace/workspace/jbosstools-build-sites.aggregate.site_master/sources/aggregate/site/target/buildinfo/buildinfo_jbosstools-xulrunner.json
> [ERROR] contains 2edce933f7d64efbb4d7a5b16be8dadae8de766e, but upstream project's MANIFEST.MF has Eclipse-SourceReferences
> [ERROR] commitId .
> [ERROR] If you have locally built projects which are aggregated here,
> [ERROR] ensure they are built from the latest SHA from HEAD, not a local topic branch.
> [ERROR] Or, use -DskipCheckSHAs=true to bypass this check.
> [ERROR] -> [Help 1]{code}
> This happened after I put a buildinfo.json file here:
> http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
> I've since moved the file here to temporarily work around the build failure:
> http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (JBIDE-19637) Runtime download hyperlink not working from New Server dialog on Mac
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19637?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-19637:
---------------------------------------
Linking to JBQA-12192 which is about testing the additional WTP server adapters where a similar button doesn't work for me.
> Runtime download hyperlink not working from New Server dialog on Mac
> --------------------------------------------------------------------
>
> Key: JBIDE-19637
> URL: https://issues.jboss.org/browse/JBIDE-19637
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.3.0.Alpha2
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Labels: help_wanted
> Fix For: 4.3.0.Beta2
>
>
> When you go through Servers view -> New Server -> EAP 6.1 -> New Runtime and then click "Download and install runtime...", it won't do anything.
> If you go through Preferences -> Server -> Runtime Environments -> Add -> EAP 6.1+ and then click the Download button, it will work.
> This issue applies to both JBDS 8.1.0.GA and JBoss Tools 4.3.0.Alpha2 testing build, but I doubt we will be able to fix this for 4.2.x.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (JBIDE-19598) Use "Build other project (extended)" to cascade aggregation
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19598?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-19598:
---------------------------------------------
downstream-ext-plugin was already in use when I did buildchow so it was added a while back: https://review.openstack.org/#/c/158117/
and now I grok it - got mislead by the "composite-install *test* jobs" and thought it was install tests, not tests if publish was needed.
But how do we avoid the downstream ext plugin to trigger if SCM has changed, but the build content has not ?
without check we are back to aggregation happen way too often are we not ?
> Use "Build other project (extended)" to cascade aggregation
> -----------------------------------------------------------
>
> Key: JBIDE-19598
> URL: https://issues.jboss.org/browse/JBIDE-19598
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Affects Versions: 4.3.0.Alpha2
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Priority: Minor
> Fix For: 4.3.0.Beta2
>
>
> In order to decide whether to cascade aggregation when components are build, we could use the "Build other project (extended)" plugin in order to trigger 2 aggregate jobs (site, coretests-site) when component has SCM changes.
> This would require changing all 17 component jobs (per stream = 34 jobs), but would eliminate the need for the composite-install test jobs [1].
> [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months