January 2015 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-18715) Server Adapter: Notification should be shown once the server is started (e.g. EAP, AS...)

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18715?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-18715: ------------------------------------- Isn't this what the servers view is for? It has server state listed there and it'd seem more logical to link up with that than to open new notifications in other places. > Server Adapter: Notification should be shown once the server is started (e.g. EAP, AS...) > ----------------------------------------------------------------------------------------- > > Key: JBIDE-18715 > URL: https://issues.jboss.org/browse/JBIDE-18715 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: openshift, server > Affects Versions: 4.2.0.Final > Reporter: Marián Labuda > Labels: server_adapter > Fix For: LATER > > > Under "server" I mean EAP, AS, WildFly, Tomcat... catridges (server runtimes). > We talked with [~adietish] about having a notification about started server. It would help with application deployment to know, when the server is running and not to check/stare into the console. > Notification should be shown in the bottom right corner and at first it should inform user about server being started and that we are going to inform him/her once the server is started. Second notification would be shown once the server is started. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19090) jbosstools-maven-plugins requires Java 7 but compiles to Java 8 requirement?

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19090?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-19090: ---------------------------------------- I did chose org.json because it's the most documented one. I'm not against using DMR, it wasn't just not as easy to get started. > jbosstools-maven-plugins requires Java 7 but compiles to Java 8 requirement? > ---------------------------------------------------------------------------- > > Key: JBIDE-19090 > URL: https://issues.jboss.org/browse/JBIDE-19090 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.3.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.3.0.Alpha1 > > > Parent pom compilation is now failing if run with JDK 7 (but works w/ JDK 8): > {code:title=https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build.parent_master/419/} > [8mha:AAAAYB+LCAAAAAAAAP9b85aBtbiIQSmjNKU4P0+vJLE4u1gvPjexLDVPzxdEuhYV5Rf55ZekOlc7RKnPKH7IxMBQUcQgBdWQnJ9XnJ+TqucMoUEKGSCAEaSwAACsNFCqYAAAAA== > [ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site (generate-full-site) on project > parent: Execution generate-full-site of goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site failed: An API > incompatibility was encountered while executing org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site: > java.lang.UnsupportedClassVersionError: org/json/JSONObject : Unsupported major.minor version 52.0 > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19047) Issue deploying EAR project from eclipse to Wildfly using JBoss Tools Plugin

by Nick . (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19047?page=com.atlassian.jira.plugi... ] Nick . commented on JBIDE-19047: -------------------------------- Yes i have seen it for jasperreports-javaflow, sure i could replicate the same ear i've attached with the unresolved dependency. > Issue deploying EAR project from eclipse to Wildfly using JBoss Tools Plugin > ---------------------------------------------------------------------------- > > Key: JBIDE-19047 > URL: https://issues.jboss.org/browse/JBIDE-19047 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: maven, server, upstream > Environment: Ubuntu 14.04, Wildfly 8.2.0 FInal, Eclipse Luna > Reporter: Nick . > Assignee: Fred Bricon > Fix For: 4.3.x > > Attachments: sample.zip, settings.zip > > > Hi, > I have a maven EAR project, which contains a couple of WAR and JAR files. I'm using Eclipse Luna (tried STS and IntelliJ ) IDE with JBoss Tools 1.6.0 (latest). > When I try to deploy my EAR to Wildfly (as well as in EAP 6.2.0) with JBoss Tools from eclipse i'm facing the following issues. > My Jars (external jars and project jar) are getting copied into WEB-INF/lib and EAR/lib, where i expected it to be only in EAR/lib. > EAR application.xml is not getting copied into EAR/META-INF/ folder > But when i use command line to build my project , i'm not experiencing the above issue. > FYI : We are using <skinnyWars>true</skinnyWars>. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically

