February 2015 - jbosstools-issues

[JBoss JIRA] (JBIDE-18911) allow URL in the form "from-code=git@github.com" for custom app source code and downloadable cartridges

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18911?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-18911: ------------------------------------- Issue Type: Enhancement (was: Bug) > allow URL in the form "from-code=git(a)github.com" for custom app source code and downloadable cartridges > ------------------------------------------------------------------------------------------------------- > > Key: JBIDE-18911 > URL: https://issues.jboss.org/browse/JBIDE-18911 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.2.0.Final > Reporter: Andre Dietisheim > Assignee: Andre Dietisheim > Labels: application_wizard, embed_wizard > Fix For: 4.2.3.Beta1 > > > We should be able to use urls that refer to github repositories when using custom application source code and downloadable cartridges -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-18911) allow URL in the form "from-code=git@github.com" for custom app source code and downloadable cartridges

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18911?page=com.atlassian.jira.plugi... ] Andre Dietisheim commented on JBIDE-18911: ------------------------------------------ but you can still add the cartridges from code. you simply have to use a slightly different "url": to use the wildfly cartridge use the following url instead: https://cartreflect-claytondev.rhcloud.com/github/openshift-cartridges/op... the format is the following: {code} https://cartreflect-claytondev.rhcloud.com/github/<organization>/<project> {code} > allow URL in the form "from-code=git(a)github.com" for custom app source code and downloadable cartridges > ------------------------------------------------------------------------------------------------------- > > Key: JBIDE-18911 > URL: https://issues.jboss.org/browse/JBIDE-18911 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.2.0.Final > Reporter: Andre Dietisheim > Assignee: Andre Dietisheim > Labels: application_wizard, embed_wizard > Fix For: 4.2.3.Beta1 > > > We should be able to use urls that refer to github repositories when using custom application source code and downloadable cartridges -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-18866) allow URL in the form "from-code=git@github.com" for custom app source code and downloadable cartridges

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18866?page=com.atlassian.jira.plugi... ] Andre Dietisheim commented on JBIDE-18866: ------------------------------------------ but you can still add the cartridges from code. you simply have to use a slightly different "url": to use the wildfly cartridge use the following url instead: https://cartreflect-claytondev.rhcloud.com/github/openshift-cartridges/op... the format is the following: {code} https://cartreflect-claytondev.rhcloud.com/github/<organization>/<project> {code} > allow URL in the form "from-code=git(a)github.com" for custom app source code and downloadable cartridges > ------------------------------------------------------------------------------------------------------- > > Key: JBIDE-18866 > URL: https://issues.jboss.org/browse/JBIDE-18866 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.2.0.Final > Reporter: Andre Dietisheim > Assignee: Andre Dietisheim > Labels: new_and_noteworthy > Fix For: 4.3.0.Alpha2 > > > We should be able to use urls that refer to github repositories when using custom application source code and downloadable cartridges -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-18911) allow URL in the form "from-code=git@github.com" for custom app source code and downloadable cartridges

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18911?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-18911: ------------------------------------- Workaround Description: to use the wildfly cartridge use the following url instead: https://cartreflect-claytondev.rhcloud.com/github/openshift-cartridges/op... the format is the following: https://cartreflect-claytondev.rhcloud.com/github/<organization>/<project> Workaround: Workaround Exists > allow URL in the form "from-code=git(a)github.com" for custom app source code and downloadable cartridges > ------------------------------------------------------------------------------------------------------- > > Key: JBIDE-18911 > URL: https://issues.jboss.org/browse/JBIDE-18911 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.2.0.Final > Reporter: Andre Dietisheim > Assignee: Andre Dietisheim > Labels: application_wizard, embed_wizard > Fix For: 4.2.3.Beta1 > > > We should be able to use urls that refer to github repositories when using custom application source code and downloadable cartridges -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-13835) Improve publish script (split? Move to maven?)

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13835?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen edited comment on JBIDE-13835 at 2/24/15 11:02 AM: ----------------------------------------------------------------------- {quote} So for the use case of "I want to rebuild JBDS from source" you suggest people take a few hundred source plugins, unpack them all, and build them one by one? What we have today is a zip containing 17 subfolders (one per github project) which can be built in series without any futzing other than unpacking the zip. " {quote} No, I suggest each component site build zips the source they are being built from and produce a source artifact that then gets aggregated. {quote} " why don't our maven builds produce -source artifacts? There has never been a request for that. There has ONLY ever been a request for a JBT and JBDS source zip." {quote} There has never been a request for fetching source from github - that was your choice on implementing the requirement. I'm here suggesting another one that removes any dependency on having to fetch from external server and from possible different content than what was used. {quote} "Therefore it's more expedient to get the sources when we need them rather than producing and aggregating source zips into a larger JBT and JBDS zip. Do we have a community need for source zips? Surely for the community people can just go to github directly and fetch from the appropriate tag, branch, or SHA?" {quote} I do not understand why you want request from community to make this relevant to do. The suggestion here I make I believe removes need on fetching sources again and from potentially different location - it makes the testing and reproducibility of our build pipleine much less dependent on future/external changes. about publish.sh I would probably make publish.sh call rsync.sh and then cleanup.sh to have these two steps independently more easily. And having md5 etc. generation done by the builds them self instead of done at publish step unless there is something I'm missing about why that must be at the publish step. was (Author: maxandersen): "So for the use case of "I want to rebuild JBDS from source" you suggest people take a few hundred source plugins, unpack them all, and build them one by one? What we have today is a zip containing 17 subfolders (one per github project) which can be built in series without any futzing other than unpacking the zip. " No, I suggest each component site build zips the source they are being built from and produce a source artifact that then gets aggregated. " why don't our maven builds produce -source artifacts? There has never been a request for that. There has ONLY ever been a request for a JBT and JBDS source zip." There has never been a request for fetching source from github - that was your choice on implementing the requirement. I'm here suggesting another one that removes any dependency on having to fetch from external server and from possible different content than what was used. "Therefore it's more expedient to get the sources when we need them rather than producing and aggregating source zips into a larger JBT and JBDS zip. Do we have a community need for source zips? Surely for the community people can just go to github directly and fetch from the appropriate tag, branch, or SHA?" I do not understand why you want request from community to make this relevant to do. The suggestion here I make I believe removes need on fetching sources again and from potentially different location - it makes the testing and reproducibility of our build pipleine much less dependent on future/external changes. about publish.sh I would probably make publish.sh call rsync.sh and then cleanup.sh to have these two steps independently more easily. And having md5 etc. generation done by the builds them self instead of done at publish step unless there is something I'm missing about why that must be at the publish step. > Improve publish script (split? Move to maven?) > ---------------------------------------------- > > Key: JBIDE-13835 > URL: https://issues.jboss.org/browse/JBIDE-13835 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Reporter: Mickael Istria > Fix For: 4.3.x > > > Publish script deals with a lot of different and not-always-related things. It makes it difficult to maintain it. We should think about some improvements such as > * different conventions from different stream > * components vs aggregate > * devstudio vs jbosstools. > Or, > * Make publishing part of a "mvn deploy" step. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTIS-399) Cannot install JBDS-IS earlyaccess in offline mode

