October 2017 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBTIS-1172) Move Teiid Designer to EA until it goes .Final

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBTIS-1172?page=com.atlassian.jira.plugin... ] Nick Boldt commented on JBTIS-1172: ----------------------------------- Actually I just realized your URLs are generic and don't include versions in them... so you already have in place URLs like https://devstudio.redhat.com/11/development/updates/integration-stack/dis... and http://download.jboss.org/jbosstools/oxygen/development/updates/integrati... Which means as long as you update those URLs to contain your latest Beta1 release, you should be all done -- no need for the maven script or a jenkins wrapper. That said, you might want to change your STAGING & CI/snapshot URLs to point at your STAGING & CI content, rather than the /development/ URLs. {code} #forthcoming CI builds of JBT and devstudio jboss.discovery.site.integration-stack.url|jbosstools|4.5.1.Final=http://... jboss.discovery.earlyaccess.site.integration-stack.url|jbosstools|4.5.1.F... jboss.discovery.site.integration-stack.url|devstudio|11.1.0.GA=https://de... jboss.discovery.earlyaccess.site.integration-stack.url|devstudio|11.1.0.G... # last staging build of devstudio jboss.discovery.site.integration-stack.url|devstudio|11.1.0.AM3=https://d... jboss.discovery.earlyaccess.site.integration-stack.url|devstudio|11.1.0.A... {code} > Move Teiid Designer to EA until it goes .Final > ---------------------------------------------- > > Key: JBTIS-1172 > URL: https://issues.jboss.org/browse/JBTIS-1172 > Project: JBoss Tools Integration Stack > Issue Type: Task > Components: distribution > Affects Versions: 4.5.1.Beta1 > Reporter: Paul Leacu > Assignee: Paul Leacu > Fix For: 4.5.1.Beta1 > > > Need to make Teiid Designer an early access component for the Beta release. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-1172) Move Teiid Designer to EA until it goes .Final

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBTIS-1172?page=com.atlassian.jira.plugin... ] Nick Boldt commented on JBTIS-1172: ----------------------------------- If you'd prefer to use a script to do the above updates, have a look at https://github.com/jbosstools/jbosstools-download.jboss.org/blob/master/j... - I'm not sure I've ever tested it to make changes to the *integration-stack.url* variables, but we could certainly add that if you'll find it useful. Then we can wrap that in a job like these two I use: https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/jbosstoo... https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/jbosstoo... so all you need to do is pass in the correct params and the files will be updated and pushed to dl.jb.o automatically. > Move Teiid Designer to EA until it goes .Final > ---------------------------------------------- > > Key: JBTIS-1172 > URL: https://issues.jboss.org/browse/JBTIS-1172 > Project: JBoss Tools Integration Stack > Issue Type: Task > Components: distribution > Affects Versions: 4.5.1.Beta1 > Reporter: Paul Leacu > Assignee: Paul Leacu > Fix For: 4.5.1.Beta1 > > > Need to make Teiid Designer an early access component for the Beta release. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-1172) Move Teiid Designer to EA until it goes .Final

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBTIS-1172?page=com.atlassian.jira.plugin... ] Nick Boldt commented on JBTIS-1172: ----------------------------------- *STAGING* Update these files for staging your beta, on the lines with jboss.discovery.site.integration-stack.url and jboss.discovery.earlyaccess.site.integration-stack.url: https://github.com/jbosstools/jbosstools-download.jboss.org/blob/master/j... https://github.com/jbosstools/jbosstools-download.jboss.org/blob/master/j... https://github.com/jbosstools/jbosstools-download.jboss.org/blob/master/j... (same changes here) *DEVELOPMENT* When you release your dev milestone and want it discovered inside JBT 4.5.1.AM3: https://github.com/jbosstools/jbosstools-download.jboss.org/blob/master/j... https://github.com/jbosstools/jbosstools-download.jboss.org/blob/master/j... (same changes here) *STABLE* When devstudio 11.1.0.GA / jbt 4.5.1.Final go live and we want to discover your Beta1/EA bits of TD: https://github.com/jbosstools/jbosstools-download.jboss.org/blob/master/j... https://github.com/jbosstools/jbosstools-download.jboss.org/blob/master/j... https://github.com/jbosstools/jbosstools-download.jboss.org/blob/master/j... (same changes here) > Move Teiid Designer to EA until it goes .Final > ---------------------------------------------- > > Key: JBTIS-1172 > URL: https://issues.jboss.org/browse/JBTIS-1172 > Project: JBoss Tools Integration Stack > Issue Type: Task > Components: distribution > Affects Versions: 4.5.1.Beta1 > Reporter: Paul Leacu > Assignee: Paul Leacu > Fix For: 4.5.1.Beta1 > > > Need to make Teiid Designer an early access component for the Beta release. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-25228) target platform fix-version and targetToRepoMojo no longer able to find multiple IU versions

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-25228?page=com.atlassian.jira.plugi... ] Mickael Istria edited comment on JBIDE-25228 at 10/13/17 12:23 PM: ------------------------------------------------------------------- ;../So {code:java}tpResolver.addDependency(ArtifactType.TYPE_INSTALLABLE_UNIT , unit.getId(), unit.getVersion());{code} is most likely the cause of the issue. It should be something like {code:java} String version = unit.getVersion(); if (version == null || version.isEmpty()) { version = "0.0.0"; } else if (!"0.0.0".equals(unit.getVersion()) { version = '[' + unit.getVersion() + ',' + unit.getVersion() + ']'; } tpResolver.addDependency(ArtifactType.TYPE_INSTALLABLE_UNIT , unit.getId(), version); {code} to make sure we lock to the resolved version and not to a range (just "1.6.0.xyz" actually means [1.6.0.xyz, 2.0.0) to p2 resolver IIRC) was (Author: mickael_istria): ;../So {code}tpResolver.addDependency(ArtifactType.TYPE_INSTALLABLE_UNIT , unit.getId(), unit.getVersion());{code} is most likely the cause of the issue. It should be something like {code} String version = unit.getVersion(); if (version == null || version.isEmpty()) { version = "0.0.0"; } else if ("0.0.0.equals(unit.getVersion()) { version = '[' + unit.getVersion() + ',' + unit.getVersion() + ']'; } tpResolver.addDependency(ArtifactType.TYPE_INSTALLABLE_UNIT , unit.getId(), version); {code} to make sure we lock to the resolved version and not to a range (just "1.6.0.xyz" actually means [1.6.0.xyz, 2.0.0) to p2 resolver IIRC) > target platform fix-version and targetToRepoMojo no longer able to find multiple IU versions > -------------------------------------------------------------------------------------------- > > Key: JBIDE-25228 > URL: https://issues.jboss.org/browse/JBIDE-25228 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: target-platform > Affects Versions: 4.5.1.Final > Reporter: Nick Boldt > Assignee: Nick Boldt > Priority: Blocker > Fix For: 4.5.1.Final > > > With these recent changes [0], [1], target platform resolution is no longer able to fetch more than one version of an IU. > We need apache.commons.codec 1.6.0.v201305230611, per the .target file [2], but only org.apache.commons.codec_1.9.0.v20170208-1614.jar is found in the update site [3], so the job [4] cannot perform an installation and validation of the TP fails. > Is there a setting I can pass in to make TargetToRepo more greedy about pulling multiple versions of IUs? > Note too that I was having problems last night getting the fix-version mojo to properly find and update the versions of WTP in the new 3.9.1a site, even when explicitly setting 0.0.0 to force it to search and update. Seems the target platform resolver will only pull the latest version of an IU, rather than an older one (a few WTP features have gone backwards in their timestamp). But it could also not resolve a version change from 3.3.600 [5] to 3.3.601 [6], so I had to update the version manually. > [0] https://github.com/jbosstools/jbosstools-maven-plugins/commit/2b724eceadb... > [1] https://github.com/jbosstools/jbosstools-maven-plugins/commit/ac4e492fab4... > [2] https://github.com/jbosstools/jbosstools-target-platforms/blob/4.71.x/jbo... > [3] http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.7... > [4] https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/jbosstoo... > [5] https://github.com/jbosstools/jbosstools-target-platforms/blob/14ec465a9b... > [6] https://github.com/jbosstools/jbosstools-target-platforms/blob/4.71.x/jbo... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-25228) target platform fix-version and targetToRepoMojo no longer able to find multiple IU versions

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-25228?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-25228: ---------------------------------------- ;../So {code}tpResolver.addDependency(ArtifactType.TYPE_INSTALLABLE_UNIT , unit.getId(), unit.getVersion());{code} is most likely the cause of the issue. It should be something like {code} String version = unit.getVersion(); if (version == null || version.isEmpty()) { version = "0.0.0"; } else if ("0.0.0.equals(unit.getVersion()) { version = '[' + unit.getVersion() + ',' + unit.getVersion() + ']'; } tpResolver.addDependency(ArtifactType.TYPE_INSTALLABLE_UNIT , unit.getId(), version); {code} to make sure we lock to the resolved version and not to a range (just "1.6.0.xyz" actually means [1.6.0.xyz, 2.0.0) to p2 resolver IIRC) > target platform fix-version and targetToRepoMojo no longer able to find multiple IU versions > -------------------------------------------------------------------------------------------- > > Key: JBIDE-25228 > URL: https://issues.jboss.org/browse/JBIDE-25228 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: target-platform > Affects Versions: 4.5.1.Final > Reporter: Nick Boldt > Assignee: Nick Boldt > Priority: Blocker > Fix For: 4.5.1.Final > > > With these recent changes [0], [1], target platform resolution is no longer able to fetch more than one version of an IU. > We need apache.commons.codec 1.6.0.v201305230611, per the .target file [2], but only org.apache.commons.codec_1.9.0.v20170208-1614.jar is found in the update site [3], so the job [4] cannot perform an installation and validation of the TP fails. > Is there a setting I can pass in to make TargetToRepo more greedy about pulling multiple versions of IUs? > Note too that I was having problems last night getting the fix-version mojo to properly find and update the versions of WTP in the new 3.9.1a site, even when explicitly setting 0.0.0 to force it to search and update. Seems the target platform resolver will only pull the latest version of an IU, rather than an older one (a few WTP features have gone backwards in their timestamp). But it could also not resolve a version change from 3.3.600 [5] to 3.3.601 [6], so I had to update the version manually. > [0] https://github.com/jbosstools/jbosstools-maven-plugins/commit/2b724eceadb... > [1] https://github.com/jbosstools/jbosstools-maven-plugins/commit/ac4e492fab4... > [2] https://github.com/jbosstools/jbosstools-target-platforms/blob/4.71.x/jbo... > [3] http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.7... > [4] https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/jbosstoo... > [5] https://github.com/jbosstools/jbosstools-target-platforms/blob/14ec465a9b... > [6] https://github.com/jbosstools/jbosstools-target-platforms/blob/4.71.x/jbo... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-25228) target platform fix-version and targetToRepoMojo no longer able to find multiple IU versions

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-25228?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-25228: ---------------------------------------- This is a bug in the Mojo for sure. The buildLog is interesting: it shows that TP validation mentions org.apache.commons.codec 1.6.0.v201305230611 (good); then later the MirrorMojo talks about 1.9.0. It seems like either the change in MirrorMojo fails at properly resolve TP and decides to use 1.9.0 (and pass it to the code doing the mirroring), or the TP resolution is correct, but the mirror step ignores the version. I'll compare the TP Validation Mojo and the Mirror one and see whether it could be a few settings missing to the code doing the TP resolution. > target platform fix-version and targetToRepoMojo no longer able to find multiple IU versions > -------------------------------------------------------------------------------------------- > > Key: JBIDE-25228 > URL: https://issues.jboss.org/browse/JBIDE-25228 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: target-platform > Affects Versions: 4.5.1.Final > Reporter: Nick Boldt > Assignee: Nick Boldt > Priority: Blocker > Fix For: 4.5.1.Final > > > With these recent changes [0], [1], target platform resolution is no longer able to fetch more than one version of an IU. > We need apache.commons.codec 1.6.0.v201305230611, per the .target file [2], but only org.apache.commons.codec_1.9.0.v20170208-1614.jar is found in the update site [3], so the job [4] cannot perform an installation and validation of the TP fails. > Is there a setting I can pass in to make TargetToRepo more greedy about pulling multiple versions of IUs? > Note too that I was having problems last night getting the fix-version mojo to properly find and update the versions of WTP in the new 3.9.1a site, even when explicitly setting 0.0.0 to force it to search and update. Seems the target platform resolver will only pull the latest version of an IU, rather than an older one (a few WTP features have gone backwards in their timestamp). But it could also not resolve a version change from 3.3.600 [5] to 3.3.601 [6], so I had to update the version manually. > [0] https://github.com/jbosstools/jbosstools-maven-plugins/commit/2b724eceadb... > [1] https://github.com/jbosstools/jbosstools-maven-plugins/commit/ac4e492fab4... > [2] https://github.com/jbosstools/jbosstools-target-platforms/blob/4.71.x/jbo... > [3] http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.7... > [4] https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/jbosstoo... > [5] https://github.com/jbosstools/jbosstools-target-platforms/blob/14ec465a9b... > [6] https://github.com/jbosstools/jbosstools-target-platforms/blob/4.71.x/jbo... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBDS-4588) update installer to be able to use JDK 9

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-4588?page=com.atlassian.jira.plugin.... ] Nick Boldt updated JBDS-4588: ----------------------------- Affects: Documentation (Ref Guide, User Guide, etc.),Release Notes,Compatibility/Configuration Release Notes Docs Status: Not Yet Documented > update installer to be able to use JDK 9 > ---------------------------------------- > > Key: JBDS-4588 > URL: https://issues.jboss.org/browse/JBDS-4588 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Bug > Components: installer > Affects Versions: 11.1.0.AM3 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 11.1.0.GA > > > Investigate what's needed to support running the installer w/ JDK 9. > May also need to add this to the devstudio.ini, after *-vmargs*: > {code}-Dosgi.requiredJavaVersion=1.8 > --add-modules=ALL-SYSTEM{code} -- https://wiki.eclipse.org/Configure_Eclipse_for_Java_9#Configure_Eclipse_f... > cc: [~mmalina] [~jeffmaury] [~dgolovin] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-1173) Missing TP for 11.1.0.Beta1 Early Access

by Paul Leacu (JIRA)

[ https://issues.jboss.org/browse/JBTIS-1173?page=com.atlassian.jira.plugin... ] Paul Leacu closed JBTIS-1173. ----------------------------- Resolution: Rejected No EA TP required for this release. > Missing TP for 11.1.0.Beta1 Early Access > ---------------------------------------- > > Key: JBTIS-1173 > URL: https://issues.jboss.org/browse/JBTIS-1173 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Components: target-platform > Affects Versions: 11.1.0.CR1 > Reporter: Andrej Podhradsky > Priority: Critical > > I noticed that there is no TP for 11.1.0.Beta1 Early Access even though the Teiid Designer is released on Early Access. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24671) [jbosstools-openshift] Block PRs for merge untill code is reviewed

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24671?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-24671: ------------------------------------ The bot doesn't need admin access. I updated my comment when I realized that even with protected master branch in jbosstools-fuse, I can still auto-updated root pom when it's time to move to a new parent pom version. > [jbosstools-openshift] Block PRs for merge untill code is reviewed > ------------------------------------------------------------------ > > Key: JBIDE-24671 > URL: https://issues.jboss.org/browse/JBIDE-24671 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: openshift > Affects Versions: 4.5.1.AM1 > Reporter: Nick Boldt > Assignee: Dmitrii Bocharov > Fix For: 4.5.1.Final > > Attachments: bot-admin-openshift.png, protected-master-branch.png > > > Nick asked: > {quote} > if we implement protected branches in github then no PRs can be merged w/o a PR review > so for projects like Base or Server, this would slow Rob down as he'd be even more dependent on PR reviews > for Openshift this would force Andre to break his PRs into smaller pieces so they could be more easily/quickly reviewed > otherwise all forward dev would be halted > so it's good from a "keep the code safe and clean" perspective > but if we don't actually get buy-in / acceptance from the people who submit the PRs and review them, it will block progress{quote} > Jeff replied: > {quote}I think this make more sense for OpenShift as we are more in a collaborative way, I have the feeling that Rob is more or less alone in server. So let's start with OpenShift but I would see this after the GA{quote} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-25221) [jbosstools-openshift] Block PRs for merge untill review (approved by other team members)

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-25221?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-25221: ------------------------------- Summary: [jbosstools-openshift] Block PRs for merge untill review (approved by other team members) (was: Block PRs for merge untill review (approved by other team members)) > [jbosstools-openshift] Block PRs for merge untill review (approved by other team members) > ----------------------------------------------------------------------------------------- > > Key: JBIDE-25221 > URL: https://issues.jboss.org/browse/JBIDE-25221 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Reporter: Dmitrii Bocharov > Assignee: Jeff MAURY > Fix For: 4.5.1.Final > > Attachments: protected_branch_only_for_review.png > > > There is a possibility in github to "protect" branch from merge based on the approval status, not on the Jenkins status as it is described in JBIDE-24439. See the attached image for details. > [~adietish] and [~jeffmaury] agreed with this idea in the mattermost. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues October 2017