by Darryl Miles (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugi... ] Darryl Miles commented on JBIDE-18862: -------------------------------------- Yes and No. It is more complicated than a black and white answer. I am saying you should block all 'deployment directory' file modifications when you know the AS is busy using the 'deployment directory' to "deploy" (a.k.a. starting) or "undeploy" (a.k.a. stopping) of a module (or the AS itself is starting/stopping in certain scenarios). Ideally you use a file watcher API when available so there is no busy/wait loop adding additional milliseconds of delays because the wait part is never instant. But in an example scenario where you perform a Full Publish then 2 additional Incremental Publish ops immediately after, there is no reason to block the incrementals if you know the AS has not picked up the original Full Publish yet. You can effectively merge those two incrementals into the full publish operation behind the back of the AS. But you are presented with a race scenario, you have already laid down the *.dodeploy at the end of the original Full Publish. So Eclipse needs to effectively notice that scenario exists, revoke and remember that instruction to the AS in an atomic way (what I mean by this is Eclipse knows for sure if it cancelled it in time, or if it was too late and the AS got to the full publish first and started deploying). You need to do this so Eclipse can make file change modifications to the 'deployment directory' again. Once Eclipse has completed the file change operations, if takes that remembered state and puts back the *.dodeploy file (even though this is an Incremental Publish operation). You can think of this like a "save state" and "restore state" pattern if that helps. Or you can think of this like the Eclipse target goal state for the AS (such as "AS:started" and "module.abc:started") is compared to the actual AS state (such as "AS: started" and "module.abc:stopped"), and Eclipse then brings them into alignment to do this it realizes it needs to lay down the *.dodeploy marker file (even though this is an incremental publish). I think with the current marker file arrangements there maybe a tiny window of time where Eclipse IDE will get things wrong in respect of the AS ? But maybe ensuring both Eclipse IDE and the AS check the return value of the file delete for *.dodeploy whomever was successful in deleting the file wins, whichever party got the error "No Such File" loses and performs a rollback/cleanup of the situation to ensure it tries again soon. So you can speak for the JBIDE side but can someone check the AS side ? File#delete(new File("foobar.dodeploy")) != true. The AS has to delete the command instruction file before it starts to process that command, but after it has laid down a state change file (*.isdeploying). One of the goals of the marker files is that at no point in time is there a snapshot of the files that exist in the directory; that would leave an observer to interpret the wrong state. For example deleting one marker file before laying down the next would be bad, because there is a snapshot of time when no state marker file exists in the directory, leaving the observer to interpret that nothing is happening with that module. The alternative is to lay both the new file first then delete the old one, now there is a window of time when 2 marker files indicate state for 1 module, this is good and valid since the observer can clearly see the correct state. So if you got here and are still with me, then you can see how things should only slow down, when they need to slow down. > when removing a module from AS runtime marker files are not removed automatically > --------------------------------------------------------------------------------- > > Key: JBIDE-18862 > URL: https://issues.jboss.org/browse/JBIDE-18862 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server > Environment: Windiws7 64bit, JDK 8u25 > Reporter: Darryl Miles > Assignee: Rob Stryker > Fix For: 4.2.3.Final, 4.3.0.Alpha1 > > > module removal does not delete the various marker files relating to it: > *.undeployed > *.dodeploy > The same should be true when ADDING a module, it should clean out any marker files. > Setup an deploy-inhibiting marker file to ensure it won't try to deploy it before the *.ear is full written. > Write out the*.ear file. > Then adjust the marker files as necessary to reflect the intended state of the module (if it should be started then remove the inhibiting marker file in the previous step). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3310) 3rd party certification for JBDS 8.0.2.GA

by Michelle Murray (JIRA)

