November 2014 - jbosstools-issues

[JBoss JIRA] (JBDS-3208) reorg directories for consistency across JBT/JBDS

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-3208?page=com.atlassian.jira.plugin.... ] Nick Boldt commented on JBDS-3208: ---------------------------------- Based on side conversation w/ Max re: JBIDE-18833: To provide an update site that is a *composite of multiple nightly builds*, updates/\*/snapshots/ must in fact be a *symlink* to builds/\*/snapshots/ (or builds/<jobname>/) so that the N latest builds can be accessed from a single URL. And we'll have to ensure that the cleanup script [1] is amended to perform deletes in these new folders, too. [1] http://hudson.qa.jboss.com/hudson/job/jbosstools-cleanup/ > reorg directories for consistency across JBT/JBDS > ------------------------------------------------- > > Key: JBDS-3208 > URL: https://issues.jboss.org/browse/JBDS-3208 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: build > Affects Versions: 9.0.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 9.0.0.Alpha1 > > > Be it resolved - we should reorg directories for consistency across JBT/JBDS: > {code} > download.jboss.org > <earlyaccess,updates,discovery>/mars > /snapshots [replace nightly] > /staging [rename content for QE, moves to development when approved] > /development > /stable (updates/mars/stable is a pointer back into updates/mars) > drop /integration (not used) > builds/<jobname>/<buildid> > builds/<jobname>/composite*.xml for last 2 builds > targetplatforms/<type>/<version> > {code} > and > {code} > devstudio.redhat.com > <earlyaccess,updates,discovery>/9.0 > /snapshots > /staging > /development > /stable (updates/9.0/stable is a pointer back into updates/9.0) > builds/<jobname>/<buildid> > builds/<jobname>/composite*.xml for last 2 builds > targetplatforms/<type>/<version> > {code} > Further discussion in http://ether-man.rhcloud.com/p/build.next.20141112 > This would remove the idea of the composite staging site [1] and the composite install job [2], today used to determine when it's time to run the aggregate builds, in favour of a new p2diff mechanism for determining if aggregates should be published. See JBIDE-18742 and JBIDE-16970. > [1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.2.... > [2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18847) Extract discovery code out of project examples

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18847?page=com.atlassian.jira.plugi... ] Fred Bricon updated JBIDE-18847: -------------------------------- Description: Discovery code used by central (to install software) and project-examples (to discover proxy-wizards) lives in project examples. Because of that dependency, project examples also contain API that configures central content. That forces com.jboss.devstudio.core.central to depend on project examples, just to configure central contents. This sucks big time and that common discovery code should be extracted to another component, consumed by both central and examples. The central configuration API should move back to central. was: Discovery code used by central (to install software) and project-examples (to discover proxy-wizards) lives in project examples. Because of that dependency, project examples also contain API that configures central content. That forces com.jboss.devstudio.core.central to depends on project examples, just to configure central contents. This sucks big time and that common discovery code should be extracted to another component, consumed by both central and examples. The central configuration API should move back to central. > Extract discovery code out of project examples > ---------------------------------------------- > > Key: JBIDE-18847 > URL: https://issues.jboss.org/browse/JBIDE-18847 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: project-examples > Affects Versions: 4.2.0.Final > Reporter: Fred Bricon > Assignee: Fred Bricon > Fix For: 4.3.0.Alpha1 > > > Discovery code used by central (to install software) and project-examples (to discover proxy-wizards) lives in project examples. Because of that dependency, project examples also contain API that configures central content. That forces com.jboss.devstudio.core.central to depend on project examples, just to configure central contents. > This sucks big time and that common discovery code should be extracted to another component, consumed by both central and examples. The central configuration API should move back to central. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18847) Extract discovery code out of project examples

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18847?page=com.atlassian.jira.plugi... ] Fred Bricon updated JBIDE-18847: -------------------------------- Description: Discovery code used by central (to install software) and project-examples (to discover proxy-wizards) lives in project examples. Because of that dependency, project examples also contain API that configures central content. That forces com.jboss.devstudio.core.central to depends on project examples, just to configure central contents. This sucks big time and that common discovery code should be extracted to another component, consumed by both central and examples. The central configuration API should move back to central. was: Discovery code used by central (to install software) and project-examples (to discover proxy-wizards) lives in project examples. Because of that dependency, project examples also contain API that configures central content. This sucks big time and that common discovery code should be extracted to another component, consumed by both central and examples. The central configuration API should move back to central > Extract discovery code out of project examples > ---------------------------------------------- > > Key: JBIDE-18847 > URL: https://issues.jboss.org/browse/JBIDE-18847 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: project-examples > Affects Versions: 4.2.0.Final > Reporter: Fred Bricon > Assignee: Fred Bricon > Fix For: 4.3.0.Alpha1 > > > Discovery code used by central (to install software) and project-examples (to discover proxy-wizards) lives in project examples. Because of that dependency, project examples also contain API that configures central content. That forces com.jboss.devstudio.core.central to depends on project examples, just to configure central contents. > This sucks big time and that common discovery code should be extracted to another component, consumed by both central and examples. The central configuration API should move back to central. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16992) filters in arquillian editor is case sensitive and start of string

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16992?page=com.atlassian.jira.plugi... ] Snjezana Peco updated JBIDE-16992: ---------------------------------- Fix Version/s: 4.3.0.Alpha1 (was: 4.3.x) > filters in arquillian editor is case sensitive and start of string > ------------------------------------------------------------------ > > Key: JBIDE-16992 > URL: https://issues.jboss.org/browse/JBIDE-16992 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: testing-tools, upstream > Reporter: Max Rydahl Andersen > Assignee: Snjezana Peco > Fix For: 4.3.0.Alpha1 > > > EXECUTE: open qualifier list and type "remote" > ASSERT: qualifiers containing the string remote should show up > currently it does not - I have to type WILDFLY_REMOTE. > it should be a case insensitive in string search instead of case sensitive beginning of string search. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18847) Extract discovery code out of project examples

