October 2015 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBTIS-508) integration stack update sites mix discovery and earlyaccess causing inconsistent update mechanism

by Paul Leacu (JIRA)

[ https://issues.jboss.org/browse/JBTIS-508?page=com.atlassian.jira.plugin.... ] Paul Leacu commented on JBTIS-508: ---------------------------------- Corrected JBTIS composites: https://github.com/jbosstools/jbosstools-download.jboss.org/commit/d65979... > integration stack update sites mix discovery and earlyaccess causing inconsistent update mechanism > -------------------------------------------------------------------------------------------------- > > Key: JBTIS-508 > URL: https://issues.jboss.org/browse/JBTIS-508 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Components: releng > Reporter: Max Rydahl Andersen > Assignee: Paul Leacu > Priority: Blocker > > While reviewing JBIDE-20803 I noticed the following: > {code} > jboss.discovery.site.integration-stack.url|jbosstools|4.2.4=http://downlo... > {code} > The stable release for 4.2.4 is stated to point to the stable integration stack url which on surface looks good: > But there are a few problems: > 1) why not just point to http://download.jboss.org/jbosstools/updates/stable/luna/ and have the above internal detail url composited in ? > 2) the actual composite behind it right now is http://download.jboss.org/jbosstools/discovery/stable/integration-stack/4... which links in http://download.jboss.org/jbosstools/discovery/stable/integration-stack/4... (our main sites should never composite earlyaccees since then when users install supported versions they suddenly will now also have access to earlyaccess. > #1 is mainly just to reduce the number of updatesites actually necessary for users to work with > #2 seems to be something inherent broken in the IS build since earlyaccess shold *never* be aggregated into the release site. > Any earlyaccess connectors should explicitly point to a *separate* earlyaccess site. > I would also have expected that the discovery site with the discovery plugins was kept *separate* from the actual update sites to avoid any coupling between these. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20845) Unable to install breakpoint even if line number set to be generated

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20845?page=com.atlassian.jira.plugi... ] Snjezana Peco commented on JBIDE-20845: --------------------------------------- I can't reproduce the issue on Windows and Linux. {quote} But for Vlado (Fedora 22, KDE) it worked right away - no Line Number error and no need to click any button in the web app {quote} If the "Wa&rn when unable to install breakpoint due to missing line number attributes" property is unchecked, it will work as described above. If the property is checked, we will get the Java Breakpoint dialog, but the breakpoint will be hit without clicking any buttons. {quote} This cannot be right. removing the warning won't actually fix this issue of the breakpoint not being hit. And we should not be hardwiring user preferences in our setup like this IMO. {quote} I have thought you want to disable the Java Breakpoint dialog by default. [~mmalina] can you reproduce the issue when the "Wa&rn when unable to install breakpoint due to missing line number attributes" property is unchecked? > Unable to install breakpoint even if line number set to be generated > -------------------------------------------------------------------- > > Key: JBIDE-20845 > URL: https://issues.jboss.org/browse/JBIDE-20845 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: upstream > Affects Versions: 4.3.0.CR2 > Reporter: Martin Malina > Assignee: Rob Stryker > Fix For: 4.3.x, 4.4.0.Alpha1 > > Attachments: breakpoint-error.png, compiler-settings.png, lineNumber.png > > > I am unable to get breakpoints to work for a html5 project running on WildFly. > I tried to verify JBIDE-20804 so I created the html5 project from central, set a breakpoint in MemberService.listAllMembers() (line 72) and then selected Debug on server -> WildFly. The server was started in debugging mode and the project started deploying, but then I got an error: > Unable to install breakpoint in org.jboss.tools.example.html5.rest.MemberService$$$view3 due to missing line number attributes. Modify compiler options to generate line number attributes. > Reason: Absent Line Number Information > !breakpoint-error.png! > I checked and this option was checked in Preferences -> Java -> Compiler. Also, I even checked the project settings (.settings/org.eclipse.jdt.core.prefs) and it has: > org.eclipse.jdt.core.compiler.debug.lineNumber=generate > This happened to me on Mac with WildFly 8, 9 and 10. And psrna checked this for me on Linux and the result was the same. > I'm not really sure which component this should belong to, it looks like an upstream issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21022) open of .md files in project examples don't use markdown editor

by Max Rydahl Andersen (JIRA)

