[JBoss JIRA] (JBTIS-1236) Cannot install Devstudio IS 12.0.0.CR1 in offline mode
by Andrej Podhradsky (JIRA)
Andrej Podhradsky created JBTIS-1236:
----------------------------------------
Summary: Cannot install Devstudio IS 12.0.0.CR1 in offline mode
Key: JBTIS-1236
URL: https://issues.jboss.org/browse/JBTIS-1236
Project: JBoss Tools Integration Stack
Issue Type: Bug
Components: distribution
Affects Versions: 12.0.0.CR1
Reporter: Andrej Podhradsky
Priority: Critical
Fix For: 12.0.0.GA
!ENTRY org.eclipse.equinox.p2.director 4 10053 2018-08-02 15:44:43.462
!MESSAGE Cannot complete the install because one or more required items could not be found.
!SUBENTRY 1 org.eclipse.equinox.p2.director 4 0 2018-08-02 15:44:43.464
!MESSAGE Software being installed: Data Tools Platform Open Data Access Designer 1.14.100.201806252017 (org.eclipse.datatools.connectivity.oda.designer.feature.feature.group 1.14.100.201806252017)
!SUBENTRY 1 org.eclipse.equinox.p2.director 4 0 2018-08-02 15:44:43.465
!MESSAGE Missing requirement: Data Tools Platform Open Data Access Designer 1.14.100.201806252017 (org.eclipse.datatools.connectivity.oda.designer.feature.feature.group 1.14.100.201806252017) requires 'org.eclipse.equinox.p2.iu; org.eclipse.pde.feature.group 3.4.0' but it could not be found
!ENTRY org.jboss.tools.usage 4 0 2018-08-02 15:44:43.549
!MESSAGE FrameworkEvent ERROR
!STACK 0
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (JBTIS-1226) Update BPMN2 Modeler to 1.5.0
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/JBTIS-1226?page=com.atlassian.jira.plugin... ]
Andrej Podhradsky edited comment on JBTIS-1226 at 8/2/18 12:00 PM:
-------------------------------------------------------------------
Verified with Devstudio IS 12.0.0.CR1-v20180719-1716-B12 which contains BPMN2 1.5.0.Final.
was (Author: apodhrad):
Verified with Devstudio IS 12.0.0.CR1-v20180719-1716-B12 which contains Drools 1.5.0.Final.
> Update BPMN2 Modeler to 1.5.0
> -----------------------------
>
> Key: JBTIS-1226
> URL: https://issues.jboss.org/browse/JBTIS-1226
> Project: JBoss Tools Integration Stack
> Issue Type: Task
> Affects Versions: 4.6.0.CR1
> Reporter: Paul Leacu
> Assignee: Paul Leacu
> Fix For: 4.6.0.CR1
>
>
> Update bpmn2 modeler to 1.5.0 for IS 4.6.0
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (JBIDE-26283) Baseline and reactor have same fully qualified version, but with different content in jbosstools-base plugins/features
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26283?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-26283 at 8/2/18 11:54 AM:
-------------------------------------------------------------
Digging deeper for the case of Forge, and looking at the org.jboss.tools.aesh.runtime_2.0.203.v20180614-0303 plugin which hasn't changed since 4.6.0.Final release [1], we see that the only actual changes are a timestamp stating when the build was done, and the sourceref in the manifest.
* pom.properties comment
!diff-baseline-with-local-build-commented-timestamps.png|thumbnail!
* manifest.mf eclipse-sourcereference change
!diff-baseline-with-local-build-sourcereferences-cause-problem.png|thumbnail!
[1] https://github.com/jbosstools/jbosstools-forge/commits/master
So... for this case, bumping version should technically not be required. I wonder if we could add a flag in the compare-version-with-baselines mojo to ignore sourceref deltas in manifest files, or if this means that our process of automatically updating root poms to a newer parent pom ALSO means we have to always bump plugins/features going forward. :(
[~mickael_istria] [~fbricon] [~jeffmaury] WDYT? Should we...
* find a way to not have to bump for projects that haven't changed (except a sourceref change in manifest),
* don't update to newer parent pom automatically as part of the Final/GA release process, until the project *actually* shows a new commit in master, or
* just blindly bump to new parent pom AND blindly bump to new x.y.z+1 version too
was (Author: nickboldt):
Digging deeper for the case of Forge, and looking at the org.jboss.tools.aesh.runtime_2.0.203.v20180614-0303 plugin which hasn't changed since 4.6.0.Final release [1], we see that the only actual changes are a timestamp stating when the build was done, and the sourceref in the manifest.
!diff-baseline-with-local-build-commented-timestamps.png|thumbnail!
!diff-baseline-with-local-build-sourcereferences-cause-problem.png|thumbnail!
[1] https://github.com/jbosstools/jbosstools-forge/commits/master
So... for this case, bumping version should technically not be required. I wonder if we could add a flag in the compare-version-with-baselines mojo to ignore sourceref deltas in manifest files, or if this means that our process of automatically updating root poms to a newer parent pom ALSO means we have to always bump plugins/features going forward. :(
[~mickael_istria] [~fbricon] [~jeffmaury] WDYT? Should we...
* find a way to not have to bump for projects that haven't changed (except a sourceref change in manifest),
* don't update to newer parent pom automatically as part of the Final/GA release process, until the project *actually* shows a new commit in master, or
* just blindly bump to new parent pom AND blindly bump to new x.y.z+1 version too
> Baseline and reactor have same fully qualified version, but with different content in jbosstools-base plugins/features
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-26283
> URL: https://issues.jboss.org/browse/JBIDE-26283
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.9.0.AM1
> Reporter: Josef Kopriva
> Assignee: Nick Boldt
> Priority: Blocker
> Fix For: 4.9.0.AM2
>
> Attachments: diff-baseline-with-local-build-commented-timestamps.png, diff-baseline-with-local-build-sourcereferences-cause-problem.png
>
>
> Job https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Devstud... is red for one week.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (JBIDE-26283) Baseline and reactor have same fully qualified version, but with different content in jbosstools-base plugins/features
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26283?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-26283:
------------------------------------
Digging deeper for the case of Forge, and looking at the org.jboss.tools.aesh.runtime_2.0.203.v20180614-0303 plugin which hasn't changed since 4.6.0.Final release [1], we see that the only actual changes are a timestamp stating when the build was done, and the sourceref in the manifest.
!diff-baseline-with-local-build-commented-timestamps.png|thumbnail!
!diff-baseline-with-local-build-sourcereferences-cause-problem.png|thumbnail!
[1] https://github.com/jbosstools/jbosstools-forge/commits/master
So... for this case, bumping version should technically not be required. I wonder if we could add a flag in the compare-version-with-baselines mojo to ignore sourceref deltas in manifest files, or if this means that our process of automatically updating root poms to a newer parent pom ALSO means we have to always bump plugins/features going forward. :(
[~mickael_istria] [~fbricon] [~jeffmaury] WDYT? Should we...
* find a way to not have to bump for projects that haven't changed (except a sourceref change in manifest),
* don't update to newer parent pom automatically as part of the Final/GA release process, until the project *actually* shows a new commit in master, or
* just blindly bump to new parent pom AND blindly bump to new x.y.z+1 version too
> Baseline and reactor have same fully qualified version, but with different content in jbosstools-base plugins/features
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-26283
> URL: https://issues.jboss.org/browse/JBIDE-26283
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.9.0.AM1
> Reporter: Josef Kopriva
> Assignee: Nick Boldt
> Priority: Blocker
> Fix For: 4.9.0.AM2
>
> Attachments: diff-baseline-with-local-build-commented-timestamps.png, diff-baseline-with-local-build-sourcereferences-cause-problem.png
>
>
> Job https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Devstud... is red for one week.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (JBIDE-26283) Baseline and reactor have same fully qualified version, but with different content in jbosstools-base plugins/features
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26283?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-26283:
------------------------------------
Looking at the spec for compare-version-with-baselines [1], one of the illegal versions is "same fully-qualified version as baseline, but with different binary content", which is what we're seeing here.
[1] https://www.eclipse.org/tycho/sitedocs-extras/tycho-p2-extras-plugin/comp...
So... as I'm not sure why this is happening other than the usual "someone forgot to bump a version after we released 4.6.0.Final", I'm bumping versions.
Base: https://github.com/jbosstools/jbosstools-base/commit/0594f0a41a1ceec00e72...
Central: https://github.com/jbosstools/jbosstools-central/commit/df3719f1ce67e6106...
Appears to be the same problem in forge, javaee, jst, openshift, vpe, webservices.
> Baseline and reactor have same fully qualified version, but with different content in jbosstools-base plugins/features
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-26283
> URL: https://issues.jboss.org/browse/JBIDE-26283
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.9.0.AM1
> Reporter: Josef Kopriva
> Assignee: Nick Boldt
> Priority: Blocker
> Fix For: 4.9.0.AM2
>
>
> Job https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Devstud... is red for one week.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (JBIDE-26071) Add server adapter for WildFly 13
by Pavol Srna (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26071?page=com.atlassian.jira.plugi... ]
Pavol Srna updated JBIDE-26071:
-------------------------------
Fix Version/s: 4.6.0.Final
(was: 4.9.0.AM1)
> Add server adapter for WildFly 13
> ---------------------------------
>
> Key: JBIDE-26071
> URL: https://issues.jboss.org/browse/JBIDE-26071
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Affects Versions: 4.6.0.AM2
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Priority: Blocker
> Fix For: 4.6.0.Final
>
>
> It turns out WildFly 13 was released yesterday. They're on a quarterly release cadence now apparently. So I wonder how we should deal with this. Perhaps should group some of the versions if there are no breaking changes for us? Or do you think it's better to stick with our current model of always adding a new adapter and that way you can always update the libs?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months