October 2013 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-15619) Verify EAP 6.2 ER4 works without error

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15619?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-15619: ------------------------------------- Must add tests to verify an eap6.3 or 6.4, work. This will ensure the recent patch doesn't mean we're only testing exactly what was fixed, but a future scenario. . > Verify EAP 6.2 ER4 works without error > --------------------------------------- > > Key: JBIDE-15619 > URL: https://issues.jboss.org/browse/JBIDE-15619 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: server > Affects Versions: 4.2.0.Alpha1 > Reporter: Rob Stryker > Assignee: Rob Stryker > Fix For: 4.2.0.Alpha1 > > > Do a smoke-test on all aspects of EAP6.2 ER4, including startup, shutdown, management, deployment, pollers, etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-186) ModeShape sometimes doesn't publish all models of Teiid VDB

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTIS-186?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated JBTIS-186: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1017684 > ModeShape sometimes doesn't publish all models of Teiid VDB > ----------------------------------------------------------- > > Key: JBTIS-186 > URL: https://issues.jboss.org/browse/JBTIS-186 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: modeshape > Affects Versions: 4.1.3 > Environment: Ubuntu 12.04, JBTIS 4.1.3.Beta4, DV 6.0.0.ER2, sun jdk 1.6 > Reporter: Lucie Fabrikova > > If I publish a teiid VDB with relational models .xmi in given environment, sometimes some (or all) of the models are not published. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-186) ModeShape sometimes doesn't publish all models of Teiid VDB

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTIS-186?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTIS-186: ----------------------------------------------- Lucie Fabrikova <lfabriko(a)redhat.com> made a comment on [bug 1017684|https://bugzilla.redhat.com/show_bug.cgi?id=1017684] Description of problem: If I publish a teiid VDB with relational models .xmi in given environment, sometimes some (or all) of the models are not published. Version-Release number of selected component (if applicable): ModeShape Client 3.4.0.Final How reproducible: Steps to Reproduce: 1. Create Modeshape server (localhost:8080/modeshape-rest, admin/admin) 2. Deploy a VDB with some .xmi models to some publish area on the modeshape server 3. Access the VDB via connection profile (jdbc:teiid:ModeShape@mm://localhost:31000) 4. Execute SQL query SELECT * FROM ModeShape.xmi_model Actual results: Sometimes the result of query doesn't contain reference to all .xmi models of VDB Expected results: Additional info: > ModeShape sometimes doesn't publish all models of Teiid VDB > ----------------------------------------------------------- > > Key: JBTIS-186 > URL: https://issues.jboss.org/browse/JBTIS-186 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: modeshape > Affects Versions: 4.1.3 > Environment: Ubuntu 12.04, JBTIS 4.1.3.Beta4, DV 6.0.0.ER2, sun jdk 1.6 > Reporter: Lucie Fabrikova > > If I publish a teiid VDB with relational models .xmi in given environment, sometimes some (or all) of the models are not published. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15619) Verify EAP 6.2 ER4 works without error

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15619?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-15619: ------------------------------------- For master and maintenance, as far as I can tell, eap6.2 er4 works without error now. For released tools, EAP6.2 ER4 will work fine if created from the new server wizard, using the eap6.1 server type. However, it will NOT work properly when using runtime detection, as the runtime detection will get the version wrong (6.0) and then try to create an eap6.0 server type to represent it. It will then obviously fail because of the filesystem layout changes between eap6.0 and eap6.1. There's nothing we can do here to fix it except advise users to upgrade to maintenance, or, to create their server via the new server wizard instead of the runtime detection. > Verify EAP 6.2 ER4 works without error > --------------------------------------- > > Key: JBIDE-15619 > URL: https://issues.jboss.org/browse/JBIDE-15619 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: server > Affects Versions: 4.2.0.Alpha1 > Reporter: Rob Stryker > Assignee: Rob Stryker > Fix For: 4.2.0.Alpha1 > > > Do a smoke-test on all aspects of EAP6.2 ER4, including startup, shutdown, management, deployment, pollers, etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15647) Compile errors when building arquillian with Luna target platform

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15647?page=com.atlassian.jira.plugi... ] Snjezana Peco commented on JBIDE-15647: --------------------------------------- Arquillian uses a special classloader in order to avoid a Windows file lock issue. The classloader uses a bundle's classloader. It wouldn't be easy to change that behaviour. In my opinion, the fix is simple: org.eclipse.osgi.framework.adaptor.BundleClassLoader is renamed to org.eclipse.osgi.internal.loader.ModuleClassLoader. If we would want to use the same code for Kepler and Luna, we would have to remove internal API which would be difficult to do because other parts of JBT also use it. > Compile errors when building arquillian with Luna target platform > ----------------------------------------------------------------- > > Key: JBIDE-15647 > URL: https://issues.jboss.org/browse/JBIDE-15647 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: testing-tools > Affects Versions: 4.2.x > Reporter: Snjezana Peco > Assignee: Snjezana Peco > > When building the arquillian component with Luna TP(tpc.version=4.40.0.Alpha1-SNAPSHOT) there are the following compile errors: > {code} > [ERROR] import org.eclipse.osgi.framework.adaptor.BundleClassLoader; > [ERROR] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > [ERROR] The import org.eclipse.osgi.framework.adaptor cannot be resolved > [ERROR] > ... > [ERROR] || tmp instanceof BundleClassLoader) > [ERROR] ^^^^^^^^^^^^^^^^^ > [ERROR] BundleClassLoader cannot be resolved to a type > {code} > The errors are caused by the change of OSGi internals. > The org.eclipse.osgi.framework.adaptor package and the BundleClassloader class have been removed from Luna. > The changes aren't compatible with the previous Eclipse versions, so we need a separate branch for Luna. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15614) Rename EAP 6.1 server type to 6.1+, ensure runtime detection is accurate

