January 2015 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-15135) Attach metadata during assembly instead of publish time

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-15135: ------------------------------------ {quote}This is meant to go in the upstream block when upstream data is available{quote} When is it available? How is it made available? How do you test this offline? How does the mojo know about upstream projects, since none of the jobs are linked in Jenkins? {quote}Same reason, it's reporting the value of the property from Jenkins (or CLI).{quote} Why not also dump variables we know are important which are resolved from parent pom? Why only worry about CLI variables, not defaults too? (Consider what you see in the Help > About > Eclipse Config view -- it contains BOTH things set CLI / eclipse.ini and also defaults pulled from the OS/system. I think we should do that too.) Re: OS/JDK details... we should include those. It's way better to just collect it at publish time than to have to go dig up the information later if something fails which is slave config specific, or is an OS-related problem. Is it a lot of work to collect that information? Surely you can just grab the output of `uname -a;java -version` ? > Attach metadata during assembly instead of publish time > ------------------------------------------------------- > > Key: JBIDE-15135 > URL: https://issues.jboss.org/browse/JBIDE-15135 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build > Reporter: Mickael Istria > Assignee: Mickael Istria > Fix For: 4.2.x > > > In order to make it easier to deal with Nexus and to have an homogeneous way to access build metadata (commit id), it would be interesting to move creation of metadata at assembly time (same time as when we create index and so on), and put it directly into the site. > Then whether we use Nexus or a home-made publication, we are sure that we can access metadata whenever we can access the binaries. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-374) Unknown category 'org.jboss.tools.central.discovery.a.web' when installing from central

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBTIS-374?page=com.atlassian.jira.plugin.... ] Nick Boldt commented on JBTIS-374: ---------------------------------- Problem is that your directory.xml does not know where to find the JBDS Central plugin. It should contain THREE entries: * JBDS Central [missing] * JBDS Early Access [present] * JBDS IS (Early Access) [present] For example: https://devstudio.jboss.com/updates/8.0-staging/devstudio-directory.xml > Unknown category 'org.jboss.tools.central.discovery.a.web' when installing from central > --------------------------------------------------------------------------------------- > > Key: JBTIS-374 > URL: https://issues.jboss.org/browse/JBTIS-374 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Components: distribution > Affects Versions: 8.0.0.Beta2 > Environment: JBDS 8.0.1.GA + JBDS-IS 8.0.0.Beta2 > Reporter: Andrej Podhradsky > Assignee: Paul Leacu > Priority: Minor > > The following errors occur when we want to install JBDS-IS from JBoss Central > !ENTRY org.eclipse.mylyn.discovery.core 4 0 2014-12-16 08:23:00.010 > !MESSAGE Unknown category 'org.jboss.tools.central.discovery.a.web' referenced by connector 'angularjs-eclipse-feature' declared in com.jboss.jbds.central.discovery.earlyaccess_8.0.0.Final_v20141017_1053_B366.jar_8432436156156296317.jar > !ENTRY org.eclipse.mylyn.discovery.core 4 0 2014-12-16 08:23:00.023 > !MESSAGE Unknown category 'org.jboss.tools.central.discovery.a.web' referenced by connector 'org.jboss.tools.arquillian' declared in com.jboss.jbds.central.discovery.earlyaccess_8.0.0.Final_v20141017_1053_B366.jar_8432436156156296317.jar > This occurs only in error log and has no impact on the installation. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3304) [unit test] versionwatch should run against latest builds, not hardcoded older Betas

by CDW Engine (JIRA)