Max Rydahl Andersen created JBIDE-21022: ------------------------------------------- Summary: open of .md files in project examples don't use markdown editor Key: JBIDE-21022 URL: https://issues.jboss.org/browse/JBIDE-21022 Project: Tools (JBoss Tools) Issue Type: Bug Components: project-examples Reporter: Max Rydahl Andersen even though we have JBDS-3259 readme.md opened by project-examples still seem to use the default editor as opposed to the wiki text editor. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21012) Why do we deploy JBT components to Nexus snapshots repo?

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21012?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-21012: ---------------------------------------- AFAIK, setting the value before release seems best. See JBIDE-16128 for more details. > Why do we deploy JBT components to Nexus snapshots repo? > -------------------------------------------------------- > > Key: JBIDE-21012 > URL: https://issues.jboss.org/browse/JBIDE-21012 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, updatesite > Affects Versions: 4.3.0.Final, 4.4.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.3.1.Beta1, 4.4.0.Alpha1 > > > Currently, we deploy our x.y.z-SNAPSHOT update sites to the JBoss Nexus snapshots repo. > But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just: > * eat disk space in Nexus > * consume time/resources in Jenkins > Since we have the custom profile deploy-to-jboss.org in place for all our artifacts, why don't we set *maven.deploy.skip=true* in the parent pom for all the projects (except of course Locus and Browsersim Standalone, which would use maven.deploy.skip=false) ? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21012) Why do we deploy JBT components to Nexus snapshots repo?

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21012?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-21012: --------------------------------------------- so the updatesite pom don't pick up the alpha/beta/etc. qualifier ? any ways it could do that ? or is the solution that before release we set the site pom to have the right qualifier ? > Why do we deploy JBT components to Nexus snapshots repo? > -------------------------------------------------------- > > Key: JBIDE-21012 > URL: https://issues.jboss.org/browse/JBIDE-21012 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, updatesite > Affects Versions: 4.3.0.Final, 4.4.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.3.1.Beta1, 4.4.0.Alpha1 > > > Currently, we deploy our x.y.z-SNAPSHOT update sites to the JBoss Nexus snapshots repo. > But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just: > * eat disk space in Nexus > * consume time/resources in Jenkins > Since we have the custom profile deploy-to-jboss.org in place for all our artifacts, why don't we set *maven.deploy.skip=true* in the parent pom for all the projects (except of course Locus and Browsersim Standalone, which would use maven.deploy.skip=false) ? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21012) Why do we deploy JBT components to Nexus snapshots repo?

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21012?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-21012: ---------------------------------------- The version in pom.xml at the root of each component and in children pom are not changed between milestones. They are changed yearly. We only change the version of the parent pom, but this doesn't cascade to update sites pom. > Why do we deploy JBT components to Nexus snapshots repo? > -------------------------------------------------------- > > Key: JBIDE-21012 > URL: https://issues.jboss.org/browse/JBIDE-21012 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, updatesite > Affects Versions: 4.3.0.Final, 4.4.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.3.1.Beta1, 4.4.0.Alpha1 > > > Currently, we deploy our x.y.z-SNAPSHOT update sites to the JBoss Nexus snapshots repo. > But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just: > * eat disk space in Nexus > * consume time/resources in Jenkins > Since we have the custom profile deploy-to-jboss.org in place for all our artifacts, why don't we set *maven.deploy.skip=true* in the parent pom for all the projects (except of course Locus and Browsersim Standalone, which would use maven.deploy.skip=false) ? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3553) Integrate/Enable CodeRecommenders substring completion in JBDS

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBDS-3553?page=com.atlassian.jira.plugin.... ] Max Rydahl Andersen commented on JBDS-3553: ------------------------------------------- to be clear - I'm +1 on adding coderecommenders in, but lets just do some basic due diligence. substring completion is just one of many, right? Can someone outline the features we get beyond it ? last I checked the big feature of code recommenders was about showing the % of the likelihood of a completion being relevant for a given situation - afaik that only works for SWT/Eclipse platform code. Not for Java/JavaEE in general. Can anyone confirm ? The coderecommenders rely on a remote DB to be updated and I believe thre might also be data sent to coderecommenders or eclipse - is that part of the default code recommender suggested here ? if yes, how does that affect our online/offline story (if at all) ? > Integrate/Enable CodeRecommenders substring completion in JBDS > -------------------------------------------------------------- > > Key: JBDS-3553 > URL: https://issues.jboss.org/browse/JBDS-3553 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Feature Request > Components: p2-product > Reporter: Mickael Istria > Assignee: Mickael Istria > Fix For: 9.0.1.Beta1 > > > Eclipse Mars release are shipped with CodeRecommenders enabled so that Java developers can benefit from substring completion and many others: https://www.eclipse.org/recommenders/manual/ > JBDS doesn't have it enabled by default when installing from installer. Since it provides a lot of value for Java developers, it should be on by default. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21012) Why do we deploy JBT components to Nexus snapshots repo?

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21012?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-21012: --------------------------------------------- wether we use nexus or not we can't keep the same maven version in pom.xml for a year both branch and master. So if we do that then we got a problem. Which pom.xml are you explicitly referring to here? > Why do we deploy JBT components to Nexus snapshots repo? > -------------------------------------------------------- > > Key: JBIDE-21012 > URL: https://issues.jboss.org/browse/JBIDE-21012 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, updatesite > Affects Versions: 4.3.0.Final, 4.4.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.3.1.Beta1, 4.4.0.Alpha1 > > > Currently, we deploy our x.y.z-SNAPSHOT update sites to the JBoss Nexus snapshots repo. > But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just: > * eat disk space in Nexus > * consume time/resources in Jenkins > Since we have the custom profile deploy-to-jboss.org in place for all our artifacts, why don't we set *maven.deploy.skip=true* in the parent pom for all the projects (except of course Locus and Browsersim Standalone, which would use maven.deploy.skip=false) ? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21012) Why do we deploy JBT components to Nexus snapshots repo?

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21012?page=com.atlassian.jira.plugi... ] Mickael Istria edited comment on JBIDE-21012 at 10/26/15 11:37 AM: ------------------------------------------------------------------- The issue noticed by [~nickboldt] about empty folders on Nexus is a relatively new one. I'm positive on the fact that when the profile was introduced, the zips were attached on Nexus, and the sites were available. Maybe something changed in our conventions or in Tycho to explain the new behaviour. In any case, as I mentioned above, as long as we keep same Maven version in pom.xml for a year, and for both branch and master, we cannot rely on Nexus for our builds/publishing of snapshot component sites. was (Author: mickael_istria): The issue noticed by [~nickboldt] about empty folders on Nexus is a relatively new one. I'm positive on the fact that when the profile was introduced, the zips were attached on Nexus, and the sites were available. Maybe something changed in our conventions or in Tycho to explain the new behaviour. In any case, as I mentioned above, as long as we keep same Maven version in pom.xml for a year, and for both branch and master, we cannot rely on Nexus for our builds. > Why do we deploy JBT components to Nexus snapshots repo? > -------------------------------------------------------- > > Key: JBIDE-21012 > URL: https://issues.jboss.org/browse/JBIDE-21012 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, updatesite > Affects Versions: 4.3.0.Final, 4.4.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.3.1.Beta1, 4.4.0.Alpha1 > > > Currently, we deploy our x.y.z-SNAPSHOT update sites to the JBoss Nexus snapshots repo. > But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just: > * eat disk space in Nexus > * consume time/resources in Jenkins > Since we have the custom profile deploy-to-jboss.org in place for all our artifacts, why don't we set *maven.deploy.skip=true* in the parent pom for all the projects (except of course Locus and Browsersim Standalone, which would use maven.deploy.skip=false) ? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21012) Why do we deploy JBT components to Nexus snapshots repo?

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21012?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-21012: ---------------------------------------- The issue noticed by [~nickboldt] about empty folders on Nexus is a relatively new one. I'm positive on the fact that when the profile was introduced, the zips were attached on Nexus, and the sites were available. Maybe something changed in our conventions or in Tycho to explain the new behaviour. In any case, as I mentioned above, as long as we keep same Maven version in pom.xml for a year, and for both branch and master, we cannot rely on Nexus for our builds. > Why do we deploy JBT components to Nexus snapshots repo? > -------------------------------------------------------- > > Key: JBIDE-21012 > URL: https://issues.jboss.org/browse/JBIDE-21012 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, updatesite > Affects Versions: 4.3.0.Final, 4.4.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.3.1.Beta1, 4.4.0.Alpha1 > > > Currently, we deploy our x.y.z-SNAPSHOT update sites to the JBoss Nexus snapshots repo. > But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just: > * eat disk space in Nexus > * consume time/resources in Jenkins > Since we have the custom profile deploy-to-jboss.org in place for all our artifacts, why don't we set *maven.deploy.skip=true* in the parent pom for all the projects (except of course Locus and Browsersim Standalone, which would use maven.deploy.skip=false) ? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

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