by Martin Malina (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15614?page=com.atlassian.jira.plugi... ] Martin Malina commented on JBIDE-15614: --------------------------------------- {quote} Other news about eap6.2: Everything else seems to work fine. Startup, shutdown, jmx, and others. {quote} Yeah, I checked that too. Note that there is ER5 now. But that shouldn't make any difference - I will check today. > Rename EAP 6.1 server type to 6.1+, ensure runtime detection is accurate > ------------------------------------------------------------------------ > > Key: JBIDE-15614 > URL: https://issues.jboss.org/browse/JBIDE-15614 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: runtime-detection, server > Affects Versions: 4.1.0.Final > Environment: JBDS 7.0.0.GA > Reporter: Martin Malina > Assignee: Max Rydahl Andersen > Fix For: 4.1.1.Beta1 > > > 1. When you try to add EAP 6.2 using runtime detection, it detects it as EAP 6.0. > 2. When trying to add EAP 6.2 manually, there is no type EAP 6.2 > Let me know if you want subtasks for these two. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15614) Rename EAP 6.1 server type to 6.1+, ensure runtime detection is accurate

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15614?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-15614: ------------------------------------- Some more details on what went wrong here: ServerBeanLoader.loadBeanInternal incorrectly call deprecated method getServerVersion(fullVersion). It should instead use getMajorMinorVersion, which is fairly new method. The deprecated method getServerVersion had unclear semantics and was not useful in any way. In this specific case, the eap6.2 folder was recognized as an eap6.1 "type", and it's full version was recongized as 6.2, which is correct. However, the server bean was instantiated with a version of 6.0, due to the badly performing getServerVersion method who's job it was to take the full version string and turn it into a more compact form. By using the newer method getMajorMinorVersion, the entire issue is fixed. Looking over this code, JBossServerType.getVersions() can also be deprecated, as there are no other clients using the method, and it would simplify the construction process drastically and require fewer updates. Other news about eap6.2: Everything else seems to work fine. Startup, shutdown, jmx, and others. > Rename EAP 6.1 server type to 6.1+, ensure runtime detection is accurate > ------------------------------------------------------------------------ > > Key: JBIDE-15614 > URL: https://issues.jboss.org/browse/JBIDE-15614 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: runtime-detection, server > Affects Versions: 4.1.0.Final > Environment: JBDS 7.0.0.GA > Reporter: Martin Malina > Assignee: Max Rydahl Andersen > Fix For: 4.1.1.Beta1 > > > 1. When you try to add EAP 6.2 using runtime detection, it detects it as EAP 6.0. > 2. When trying to add EAP 6.2 manually, there is no type EAP 6.2 > Let me know if you want subtasks for these two. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15482) Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files