by Fred Bricon (JIRA)

Fred Bricon created JBIDE-18847: ----------------------------------- Summary: Extract discovery code out of project examples Key: JBIDE-18847 URL: https://issues.jboss.org/browse/JBIDE-18847 Project: Tools (JBoss Tools) Issue Type: Sub-task Components: project-examples Affects Versions: 4.2.0.Final Reporter: Fred Bricon Discovery code used by central (to install software) and project-examples (to discover proxy-wizards) lives in project examples. Because of that dependency, project examples also contain API that configures central content. This sucks big time and that common discovery code should be extracted to another component, consumed by both central and examples. The central configuration API should move back to central -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18847) Extract discovery code out of project examples

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18847?page=com.atlassian.jira.plugi... ] Fred Bricon reassigned JBIDE-18847: ----------------------------------- Assignee: Fred Bricon > Extract discovery code out of project examples > ---------------------------------------------- > > Key: JBIDE-18847 > URL: https://issues.jboss.org/browse/JBIDE-18847 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: project-examples > Affects Versions: 4.2.0.Final > Reporter: Fred Bricon > Assignee: Fred Bricon > Fix For: 4.3.0.Alpha1 > > > Discovery code used by central (to install software) and project-examples (to discover proxy-wizards) lives in project examples. Because of that dependency, project examples also contain API that configures central content. > This sucks big time and that common discovery code should be extracted to another component, consumed by both central and examples. The central configuration API should move back to central -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16992) filters in arquillian editor is case sensitive and start of string

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16992?page=com.atlassian.jira.plugi... ] Snjezana Peco updated JBIDE-16992: ---------------------------------- Fix Version/s: (was: 4.2.1.Final) > filters in arquillian editor is case sensitive and start of string > ------------------------------------------------------------------ > > Key: JBIDE-16992 > URL: https://issues.jboss.org/browse/JBIDE-16992 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: testing-tools, upstream > Reporter: Max Rydahl Andersen > Assignee: Snjezana Peco > Fix For: 4.3.x > > > EXECUTE: open qualifier list and type "remote" > ASSERT: qualifiers containing the string remote should show up > currently it does not - I have to type WILDFLY_REMOTE. > it should be a case insensitive in string search instead of case sensitive beginning of string search. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-14782) Add ShrinkWrap Archive file location validation

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-14782?page=com.atlassian.jira.plugi... ] Snjezana Peco updated JBIDE-14782: ---------------------------------- Fix Version/s: (was: 4.2.1.Final) > Add ShrinkWrap Archive file location validation > ----------------------------------------------- > > Key: JBIDE-14782 > URL: https://issues.jboss.org/browse/JBIDE-14782 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: testing-tools > Reporter: Aslak Knutsen > Assignee: Snjezana Peco > Labels: new_and_noteworthy > Fix For: 4.3.0.Alpha1 > > > *Given* > A Deployment method > *When* > {code} > war.addAsManifestResource(X, "beans.xml") > ear.addAsManifestResource(X, "beans.xml") > war.addAsManifestResource(X, "persistence.xml") > {code} > *Then* > Warn that known EE descriptor files are in the wrong location > Some mapping on top of my head: > WebArchive > {code} > web.xml -> /WEB-INF/ > web-fragment.xml -> Not supported ? > beans.xml -> /WEB-INF/ > persistence.xml -> /WEB-INF/classes/META-INF/ > ejb-jar.xml -> /WEB-INF/classes/META-INF/ > {code} > JavaArchive > {code} > web.xml -> Not supported > web-fragment.xml -> /META-INF/ > beans.xml -> /META-INF/ > persistence.xml -> /META-INF/ > ejb-jar.xml -> /META-INF/ > {code} > EnterpriseArchive > {code} > beans.xml -> Not supported > persistence.xml -> Not supported > ejb-jar.xml -> Not supported > application.xml -> /META-INF/ > {code} > One common mistake is using addAsManifestResource on WebArchives. A quickfix / suggestion would be to use addAsWebInfResource for the files located in /WEB-INF/ -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3199) Creating a new HTML5 "from scratch" retains "kitchensink" string in datasources instead of picking up actual project names

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBDS-3199?page=com.atlassian.jira.plugin.... ] Fred Bricon commented on JBDS-3199: ----------------------------------- [~rafabene], [~manaRH] : which of you guys should we nag? :-) > Creating a new HTML5 "from scratch" retains "kitchensink" string in datasources instead of picking up actual project names > -------------------------------------------------------------------------------------------------------------------------- > > Key: JBDS-3199 > URL: https://issues.jboss.org/browse/JBDS-3199 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: central, upstream > Affects Versions: 8.0.0.GA > Reporter: Len DiMaggio > Assignee: Fred Bricon > > These "kitchensink" strings are retained: > grep -ir kitchen * > main/resources/META-INF/persistence.xml: <jta-data-source>java:jboss/datasources/KitchensinkHTML5MobileQuickstartDS</jta-data-source> > main/webapp/WEB-INF/kitchensink-quickstart-ds.xml: <datasource jndi-name="java:jboss/datasources/KitchensinkHTML5MobileQuickstartDS" > main/webapp/WEB-INF/kitchensink-quickstart-ds.xml: pool-name="kitchensink-quickstart" enabled="true" > test/resources/arquillian-ds.xml: <datasource jndi-name="java:jboss/datasources/KitchensinkHTML5MobileTestDS" > test/resources/META-INF/test-persistence.xml: <jta-data-source>java:jboss/datasources/KitchensinkHTML5MobileTestDS</jta-data-source> -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18837) because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18837?page=com.atlassian.jira.plugi... ] Fred Bricon edited comment on JBIDE-18837 at 11/27/14 4:40 PM: --------------------------------------------------------------- So after a chat with Max we agreed that : - micro version lock was not necessary - moving the version string to a different plugin than foundation is not practical - we need to enforce foundation dependency at the minor level (X.Y), in all plugins consuming foundation, i.e. central and examples for now. - all micro releases should use the same config in ide-config.properties, i.e. once the first GA is released, we should always find key|context|X.Y properties - we need to create tests that would run daily and that check that : ** there are no unused keys in ide-config.properties (to catch typos) ** all urls defined there are live was (Author: fbricon): So after a chat with Max we agreed that : - micro version lock was not necessary - moving the version string to a different plugin than foundation is not practical - we need to enforce foundation dependency at the minor level (X.Y), in all plugins consuming foundation, i.e. central and examples for now. - all micro releases should use the same config in ide-config.properties, i.e. once the first GA is released, we should always find key|context|X.Y properties - we need to create tests that would run daily and that check that : * there are no unused keys in ide-config.properties (to catch typos) * all urls defined there are live > because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated > ------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-18837 > URL: https://issues.jboss.org/browse/JBIDE-18837 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, central, common/jst/core, project-examples > Affects Versions: 4.2.1.CR1 > Reporter: Nick Boldt > Fix For: 4.3.0.Alpha1 > > > When updating from 4.2.0 to 4.2.1, a user might decide to only update Central or Project Examples, and NOT update Foundation.core, which means his Eclipse will still think it's 4.2.0, not 4.2.1, and he might get the wrong version of central/examples. > Therefore we need manifest-level [4.2.1,) requirements on upstream foundation.core in examples and central, to force this lock-step updating. > And we need to use the maven enforcer plugin to fail the build if these versions get out of sync. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 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 November 2014