October 2016 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-23380) MOJO that fails build if manifest in .core plugin has .ui dependency

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23380?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-23380: ------------------------------------ Maybe you can do this using an enforcer rule? https://github.com/jbosstools/jbosstools-maven-plugins/tree/master/tycho-... Then you can test this by adding more rules into the parent pom: https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml... > MOJO that fails build if manifest in .core plugin has .ui dependency > -------------------------------------------------------------------- > > Key: JBIDE-23380 > URL: https://issues.jboss.org/browse/JBIDE-23380 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build > Reporter: Rob Stryker > Assignee: Rob Stryker > Fix For: 4.4.2.AM3 > > > At a minimum, the mojo should: > foreach plugin, if plugin ends in .core, check plugin/META-INF/MANIFEST for Dependencies manifest header, and verify .ui is not included in the dependencies at all. > However, this minimum goal would not have solved the issue we are experiencing with foundation.checkup. The foundation.checkup plugin does not end in .core and so would be skipped by this simple algorithm. > So... we may wish to check transitive dependencies *only in the same repo*. For example, foundation.core depends on foundation.checker, and foundation.checker is in the same repo, so foundation.checker should also be checked for ui deps or fail. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-934) Wrong core version in JBTIS TP 4.4.0.CR1-SNAPSHOT

by Paul Leacu (JIRA)

[ https://issues.jboss.org/browse/JBTIS-934?page=com.atlassian.jira.plugin.... ] Paul Leacu commented on JBTIS-934: ---------------------------------- SInce the current released Devstudio is 10.1.0.GA (Neon.0-based) - it must run there. [~apodhrad] - can you at least test the installation on Devtsudio 10.2? > Wrong core version in JBTIS TP 4.4.0.CR1-SNAPSHOT > ------------------------------------------------- > > Key: JBTIS-934 > URL: https://issues.jboss.org/browse/JBTIS-934 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Components: target-platform > Affects Versions: 4.4.0.CR1-TP > Reporter: Andrej Podhradsky > Assignee: Paul Leacu > Priority: Blocker > > I noticed that JBTIS TP 4.4.0.CR1-SNAPSHOT at > https://repository.jboss.org/nexus/content/groups/public/org/jboss/tools/... > defines the following repository > http://download.jboss.org/jbosstools/neon/staging/updates/core/4.4.2.AM1/ > which is supposed for JBT 4.4.2 / Devstudio 10.2.0 (which will be released later than Devstudio-IS 10.0.0.GA). > I think that there should be the stable one which is 4.4.1.Final. Please correct me if I'm wrong. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23380) MOJO that fails build if manifest in .core plugin has .ui dependency

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23380?page=com.atlassian.jira.plugi... ] Nick Boldt reassigned JBIDE-23380: ---------------------------------- Assignee: Rob Stryker > MOJO that fails build if manifest in .core plugin has .ui dependency > -------------------------------------------------------------------- > > Key: JBIDE-23380 > URL: https://issues.jboss.org/browse/JBIDE-23380 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build > Reporter: Rob Stryker > Assignee: Rob Stryker > Fix For: 4.4.2.AM3 > > > At a minimum, the mojo should: > foreach plugin, if plugin ends in .core, check plugin/META-INF/MANIFEST for Dependencies manifest header, and verify .ui is not included in the dependencies at all. > However, this minimum goal would not have solved the issue we are experiencing with foundation.checkup. The foundation.checkup plugin does not end in .core and so would be skipped by this simple algorithm. > So... we may wish to check transitive dependencies *only in the same repo*. For example, foundation.core depends on foundation.checker, and foundation.checker is in the same repo, so foundation.checker should also be checked for ui deps or fail. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23380) MOJO that fails build if manifest in .core plugin has .ui dependency

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23380?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-23380: ------------------------------- Fix Version/s: 4.4.2.AM3 > MOJO that fails build if manifest in .core plugin has .ui dependency > -------------------------------------------------------------------- > > Key: JBIDE-23380 > URL: https://issues.jboss.org/browse/JBIDE-23380 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build > Reporter: Rob Stryker > Assignee: Rob Stryker > Fix For: 4.4.2.AM3 > > > At a minimum, the mojo should: > foreach plugin, if plugin ends in .core, check plugin/META-INF/MANIFEST for Dependencies manifest header, and verify .ui is not included in the dependencies at all. > However, this minimum goal would not have solved the issue we are experiencing with foundation.checkup. The foundation.checkup plugin does not end in .core and so would be skipped by this simple algorithm. > So... we may wish to check transitive dependencies *only in the same repo*. For example, foundation.core depends on foundation.checker, and foundation.checker is in the same repo, so foundation.checker should also be checked for ui deps or fail. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-934) Wrong core version in JBTIS TP 4.4.0.CR1-SNAPSHOT

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBTIS-934?page=com.atlassian.jira.plugin.... ] Nick Boldt commented on JBTIS-934: ---------------------------------- Is the intent that IS bits will run on Devstudio 10.1 or 10.2? > Wrong core version in JBTIS TP 4.4.0.CR1-SNAPSHOT > ------------------------------------------------- > > Key: JBTIS-934 > URL: https://issues.jboss.org/browse/JBTIS-934 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Components: target-platform > Affects Versions: 4.4.0.CR1-TP > Reporter: Andrej Podhradsky > Assignee: Paul Leacu > Priority: Blocker > > I noticed that JBTIS TP 4.4.0.CR1-SNAPSHOT at > https://repository.jboss.org/nexus/content/groups/public/org/jboss/tools/... > defines the following repository > http://download.jboss.org/jbosstools/neon/staging/updates/core/4.4.2.AM1/ > which is supposed for JBT 4.4.2 / Devstudio 10.2.0 (which will be released later than Devstudio-IS 10.0.0.GA). > I think that there should be the stable one which is 4.4.1.Final. Please correct me if I'm wrong. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-934) Wrong core version in JBTIS TP 4.4.0.CR1-SNAPSHOT

