December 2014 - jbosstools-issues

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

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-3208?page=com.atlassian.jira.plugin.... ] Nick Boldt updated JBDS-3208: ----------------------------- Comment: was deleted (was: Max: You've said repeatedly that you want *nightly* (or *snapshots*, if people approve my/Mickael's renaming scheme above) to be a composite. You've also said the reason for this is so that nightly builds don't disappear while new ones are being published to the same URL [as happens for /nightly/core/4.2.luna and /nightly/core/master/). This rationale makes sense. The secondary issue of providing a stable URL for nightly builds which can point to either master or the 4.2.x branch [the step we forgot to do after we branched for jbosstools-4.2.x] has nothing to do with a reorg/refactoring of the URLs above. We still need that symlink, and we need to remember to move it to point to the correct content after we branch for 4.N.x every year. ) > reorg/refactor 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] (JBDS-3208) reorg/refactor directories for consistency across JBT/JBDS

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-3208?page=com.atlassian.jira.plugin.... ] Nick Boldt updated JBDS-3208: ----------------------------- Comment: was deleted (was: See https://issues.jboss.org/browse/JBDS-3163?focusedCommentId=13021099&page=... for more suggestions for new structure (cc: [~mickael_istria] )) > reorg/refactor 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] (JBDS-3208) reorg/refactor 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: ---------------------------------- Max: You've said repeatedly that you want *nightly* (or *snapshots*, if people approve my/Mickael's renaming scheme above) to be a composite. You've also said the reason for this is so that nightly builds don't disappear while new ones are being published to the same URL [as happens for /nightly/core/4.2.luna and /nightly/core/master/). This rationale makes sense. The secondary issue of providing a stable URL for nightly builds which can point to either master or the 4.2.x branch [the step we forgot to do after we branched for jbosstools-4.2.x] has nothing to do with a reorg/refactoring of the URLs above. We still need that symlink, and we need to remember to move it to point to the correct content after we branch for 4.N.x every year. > reorg/refactor 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-18855) Update Birt versions to 4.4.1 from 4.4.0 in the JBT unified TP

by Paul Leacu (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18855?page=com.atlassian.jira.plugi... ] Paul Leacu updated JBIDE-18855: ------------------------------- Assignee: Nick Boldt > Update Birt versions to 4.4.1 from 4.4.0 in the JBT unified TP > -------------------------------------------------------------- > > Key: JBIDE-18855 > URL: https://issues.jboss.org/browse/JBIDE-18855 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: target-platform > Reporter: Paul Leacu > Assignee: Nick Boldt > > *Reason:* You pull an updated version of Luna SR1a for use in your 4.41.x target platform, but still include the old BIRT 4.4.0 when there's a 4.4.1 version here? http://download.jboss.org/jbosstools/updates/requirements/luna/2014092610... > *Project page/sources:* ... > *Version:* 4.41.1.CR1 > *License and owner:* JBoss > *Original p2 repo:* http://third-party-vendor.com/path/to/updates-site/ > *JBoss mirror:* http://downloads.jboss.org/jbosstools/updates/requirements/<projectName> > *Include Sources:* No > *Affected projects:* JBTIS TP > *Include in JBDS:* Yes > *Type of dependency:* distribution > *List of bundles added/removed:* > {code} > suggested diff on the .target files > {code} > These features: > <unit id="org.eclipse.birt.feature.group" version="4.4.0.v201405191524-DPEp7FGixAot6DLz0hXcUqaHoLSX"/> > <unit id="org.eclipse.birt.chart.feature.group" version="4.4.0.v201405191524-829A4FQCnvK65Q9sKwwG"/> > <unit id="org.eclipse.birt.integration.wtp.feature.group" version="4.4.0.v20140521-1030-53-7w3125163202141"/> > <unit id="org.eclipse.birt.chart.integration.wtp.feature.group" version="4.4.0.v20140521-1030-53-7w3125163202141"/> > Should pick up the 4.4.1... versions as seen here: > http://download.jboss.org/jbosstools/updates/requirements/luna/2014092610... -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18855) Update Birt versions to 4.4.1 from 4.4.0 in the JBT unified TP

by Paul Leacu (JIRA)

Paul Leacu created JBIDE-18855: ---------------------------------- Summary: Update Birt versions to 4.4.1 from 4.4.0 in the JBT unified TP Key: JBIDE-18855 URL: https://issues.jboss.org/browse/JBIDE-18855 Project: Tools (JBoss Tools) Issue Type: Bug Components: target-platform Reporter: Paul Leacu *Reason:* You pull an updated version of Luna SR1a for use in your 4.41.x target platform, but still include the old BIRT 4.4.0 when there's a 4.4.1 version here? http://download.jboss.org/jbosstools/updates/requirements/luna/2014092610... *Project page/sources:* ... *Version:* 4.41.1.CR1 *License and owner:* JBoss *Original p2 repo:* http://third-party-vendor.com/path/to/updates-site/ *JBoss mirror:* http://downloads.jboss.org/jbosstools/updates/requirements/<projectName> *Include Sources:* No *Affected projects:* JBTIS TP *Include in JBDS:* Yes *Type of dependency:* distribution *List of bundles added/removed:* {code} suggested diff on the .target files {code} These features: <unit id="org.eclipse.birt.feature.group" version="4.4.0.v201405191524-DPEp7FGixAot6DLz0hXcUqaHoLSX"/> <unit id="org.eclipse.birt.chart.feature.group" version="4.4.0.v201405191524-829A4FQCnvK65Q9sKwwG"/> <unit id="org.eclipse.birt.integration.wtp.feature.group" version="4.4.0.v20140521-1030-53-7w3125163202141"/> <unit id="org.eclipse.birt.chart.integration.wtp.feature.group" version="4.4.0.v20140521-1030-53-7w3125163202141"/> Should pick up the 4.4.1... versions as seen here: http://download.jboss.org/jbosstools/updates/requirements/luna/2014092610... -- 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 Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18837?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-18837: --------------------------------------------- I definitely would prefer the version gets to be independent of parent pom and i'm not fully grokking how you suggest to do it using base root pom version thus a PR would be helpful for sure. Aside: Its not new QE (or others) use nightlies and it is also not new that in *very* special cases QE need to rely on -D to test specific setups - we have done that all former releases. I don't think there would ever be need to differentiate between latest nightly for 4.2.x and latest staged for 4.2.x - that would be extreme exceptional cases and in all this it would still require using exact timestamps in ide-properties to differentiate. And yes, there aren't an awesome silver bullet for this - I wish there were; but so far I think by decoupling from parent pom and try testing our way out of detecting if the version is properly bumped we have a solution that are not bullet proof (You can break the situation if you really are clever in install sequence of things) but that are Good Enough without being too rigid. > 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: Enhancement > 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

[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 Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18837?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen edited comment on JBIDE-18837 at 12/1/14 3:44 PM: ---------------------------------------------------------------------- I definitely would prefer the version gets to be independent of parent pom and i'm not fully grokking how you suggest to do it using base root pom version thus a PR would be helpful for sure. Aside: Its not new QE (or others) use nightlies and it is also not new that in *very* special cases QE need to rely on -D to test specific setups - we have done that all former releases when non-staged yet testing had to be done (by QE or dev). I don't think there would ever be need to differentiate between latest nightly for 4.2.x and latest staged for 4.2.x - that would be extreme exceptional cases and in all this it would still require using exact timestamps in ide-properties to differentiate. And yes, there aren't an awesome silver bullet for this - I wish there were; but so far I think by decoupling from parent pom and try testing our way out of detecting if the version is properly bumped we have a solution that are not bullet proof (You can break the situation if you really are clever in install sequence of things) but that are Good Enough without being too rigid. was (Author: maxandersen): I definitely would prefer the version gets to be independent of parent pom and i'm not fully grokking how you suggest to do it using base root pom version thus a PR would be helpful for sure. Aside: Its not new QE (or others) use nightlies and it is also not new that in *very* special cases QE need to rely on -D to test specific setups - we have done that all former releases. I don't think there would ever be need to differentiate between latest nightly for 4.2.x and latest staged for 4.2.x - that would be extreme exceptional cases and in all this it would still require using exact timestamps in ide-properties to differentiate. And yes, there aren't an awesome silver bullet for this - I wish there were; but so far I think by decoupling from parent pom and try testing our way out of detecting if the version is properly bumped we have a solution that are not bullet proof (You can break the situation if you really are clever in install sequence of things) but that are Good Enough without being too rigid. > 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: Enhancement > 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

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

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBDS-3208?page=com.atlassian.jira.plugin.... ] Max Rydahl Andersen commented on JBDS-3208: ------------------------------------------- To be clear - the requirement is not necessarily that it is a composite of multiple nightly builds; it is just the simplest way I know of providing a *stable* url for the release train that does not change just because our branch name changes. i.e. /luna/nightly vs first its called luna/master then /luna/4.2.x And no, this does not mean I think master and 4.2.x are bad names for internal sanity - but the url we make public for nightly and/or snapshot testing makes sense to follow similar layout as our staging, development and stable sites for two reasons: A) so users/testers/developers don't need to changed URL's in their test eclipse installs B) the sites we test/build are as close to the real published content. > reorg/refactor 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-18681) 'Invalid thread access' error in central during shutdown

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18681?page=com.atlassian.jira.plugi... ] Denis Golovin closed JBIDE-18681. --------------------------------- Applied fix still could have the same problems with lower probability, so it is really impossible to replicate manually now. I personally would just removed code from stop method, because the only scenario when it called is closing or restarting eclipse, manual stopping is not the case for regular eclipse usage. One more option would be register workbench listener http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.... and that would work always. Anyway closing it for now, because I am not able to replicate it manually anymore. > 'Invalid thread access' error in central during shutdown > -------------------------------------------------------- > > Key: JBIDE-18681 > URL: https://issues.jboss.org/browse/JBIDE-18681 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: central > Affects Versions: 4.2.0.Final > Reporter: Denis Golovin > Assignee: Snjezana Peco > Labels: need-info > Fix For: 4.2.1.CR1, 4.3.0.Alpha1 > > > {code}Caused by: org.eclipse.swt.SWTException: Invalid thread access > at org.eclipse.swt.SWT.error(SWT.java:4441) > at org.eclipse.swt.SWT.error(SWT.java:4356) > at org.eclipse.swt.SWT.error(SWT.java:4327) > at org.eclipse.swt.widgets.Display.error(Display.java:1083) > at org.eclipse.swt.widgets.Display.createDisplay(Display.java:840) > at org.eclipse.swt.widgets.Display.create(Display.java:823) > at org.eclipse.swt.graphics.Device.<init>(Device.java:130) > at org.eclipse.swt.widgets.Display.<init>(Display.java:714) > at org.eclipse.swt.widgets.Display.<init>(Display.java:705) > at org.eclipse.swt.widgets.Display.getDefault(Display.java:1403) > at org.jboss.tools.central.JBossCentralActivator.stop(JBossCentralActivator.java:215) > at org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:827) > at org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:1) > at java.security.AccessController.doPrivileged(Native Method) > at org.eclipse.osgi.internal.framework.BundleContextImpl.stop(BundleContextImpl.java:820) > ... 13 more{code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

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

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-3208?page=com.atlassian.jira.plugin.... ] Nick Boldt updated JBDS-3208: ----------------------------- Summary: reorg/refactor directories for consistency across JBT/JBDS (was: reorg directories for consistency across JBT/JBDS) > reorg/refactor 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues December 2014