July 2015 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (LOCUS-45) Do not deploy Locus artifacts to dl.jboss.org; only use nexus

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/LOCUS-45?page=com.atlassian.jira.plugin.s... ] Nick Boldt closed LOCUS-45. --------------------------- Close. > Do not deploy Locus artifacts to dl.jboss.org; only use nexus > ------------------------------------------------------------- > > Key: LOCUS-45 > URL: https://issues.jboss.org/browse/LOCUS-45 > Project: JBoss Tools Locus > Issue Type: Feature Request > Affects Versions: 1.3.0 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 1.3.0 > > > Nick said: > {quote} > We can now publish to Nexus as well as to dl.jb.org. I can disable the > publishing to dl.jb.org again if we no longer need that, and JUST use > the Nexus deployment. {quote} > Max said: > {quote} > I would disable all unnecessary publishing - it will just be forgotten > and someone someday will rely on the dl.jb.org bits when we wouldn't > want them to. Lets keep it as just one and locus for now is nexus bound. {quote} > So... I've updated the job again [0] to disable the deploy-to-jboss.org part. Not sure if I should also remove the profile entirely from the Locus site/pom.xml [1]. > [0] https://github.com/jbdevstudio/jbdevstudio-ci/commit/d29e92afdc5f93adfbf1... > [1] https://github.com/jbosstools/jbosstools-locus/blob/master/site/pom.xml#L... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOCUS-45) Do not deploy Locus artifacts to dl.jboss.org; only use nexus

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/LOCUS-45?page=com.atlassian.jira.plugin.s... ] Max Rydahl Andersen commented on LOCUS-45: ------------------------------------------ I dont find them offensive. if they were used they stay. thanks for deleting the unused/irrelevant mars ones. > Do not deploy Locus artifacts to dl.jboss.org; only use nexus > ------------------------------------------------------------- > > Key: LOCUS-45 > URL: https://issues.jboss.org/browse/LOCUS-45 > Project: JBoss Tools Locus > Issue Type: Feature Request > Affects Versions: 1.3.0 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 1.3.0 > > > Nick said: > {quote} > We can now publish to Nexus as well as to dl.jb.org. I can disable the > publishing to dl.jb.org again if we no longer need that, and JUST use > the Nexus deployment. {quote} > Max said: > {quote} > I would disable all unnecessary publishing - it will just be forgotten > and someone someday will rely on the dl.jb.org bits when we wouldn't > want them to. Lets keep it as just one and locus for now is nexus bound. {quote} > So... I've updated the job again [0] to disable the deploy-to-jboss.org part. Not sure if I should also remove the profile entirely from the Locus site/pom.xml [1]. > [0] https://github.com/jbdevstudio/jbdevstudio-ci/commit/d29e92afdc5f93adfbf1... > [1] https://github.com/jbosstools/jbosstools-locus/blob/master/site/pom.xml#L... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19948) Reimplement Eclipse Download plugin to allow dynamic work flow

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19948?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-19948: ------------------------------------- Hi [~dhladky]: [~maxandersen] and I have discussed the issue and do not feel a dynamic workflow is something we can make work in the next 2 months. Other things I've noticed by reviewing ORG-2414 are: 1) [~pmuir] indicated that the website does not use stacks.yaml 2) stacks.yaml is intended for automated consumption, not human consumption. 3) stacks.yaml has only a vague label "requiresCredentials" which isn't enough. We could possibly add a credentialType={jboss/redhat/apache/sourceforge/none} label as well, and eventually (2 years later?) deprecate the old requiresCredentials=true. 4) This would allow our plugin to provide different credentialing implementations and UI based on that flag, which would be useful. We would have to work under the assumption that all existing yaml objects with requiresCredentials=true and no credentialType value would default to the jboss credentialing. If we went this route, it'd also be easier for us to automatically tack on a ?workflow=direct or ?workflow=rest, since we'd know we're only doing it for those with the proper credentialType. But, again, as Pete said, it's not necessary at this time to have stacks usable by humans. 5) If we eventually wanted to change the expected request / response format, I would suggest we start passing protocol version strings back and forth. I would expect the server to continually support previous versions when such a flag is passed in, even if newer versions of the request/response are preferred. So for example, we would expect that the existing jdf urls continue to work as they currently do when no protocol version is passed in. This means you would check for a protocol version somehow (passed in as a parameter to the URL or via request header, still some questions here I need to work out). If there is none, you use the current behavior, which means you DO ask for country, but simply put in a "Not Required" option, or delete all options except "NOT REQUIRED". If a client *does* pass in a newer protocol version string, you could then provide a request/response protocol that never asks for a country. This would also allow you to make unit tests now that guarantee the behavior of existing urls with no protocol version passed in continue to function as they always have and never change. This would also allow you to make changes to the protocol however you wish (such as removing country, or adding new questions) so long as you do so only in a new version of the protocol. Then, clients can move up to the newest version at whatever speed they are able to, based on their internal schedules, release cycles, feasible timeframes, etc. Basically, the idea of you changing the request/response and us simply reacting 'dynamically' doesn't seem reasonable after some thought. The opportunity for bugs or regressions or breaking behavior is too great, as we've seen in the past 18 months. Having guaranteed protocols that do not change with version strings seems a much more reasonable solution. Doing it this way, though, also allows us a lot more flexibility than you'd think. Stacks.yaml would have something like credentialType=jboss. Our tools would recognize that, and could safely append a ?workflow=rest&version=2 (or request headers) if we wanted, without worrying that we're adding them to an apache or sourceforge download. And we could update our UI to match the protocol version we're using, without worrying you might change the protocol later. Finally, this would allow you to deprecate old protocol versions once you know all supported clients have moved off, rather than trying to get all clients to move or change at the same time. > Reimplement Eclipse Download plugin to allow dynamic work flow > -------------------------------------------------------------- > > Key: JBIDE-19948 > URL: https://issues.jboss.org/browse/JBIDE-19948 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: runtime-detection, server > Affects Versions: 4.3.0.Alpha2 > Reporter: David Hladky > Assignee: Rob Stryker > Fix For: 4.3.0.CR1 > > > We need to reimplement the plugin to accept new terms and conditions models as well as follow the workflow changes in case of changes to the current ones. > Under this issue I will create the tasks we need to achieve this goal. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOCUS-45) Do not deploy Locus artifacts to dl.jboss.org; only use nexus

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/LOCUS-45?page=com.atlassian.jira.plugin.s... ] Nick Boldt commented on LOCUS-45: --------------------------------- I have deleted these *snapshot* URLs: http://download.jboss.org/jbosstools/mars/snapshots/updates/locus/master http://download.jboss.org/jbosstools/mars/snapshots/builds/jbosstools-loc... I hope I understood your request, for it was confusingly punctuated and of convoluted sentence structure. *Old* URLs which have *not been changed*, but which I can happily delete / redirect if you find them offensive: http://download.jboss.org/jbosstools/builds/staging/jbosstools-locus.site... http://download.jboss.org/jbosstools/builds/staging/jbosstools-locus.site... http://download.jboss.org/jbosstools/updates/nightly/locus/ http://download.jboss.org/jbosstools/updates/nightly/locus/master/ http://download.jboss.org/jbosstools/updates/nightly/locus/provisional/ (no idea who created this) http://download.jboss.org/jbosstools/updates/development/locus/ http://download.jboss.org/jbosstools/updates/development/locus/1.1.0.Final/ http://download.jboss.org/jbosstools/updates/stable/locus/ http://download.jboss.org/jbosstools/updates/stable/locus/1.1.1.Final/ > Do not deploy Locus artifacts to dl.jboss.org; only use nexus > ------------------------------------------------------------- > > Key: LOCUS-45 > URL: https://issues.jboss.org/browse/LOCUS-45 > Project: JBoss Tools Locus > Issue Type: Feature Request > Affects Versions: 1.3.0 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 1.3.0 > > > Nick said: > {quote} > We can now publish to Nexus as well as to dl.jb.org. I can disable the > publishing to dl.jb.org again if we no longer need that, and JUST use > the Nexus deployment. {quote} > Max said: > {quote} > I would disable all unnecessary publishing - it will just be forgotten > and someone someday will rely on the dl.jb.org bits when we wouldn't > want them to. Lets keep it as just one and locus for now is nexus bound. {quote} > So... I've updated the job again [0] to disable the deploy-to-jboss.org part. Not sure if I should also remove the profile entirely from the Locus site/pom.xml [1]. > [0] https://github.com/jbdevstudio/jbdevstudio-ci/commit/d29e92afdc5f93adfbf1... > [1] https://github.com/jbosstools/jbosstools-locus/blob/master/site/pom.xml#L... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16379) Using symbolic links in the workspace path causes an infinite loop for m2e builder

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16379?page=com.atlassian.jira.plugi... ] Alexey Kazakov commented on JBIDE-16379: ---------------------------------------- Do we have a bugzilla link? > Using symbolic links in the workspace path causes an infinite loop for m2e builder > ---------------------------------------------------------------------------------- > > Key: JBIDE-16379 > URL: https://issues.jboss.org/browse/JBIDE-16379 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: maven, upstream > Affects Versions: 4.2.0.Alpha1 > Reporter: Snjezana Peco > Assignee: Snjezana Peco > Fix For: 4.3.x > > > See JBIDE-16286 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20216) Include Mylyn Wikitext Asciidoc editor in JBT/JBDS "CoreTools" update site category (not in Central, Marketplace or BYOE)

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20216?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-20216: ------------------------------------ Based on results of Max's investigation into org.eclipse.mylyn.wikitext.extras feature, we COULD simply add that feature into Central/Marketplace if we wanted to have wikitext asciidoc editor in JBT/JBDS Central/Marketplace. But since no one has requested it explicitly, that can be done in CR1 (if it's desired enough to open a new JIRA for the request). > Include Mylyn Wikitext Asciidoc editor in JBT/JBDS "CoreTools" update site category (not in Central, Marketplace or BYOE) > ------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-20216 > URL: https://issues.jboss.org/browse/JBIDE-20216 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: target-platform, updatesite, upstream > Affects Versions: 4.3.0.Beta1 > Reporter: Nick Boldt > Assignee: Len DiMaggio > Fix For: 4.3.0.Beta2 > > Attachments: Mylyn_ascii_doc.png > > > Wiki page: https://wiki.eclipse.org/Mylyn/WikiText/AsciiDoc > Update site: http://download.eclipse.org/mylyn/snapshots/nightly/docs/ (wikitext-extra) > Features to include: > * org.eclipse.mylyn.wikitext.extras > * org.eclipse.mylyn.wikitext_feature (already in TP: https://github.com/jbosstools/jbosstools-target-platforms/blob/4.50.x/jbo... [ see JBDS-3259 ] > * DONE: pull a mirror: http://download.jboss.org/jbosstools/updates/requirements/mylyn-extras/2.... (done) > * DONE: add it to JBT/JBDS TP: https://github.com/jbosstools/jbosstools-target-platforms/pull/158 (Nightly versions, not the mix of versions suggested in PR 159) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20244) server New and Noteworthy for 4.3.0.Beta2

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20244?page=com.atlassian.jira.plugi... ] Alexey Kazakov reassigned JBIDE-20244: -------------------------------------- Assignee: Rob Stryker > server New and Noteworthy for 4.3.0.Beta2 > ----------------------------------------- > > Key: JBIDE-20244 > URL: https://issues.jboss.org/browse/JBIDE-20244 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: archives, jmx, server > Reporter: Max Rydahl Andersen > Assignee: Rob Stryker > Priority: Critical > Fix For: 4.3.0.Beta2 > > > This [query|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+an...] contains the search for the specific component(s), to see all, use this [query|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+an...]. > If server is not listed here check if there are issues that should be added and add them. > Document the ones relevant for server by adding to [whatsnew|https://github.com/jbosstools/jbosstools-website/tree/master/doc...] and submit a pullrequest. > If no news for this component please reject and close this issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20234) Aerogear New and Noteworthy for 4.3.0.Beta2

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20234?page=com.atlassian.jira.plugi... ] Alexey Kazakov reassigned JBIDE-20234: -------------------------------------- Assignee: Gorkem Ercan Resolution: Done > Aerogear New and Noteworthy for 4.3.0.Beta2 > ------------------------------------------- > > Key: JBIDE-20234 > URL: https://issues.jboss.org/browse/JBIDE-20234 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: aerogear-hybrid > Reporter: Max Rydahl Andersen > Assignee: Gorkem Ercan > Priority: Critical > Fix For: 4.3.0.Beta2 > > > This [query|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+an...] contains the search for the specific component(s), to see all, use this [query|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+an...]. > If Aerogear is not listed here check if there are issues that should be added and add them. > Document the ones relevant for Aerogear by adding to [whatsnew|https://github.com/jbosstools/jbosstools-website/tree/master/doc...] and submit a pullrequest. > If no news for this component please reject and close this issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16379) Using symbolic links in the workspace path causes an infinite loop for m2e builder

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16379?page=com.atlassian.jira.plugi... ] Snjezana Peco commented on JBIDE-16379: --------------------------------------- The issue can be reproduced in Eclipse Mars. > Using symbolic links in the workspace path causes an infinite loop for m2e builder > ---------------------------------------------------------------------------------- > > Key: JBIDE-16379 > URL: https://issues.jboss.org/browse/JBIDE-16379 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: maven, upstream > Affects Versions: 4.2.0.Alpha1 > Reporter: Snjezana Peco > Assignee: Snjezana Peco > Fix For: 4.3.x > > > See JBIDE-16286 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19039) Window size shouldn't be computed proportionally to 'display' size but rather aligned with the components

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19039?page=com.atlassian.jira.plugi... ] Snjezana Peco resolved JBIDE-19039. ----------------------------------- Resolution: Rejected Forge wizards work as any wizards in Eclipse. Please reopen the jira if you still mean that is a problem. > Window size shouldn't be computed proportionally to 'display' size but rather aligned with the components > --------------------------------------------------------------------------------------------------------- > > Key: JBIDE-19039 > URL: https://issues.jboss.org/browse/JBIDE-19039 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: forge, upstream > Affects Versions: 4.2.2.Final > Reporter: Pavol Srna > Assignee: Snjezana Peco > Fix For: LATER > > Attachments: forge-scaffold-window.png, other-wizard.png > > > Wizard window size shouldn't be computed proportionally to 'display' size. But instead it should be aligned with the components that are in the wizard. > You can see on the screenshots how it looks when you have your monitor in portrait orientation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 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 July 2015