[ https://issues.jboss.org/browse/JBDS-3304?page=com.atlassian.jira.plugin.... ] CDW Engine updated JBDS-3304: ----------------------------- CDW docs_ack: ? CDW devel_ack: ? CDW pm_ack: + CDW qa_ack: ? CDW release: ? > [unit test] versionwatch should run against latest builds, not hardcoded older Betas > ------------------------------------------------------------------------------------ > > Key: JBDS-3304 > URL: https://issues.jboss.org/browse/JBDS-3304 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: build > Affects Versions: 8.0.1.GA > Reporter: Nick Boldt > Assignee: Nick Boldt > > versionwatch should run against latest builds, not hardcoded older Betas. > Need a way to pull the latest builds from /staging/ so that instead of testing hardcoded Beta2 builds we use the latest. > This might have broken as a result of a bug in install.jbds.sh - I thought this used to work: > {code} > ++ TMPDIR=/tmp > /mnt/hudson_workspace/workspace/devstudio.versionwatch_8.0.luna/sources/vwatch/install.jbds.sh: command substitution: line 151: unexpected EOF while looking for matching `"' > /mnt/hudson_workspace/workspace/devstudio.versionwatch_8.0.luna/sources/vwatch/install.jbds.sh: command substitution: line 152: syntax error: unexpected end of file > {code} > Either way, we need a better unit test here to ensure that the versions diffed are NOT just the list of hardcoded ones, but instead include the hardcoded list + at least one more (latest build). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3304) [unit test] versionwatch should run against latest builds, not hardcoded older Betas

by Nick Boldt (JIRA)

Nick Boldt created JBDS-3304: -------------------------------- Summary: [unit test] versionwatch should run against latest builds, not hardcoded older Betas Key: JBDS-3304 URL: https://issues.jboss.org/browse/JBDS-3304 Project: Developer Studio (JBoss Developer Studio) Issue Type: Bug Components: build Affects Versions: 8.0.1.GA Reporter: Nick Boldt Assignee: Nick Boldt versionwatch should run against latest builds, not hardcoded older Betas. Need a way to pull the latest builds from /staging/ so that instead of testing hardcoded Beta2 builds we use the latest. This might have broken as a result of a bug in install.jbds.sh - I thought this used to work: {code} ++ TMPDIR=/tmp /mnt/hudson_workspace/workspace/devstudio.versionwatch_8.0.luna/sources/vwatch/install.jbds.sh: command substitution: line 151: unexpected EOF while looking for matching `"' /mnt/hudson_workspace/workspace/devstudio.versionwatch_8.0.luna/sources/vwatch/install.jbds.sh: command substitution: line 152: syntax error: unexpected end of file {code} Either way, we need a better unit test here to ensure that the versions diffed are NOT just the list of hardcoded ones, but instead include the hardcoded list + at least one more (latest build). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3303) [unit test] versionwatch should not fail silently when the report is empty

by CDW Engine (JIRA)

[ https://issues.jboss.org/browse/JBDS-3303?page=com.atlassian.jira.plugin.... ] CDW Engine updated JBDS-3303: ----------------------------- CDW docs_ack: ? CDW devel_ack: ? CDW pm_ack: + CDW qa_ack: ? CDW release: ? > [unit test] versionwatch should not fail silently when the report is empty > -------------------------------------------------------------------------- > > Key: JBDS-3303 > URL: https://issues.jboss.org/browse/JBDS-3303 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: build > Affects Versions: 8.0.1.GA > Reporter: Nick Boldt > Assignee: Nick Boldt > > versionwatch should not fail silently when the report is empty, such as: > {code} > JBDS Version Watch > Feature list for filter = .*(hibernate\|jboss\|xulrunner).* > Plugin list for filter = .*(hibernate\|jboss\|xulrunner).* > Generated by VersionWatch 0.3.0 in 0 min, 4 sec at 2014-12-14 20:19:34.853. > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3303) [unit test] versionwatch should not fail silently when the report is empty

by Nick Boldt (JIRA)

Nick Boldt created JBDS-3303: -------------------------------- Summary: [unit test] versionwatch should not fail silently when the report is empty Key: JBDS-3303 URL: https://issues.jboss.org/browse/JBDS-3303 Project: Developer Studio (JBoss Developer Studio) Issue Type: Bug Components: build Affects Versions: 8.0.1.GA Reporter: Nick Boldt Assignee: Nick Boldt versionwatch should not fail silently when the report is empty, such as: {code} JBDS Version Watch Feature list for filter = .*(hibernate\|jboss\|xulrunner).* Plugin list for filter = .*(hibernate\|jboss\|xulrunner).* Generated by VersionWatch 0.3.0 in 0 min, 4 sec at 2014-12-14 20:19:34.853. {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18764) Weird behavior of the packaging exclusions support

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18764?page=com.atlassian.jira.plugi... ] Fred Bricon commented on JBIDE-18764: ------------------------------------- haven't retried in a while > Weird behavior of the packaging exclusions support > -------------------------------------------------- > > Key: JBIDE-18764 > URL: https://issues.jboss.org/browse/JBIDE-18764 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server > Affects Versions: 4.2.0.Final > Reporter: Fred Bricon > Attachments: excludejars.zip > > > I have a multi-module maven project with ear, war, ejb ... > The excludejars-web/pom.xml defines <packagingExcludes>WEB-INF/lib/*</packagingExcludes> > When deploying excludejars-ear to WF, the excludejars-ear/excludejars-web-0.0.1-SNAPSHOT.war/WEB-INF/lib directory is empty, as expected. > Now if you remove <packagingExcludes>WEB-INF/lib/*</packagingExcludes> from the excludejars-web/pom.xml , Update the Maven project configuration (Alt-F5) on the excludejars-web project, org.eclipse.wst.common.component is updated to contain <property name="component.exclusion.patterns"/> > When you do a full publish on the ear project, excludejars-ear/excludejars-web-0.0.1-SNAPSHOT.war/WEB-INF/lib is still empty. Same thing if you invoke "clean" on the WF server adapter. > The only way to get the jars deployed is to remove the ear from WF, clean, then add the ear back. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18861) module start action does not delete *.undeployed file

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18861?page=com.atlassian.jira.plugi... ] Rob Stryker reassigned JBIDE-18861: ----------------------------------- Assignee: Rob Stryker > module start action does not delete *.undeployed file > ----------------------------------------------------- > > Key: JBIDE-18861 > URL: https://issues.jboss.org/browse/JBIDE-18861 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: server > Environment: Windows7 64bit, JDK 8u25 > Reporter: Darryl Miles > Assignee: Rob Stryker > Priority: Minor > Fix For: 4.2.2.Final, 4.3.0.Alpha1 > > > If you start Wildfly with all modules enabled and started. > Now use STOP action on an EAR module. > Now stop Wildfly. > Now start Wildfly (debug or run). > It will start up without the EAR module running, this is correct behavior at this point. > Now use START on EAR module. It fails to start at all. > This is because the file *.undeployed still exists. If you manually remove the file (using system file manager) the module will start up. > If you perform a "full publish" on the module that appears to cause it to start up as well. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18764) Weird behavior of the packaging exclusions support

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18764?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-18764: ------------------------------------- [~fbricon] Any luck replicating this? > Weird behavior of the packaging exclusions support > -------------------------------------------------- > > Key: JBIDE-18764 > URL: https://issues.jboss.org/browse/JBIDE-18764 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server > Affects Versions: 4.2.0.Final > Reporter: Fred Bricon > Attachments: excludejars.zip > > > I have a multi-module maven project with ear, war, ejb ... > The excludejars-web/pom.xml defines <packagingExcludes>WEB-INF/lib/*</packagingExcludes> > When deploying excludejars-ear to WF, the excludejars-ear/excludejars-web-0.0.1-SNAPSHOT.war/WEB-INF/lib directory is empty, as expected. > Now if you remove <packagingExcludes>WEB-INF/lib/*</packagingExcludes> from the excludejars-web/pom.xml , Update the Maven project configuration (Alt-F5) on the excludejars-web project, org.eclipse.wst.common.component is updated to contain <property name="component.exclusion.patterns"/> > When you do a full publish on the ear project, excludejars-ear/excludejars-web-0.0.1-SNAPSHOT.war/WEB-INF/lib is still empty. Same thing if you invoke "clean" on the WF server adapter. > The only way to get the jars deployed is to remove the ear from WF, clean, then add the ear back. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18861) module start action does not delete *.undeployed file

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18861?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-18861: ------------------------------------- [~mmalina] Please verify this on master so I know whether its suitable for maintenance. > module start action does not delete *.undeployed file > ----------------------------------------------------- > > Key: JBIDE-18861 > URL: https://issues.jboss.org/browse/JBIDE-18861 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: server > Environment: Windows7 64bit, JDK 8u25 > Reporter: Darryl Miles > Priority: Minor > Fix For: 4.2.2.Final, 4.3.0.Alpha1 > > > If you start Wildfly with all modules enabled and started. > Now use STOP action on an EAR module. > Now stop Wildfly. > Now start Wildfly (debug or run). > It will start up without the EAR module running, this is correct behavior at this point. > Now use START on EAR module. It fails to start at all. > This is because the file *.undeployed still exists. If you manually remove the file (using system file manager) the module will start up. > If you perform a "full publish" on the module that appears to cause it to start up as well. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 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 January 2015