[ https://issues.jboss.org/browse/JBDS-3310?page=com.atlassian.jira.plugin.... ] Michelle Murray commented on JBDS-3310: --------------------------------------- Yep nick, SR1a was listed in the RNs > 3rd party certification for JBDS 8.0.2.GA > ----------------------------------------- > > Key: JBDS-3310 > URL: https://issues.jboss.org/browse/JBDS-3310 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Feature Request > Components: 3rd-party-certification, 3rd-party-dependencies, requirements, target-platform > Affects Versions: 8.0.0.GA > Reporter: Nick Boldt > Assignee: Len DiMaggio > Priority: Blocker > Fix For: 8.0.2.GA > > > For JBDS 8.0.2.GA, track changes since JBDS-3215 (8.0.1.GA release). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19058) refactor output.html and product.html into report_detailed.html and report_summary.html

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19058?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-19058: ------------------------------- Fix Version/s: 4.3.0.Alpha1 > refactor output.html and product.html into report_detailed.html and report_summary.html > --------------------------------------------------------------------------------------- > > Key: JBIDE-19058 > URL: https://issues.jboss.org/browse/JBIDE-19058 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, qa > Affects Versions: 4.3.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.3.0.Alpha1 > > > Today, vwatch produces two files: > * a detailed, tabular report called "output.hml" > * a summary report called "product.html" > In Jenkins, I then rename these to results*.html and report*.html, which is a bit confusing because the files are not listed next to each other in the http://download.jboss.org/jbosstools/builds/staging/devstudio.versionwatc... folder. > So, I propose we generate the files with these names: > * report_detailed.html > * report_summary.html > Then in Jenkins we can simply rename them to include a timestamp/buildID prefix, and continue to differentiate the "all" report from the org.jboss-only "filtered" report: > * 2015-01-07_17-28-06_B1766_report_detailed_all.html > * 2015-01-07_17-28-06_B1766_report_detailed_filtered.html > * 2015-01-07_17-28-06_B1766_report_summary_all.html > * 2015-01-07_17-28-06_B1766_report_summary_filtered.html -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19058) refactor output.html and product.html into report_detailed.html and report_summary.html

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19058?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-19058: ------------------------------- Affects Version/s: 4.3.0.Alpha1 > refactor output.html and product.html into report_detailed.html and report_summary.html > --------------------------------------------------------------------------------------- > > Key: JBIDE-19058 > URL: https://issues.jboss.org/browse/JBIDE-19058 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, qa > Affects Versions: 4.3.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.3.0.Alpha1 > > > Today, vwatch produces two files: > * a detailed, tabular report called "output.hml" > * a summary report called "product.html" > In Jenkins, I then rename these to results*.html and report*.html, which is a bit confusing because the files are not listed next to each other in the http://download.jboss.org/jbosstools/builds/staging/devstudio.versionwatc... folder. > So, I propose we generate the files with these names: > * report_detailed.html > * report_summary.html > Then in Jenkins we can simply rename them to include a timestamp/buildID prefix, and continue to differentiate the "all" report from the org.jboss-only "filtered" report: > * 2015-01-07_17-28-06_B1766_report_detailed_all.html > * 2015-01-07_17-28-06_B1766_report_detailed_filtered.html > * 2015-01-07_17-28-06_B1766_report_summary_all.html > * 2015-01-07_17-28-06_B1766_report_summary_filtered.html -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19063) Ensure that new "bumped.png" image is published when vwatch reports are archived in Jenkins / published to dl.jb.org

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19063?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-19063: ------------------------------- Fix Version/s: 4.3.0.Alpha1 > Ensure that new "bumped.png" image is published when vwatch reports are archived in Jenkins / published to dl.jb.org > -------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-19063 > URL: https://issues.jboss.org/browse/JBIDE-19063 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, qa > Affects Versions: 4.2.2.Final > Reporter: Nick Boldt > Assignee: Jiri Peterka > Fix For: 4.3.0.Alpha1 > > > A new bumped icon has been added to the vwatch reports [ in jbdevstudio-qa/vwatch/target/bumped.png ], but it's not included in what is archived in Jenkins and published to dl.jb.org. > So, we need to ensure that any images are published when vwatch reports are archived in Jenkins / published to dl.jb.org -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19057) externalize MultipleVersionIssue#ignore into pom properties for easier extensibility

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19057?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-19057: ------------------------------- Fix Version/s: 4.3.0.Alpha1 > externalize MultipleVersionIssue#ignore into pom properties for easier extensibility > ------------------------------------------------------------------------------------ > > Key: JBIDE-19057 > URL: https://issues.jboss.org/browse/JBIDE-19057 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, qa > Affects Versions: 4.2.2.Final > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.3.0.Alpha1 > > > Currently, there are two IUs which are excluded from tracking as a MultipleVersionIssue: > {code:title=MultipleVersionIssue.java} > String[] ignore = {"javax.wsdl","org.apache.commons.logging"}; > {code} > However, we need to add more, such as *org.eclipse.jdt.annotation*, so might as well externalize this into a pom property for easier use. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19058) refactor output.html and product.html into report_detailed.html and report_summary.html

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19058?page=com.atlassian.jira.plugi... ] Nick Boldt reassigned JBIDE-19058: ---------------------------------- Assignee: Nick Boldt > refactor output.html and product.html into report_detailed.html and report_summary.html > --------------------------------------------------------------------------------------- > > Key: JBIDE-19058 > URL: https://issues.jboss.org/browse/JBIDE-19058 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, qa > Reporter: Nick Boldt > Assignee: Nick Boldt > > Today, vwatch produces two files: > * a detailed, tabular report called "output.hml" > * a summary report called "product.html" > In Jenkins, I then rename these to results*.html and report*.html, which is a bit confusing because the files are not listed next to each other in the http://download.jboss.org/jbosstools/builds/staging/devstudio.versionwatc... folder. > So, I propose we generate the files with these names: > * report_detailed.html > * report_summary.html > Then in Jenkins we can simply rename them to include a timestamp/buildID prefix, and continue to differentiate the "all" report from the org.jboss-only "filtered" report: > * 2015-01-07_17-28-06_B1766_report_detailed_all.html > * 2015-01-07_17-28-06_B1766_report_detailed_filtered.html > * 2015-01-07_17-28-06_B1766_report_summary_all.html > * 2015-01-07_17-28-06_B1766_report_summary_filtered.html -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 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