by Martin Malina (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15482?page=com.atlassian.jira.plugi... ] Martin Malina commented on JBIDE-15482: --------------------------------------- [~nickboldt] so to reiterate, {quote} Thus instead of builds/staging/RedDeer_master/all/repo/ you would use builds/staging/CI/RedDeer_master/<some_timestamp_and_build_ID>/all/repo/ {quote} So there will be no static url pointing to the last build? No way to keep pointing to the latest unless you check the for last build url every time? We would really like to have a static url for the latest master. (Of course we could stay on the older version of publish.sh, but I don't think it will be maintained so it is bound to break eventually.) > Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-15482 > URL: https://issues.jboss.org/browse/JBIDE-15482 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build, updatesite > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.1.1.Alpha2 > > > Be it proposed: > {quote} > that instead of an in-place move which reuses > generic folder names like "staging" and "staging.previous", we > composite build output using unique names like > 2013-08-09_05-05-26-B7222/ or 2013-08-13_10-05-28-B7255 > {quote} > We therefore need: > a) to regenerate the composite site each time there's a new build > published, in order to remove the oldest and add the newest (keeping > only the Nth and N-1rst builds) > (I have a script that might already work for this, or would need > tweaking.) > b) heuristics to determine when an older (N-2, N-3, ... N-z) build is > no longer needed, perhaps simply by assuming no one needs it after > 24hrs? > 24 hours should be more that enough. > c) a cleanup script which can purge all but the builds which are no > more than 1 day old, keeping at all times at least two builds (N and > N-1) > (I have a script that already does this for folders like > http://download.jboss.org/jbosstools/builds/nightly/core/trunk/ but > might need to be tweaked to work for a new pattern of > staging/\$\{JOB_NAME}/<BUILD_ID>/ .) > {quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15649) Compilation Errors While Building Forge Component Against Luna Target Platform

by Koen Aers (JIRA)

Koen Aers created JBIDE-15649: --------------------------------- Summary: Compilation Errors While Building Forge Component Against Luna Target Platform Key: JBIDE-15649 URL: https://issues.jboss.org/browse/JBIDE-15649 Project: Tools (JBoss Tools) Issue Type: Task Components: forge Reporter: Koen Aers Assignee: Koen Aers The build stops after the failed compilation of org.jboss.tools.forge.core which gives the following error: [ERROR] super(launch, process, name, attributes); [ERROR] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [ERROR] The constructor RuntimeProcess(ILaunch, Process, String, Map<Object,Object>) is undefined -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15482) Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15482?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-15482: --------------------------------------------- so put a permanent file for the new approach and you can still decipher and no need for changing url/locations. > Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-15482 > URL: https://issues.jboss.org/browse/JBIDE-15482 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build, updatesite > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.1.1.Alpha2 > > > Be it proposed: > {quote} > that instead of an in-place move which reuses > generic folder names like "staging" and "staging.previous", we > composite build output using unique names like > 2013-08-09_05-05-26-B7222/ or 2013-08-13_10-05-28-B7255 > {quote} > We therefore need: > a) to regenerate the composite site each time there's a new build > published, in order to remove the oldest and add the newest (keeping > only the Nth and N-1rst builds) > (I have a script that might already work for this, or would need > tweaking.) > b) heuristics to determine when an older (N-2, N-3, ... N-z) build is > no longer needed, perhaps simply by assuming no one needs it after > 24hrs? > 24 hours should be more that enough. > c) a cleanup script which can purge all but the builds which are no > more than 1 day old, keeping at all times at least two builds (N and > N-1) > (I have a script that already does this for folders like > http://download.jboss.org/jbosstools/builds/nightly/core/trunk/ but > might need to be tweaked to work for a new pattern of > staging/\$\{JOB_NAME}/<BUILD_ID>/ .) > {quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 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 2013