by Paul Leacu (JIRA)

[ https://issues.jboss.org/browse/JBTIS-934?page=com.atlassian.jira.plugin.... ] Paul Leacu commented on JBTIS-934: ---------------------------------- Hey [~apodhrad] - we'll be talking about this in the JBT build.next mtg in a half hour here if you're interested. https://bluejeans.com/2875450010 fyi > Wrong core version in JBTIS TP 4.4.0.CR1-SNAPSHOT > ------------------------------------------------- > > Key: JBTIS-934 > URL: https://issues.jboss.org/browse/JBTIS-934 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Components: target-platform > Affects Versions: 4.4.0.CR1-TP > Reporter: Andrej Podhradsky > Assignee: Paul Leacu > Priority: Blocker > > I noticed that JBTIS TP 4.4.0.CR1-SNAPSHOT at > https://repository.jboss.org/nexus/content/groups/public/org/jboss/tools/... > defines the following repository > http://download.jboss.org/jbosstools/neon/staging/updates/core/4.4.2.AM1/ > which is supposed for JBT 4.4.2 / Devstudio 10.2.0 (which will be released later than Devstudio-IS 10.0.0.GA). > I think that there should be the stable one which is 4.4.1.Final. Please correct me if I'm wrong. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-921) Add an IS presence in developers.redhat.com

by Paul Leacu (JIRA)

[ https://issues.jboss.org/browse/JBTIS-921?page=com.atlassian.jira.plugin.... ] Paul Leacu commented on JBTIS-921: ---------------------------------- https://github.com/redhat-developer/developers.redhat.com/pull/1538 > Add an IS presence in developers.redhat.com > ------------------------------------------- > > Key: JBTIS-921 > URL: https://issues.jboss.org/browse/JBTIS-921 > Project: JBoss Tools Integration Stack > Issue Type: Feature Request > Components: distribution > Affects Versions: 9.0.2.GA > Reporter: Paul Leacu > Assignee: Paul Leacu > > Modify the devstudio product in developers.redhat.com to point to an Integration Stack non-product. From there reference Fuse Tooling, DataVirt and BRMS tooling. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBDS-4114) Remove cygwin from Mac installer

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBDS-4114?page=com.atlassian.jira.plugin.... ] Denis Golovin updated JBDS-4114: -------------------------------- Sprint: devex #121 October 2016 > Remove cygwin from Mac installer > -------------------------------- > > Key: JBDS-4114 > URL: https://issues.jboss.org/browse/JBDS-4114 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Task > Components: platform-installer > Affects Versions: 10.2.0.AM2 > Reporter: Jan Richter > Assignee: Denis Golovin > > There is no need for cygwin on mac since there is bash. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23352) Deploy Docker Wizard: Default routing port selection need more info for users

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23352?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-23352: ------------------------------------- Attachment: refdoc-services-2.png refdoc-services-1.png webui-deploy-docker-image.png > Deploy Docker Wizard: Default routing port selection need more info for users > ----------------------------------------------------------------------------- > > Key: JBIDE-23352 > URL: https://issues.jboss.org/browse/JBIDE-23352 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.4.1.AM2 > Reporter: Marián Labuda > Labels: deploy_docker_wizard, openshift_v3 > Fix For: 4.4.2.AM3 > > Attachments: no_route_selected.png, refdoc-services-1.png, refdoc-services-2.png, webui-deploy-docker-image.png > > > In the wizard on wizard page Services & Routing Settings, there is a table with mapped ports. No port is selected by default , but OpenShift knows what to open. > If there is only one port mapping, we could check it by default. If there are more port mappings, we could show a label/info/description what is gonna be done under the hood, so users will know what is happening. > steps to reproduce: > # EXEC: In Docker Explroer: pick an image and choose "Deploy to OpenShift..." in the context menu > # EXEC: get to the "Services & Routing Settings" page > !no_route_selected.png! > It's not obvious to the user what the wizard will create: A service that "exposes" pod ports and a route that points to this service. Furthermore it's not obvious that without a "checked" (used by route) port, the route will round-robin through the available ports. Additionally we should show the user what ports are exposed by the pod, and which ones are ports that the user added while no explicit exposure is defined in the pod (so he's on his own, if there's nothing listening on them he'll have users face non-functional or no reposonses at all). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23352) Deploy Docker Wizard: Default routing port selection need more info for users

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23352?page=com.atlassian.jira.plugi... ] Andre Dietisheim edited comment on JBIDE-23352 at 10/18/16 10:17 AM: --------------------------------------------------------------------- As examples for explanations in our page I'd took screenshots in the webui, where you're told - for a given docker image that you want to deploy - that the ports are being load balanced (which is what happens in our ui when no route port is selected): !webui-deploy-docker-image.png! We could also explain that we will create a service and a route for the image. Then explaining what serivces and routes offer (the following is taken from the reference docs at https://docs.openshift.com/enterprise/3.0/architecture/core_concepts/pods...): !refdoc-services-1.png! !refdoc-services-2.png! was (Author: adietish): As examples for explanations in our page I'd took screenshots in the webui, where you're told - for a given docker image that you want to deploy - that the ports are being load balanced (which is what happens in our ui when no route port is selected): !webui-deploy-docker-image.png! We could also explain that we will create a service and a route for the image. Then explaining what serivces and routes offer: !refdoc-services-1.png! !refdoc-services-2.png! > Deploy Docker Wizard: Default routing port selection need more info for users > ----------------------------------------------------------------------------- > > Key: JBIDE-23352 > URL: https://issues.jboss.org/browse/JBIDE-23352 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.4.1.AM2 > Reporter: Marián Labuda > Labels: deploy_docker_wizard, openshift_v3 > Fix For: 4.4.2.AM3 > > Attachments: no_route_selected.png, refdoc-services-1.png, refdoc-services-2.png, webui-deploy-docker-image.png > > > In the wizard on wizard page Services & Routing Settings, there is a table with mapped ports. No port is selected by default , but OpenShift knows what to open. > If there is only one port mapping, we could check it by default. If there are more port mappings, we could show a label/info/description what is gonna be done under the hood, so users will know what is happening. > steps to reproduce: > # EXEC: In Docker Explroer: pick an image and choose "Deploy to OpenShift..." in the context menu > # EXEC: get to the "Services & Routing Settings" page > !no_route_selected.png! > It's not obvious to the user what the wizard will create: A service that "exposes" pod ports and a route that points to this service. Furthermore it's not obvious that without a "checked" (used by route) port, the route will round-robin through the available ports. Additionally we should show the user what ports are exposed by the pod, and which ones are ports that the user added while no explicit exposure is defined in the pod (so he's on his own, if there's nothing listening on them he'll have users face non-functional or no reposonses at all). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 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 2016