by Paul Leacu (JIRA)

[ https://issues.jboss.org/browse/JBTIS-399?page=com.atlassian.jira.plugin.... ] Paul Leacu commented on JBTIS-399: ---------------------------------- similar problem is with JBDS using BYOE https://issues.jboss.org/browse/JBDS-3361 > Cannot install JBDS-IS earlyaccess in offline mode > -------------------------------------------------- > > Key: JBTIS-399 > URL: https://issues.jboss.org/browse/JBTIS-399 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Components: distribution > Affects Versions: 8.0.0.GA > Reporter: Andrej Podhradsky > Assignee: Paul Leacu > Priority: Critical > Attachments: error.txt > > > Cannot install JBDS-IS 8.0.0.GA early access in offline mode. Note that DV tooling (Teiid Designer and ModeShape) can be installed without any problem. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-13835) Improve publish script (split? Move to maven?)

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13835?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-13835: --------------------------------------------- "So for the use case of "I want to rebuild JBDS from source" you suggest people take a few hundred source plugins, unpack them all, and build them one by one? What we have today is a zip containing 17 subfolders (one per github project) which can be built in series without any futzing other than unpacking the zip. " No, I suggest each component site build zips the source they are being built from and produce a source artifact that then gets aggregated. " why don't our maven builds produce -source artifacts? There has never been a request for that. There has ONLY ever been a request for a JBT and JBDS source zip." There has never been a request for fetching source from github - that was your choice on implementing the requirement. I'm here suggesting another one that removes any dependency on having to fetch from external server and from possible different content than what was used. "Therefore it's more expedient to get the sources when we need them rather than producing and aggregating source zips into a larger JBT and JBDS zip. Do we have a community need for source zips? Surely for the community people can just go to github directly and fetch from the appropriate tag, branch, or SHA?" I do not understand why you want request from community to make this relevant to do. The suggestion here I make I believe removes need on fetching sources again and from potentially different location - it makes the testing and reproducibility of our build pipleine much less dependent on future/external changes. about publish.sh I would probably make publish.sh call rsync.sh and then cleanup.sh to have these two steps independently more easily. And having md5 etc. generation done by the builds them self instead of done at publish step unless there is something I'm missing about why that must be at the publish step. > Improve publish script (split? Move to maven?) > ---------------------------------------------- > > Key: JBIDE-13835 > URL: https://issues.jboss.org/browse/JBIDE-13835 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Reporter: Mickael Istria > Fix For: 4.3.x > > > Publish script deals with a lot of different and not-always-related things. It makes it difficult to maintain it. We should think about some improvements such as > * different conventions from different stream > * components vs aggregate > * devstudio vs jbosstools. > Or, > * Make publishing part of a "mvn deploy" step. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-19362) Garbled text in forge list when SWT_GTK3 is true

by Pavol Srna (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19362?page=com.atlassian.jira.plugi... ] Pavol Srna updated JBIDE-19362: ------------------------------- Attachment: garbled-text.png > Garbled text in forge list when SWT_GTK3 is true > ------------------------------------------------ > > Key: JBIDE-19362 > URL: https://issues.jboss.org/browse/JBIDE-19362 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: forge, upstream > Affects Versions: 4.3.0.Alpha1 > Reporter: Pavol Srna > Attachments: garbled-text.png > > > This is probably an older eclipse issue with GTK3 [1]. But if we can find some workaround for forge it would be nice. > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=446075 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-19362) Garbled text in forge list when SWT_GTK3 is true

by Pavol Srna (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19362?page=com.atlassian.jira.plugi... ] Pavol Srna updated JBIDE-19362: ------------------------------- Description: This is probably an older eclipse issue with GTK3 [1]. But if we can find some workaround for forge it would be nice. [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=446075 was: This is probably an older eclipse issue with GTK3. But if we can find some workaround for forge it would be nice. > Garbled text in forge list when SWT_GTK3 is true > ------------------------------------------------ > > Key: JBIDE-19362 > URL: https://issues.jboss.org/browse/JBIDE-19362 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: forge, upstream > Affects Versions: 4.3.0.Alpha1 > Reporter: Pavol Srna > > This is probably an older eclipse issue with GTK3 [1]. But if we can find some workaround for forge it would be nice. > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=446075 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-13835) Improve publish script (split? Move to maven?)

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13835?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-13835: ------------------------------------ {quote}The installable source bundles are buildable so I actually think it is enough.{quote} So for the use case of "I want to rebuild JBDS from source" you suggest people take a few hundred source plugins, unpack them all, and build them one by one? What we have today is a zip containing 17 subfolders (one per github project) which can be built in series without any futzing other than unpacking the zip. {quote}why don't our maven builds produce -source artifacts?{quote} There has never been a request for that. There has ONLY ever been a request for a JBT and JBDS source zip. Therefore it's more expedient to get the sources when we need them rather than producing and aggregating source zips into a larger JBT and JBDS zip. Do we have a community need for source zips? Surely for the community people can just go to github directly and fetch from the appropriate tag, branch, or SHA? {quote}Also, just to comment on the publish.sh script... {quote} Yes, agreed. That's why I'm refactoring it to rsync.sh so it's just doing an rsync copy, trivially generating MD5s for zips, and cleaning up old builds. See https://github.com/jbosstools/jbosstools-build-ci/pull/119 Are you suggesting you'd rather have the jobs configured to run rsync.sh THEN cleanup.sh as two steps? > Improve publish script (split? Move to maven?) > ---------------------------------------------- > > Key: JBIDE-13835 > URL: https://issues.jboss.org/browse/JBIDE-13835 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Reporter: Mickael Istria > Fix For: 4.3.x > > > Publish script deals with a lot of different and not-always-related things. It makes it difficult to maintain it. We should think about some improvements such as > * different conventions from different stream > * components vs aggregate > * devstudio vs jbosstools. > Or, > * Make publishing part of a "mvn deploy" step. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

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 February 2015