[JBoss JIRA] (JBIDE-18912) Custom deploy dir with remote server using filesystem operations does not work
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18912?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-18912:
-------------------------------
Fix Version/s: 4.4.4.AM1
(was: 4.4.3.AM2)
> Custom deploy dir with remote server using filesystem operations does not work
> ------------------------------------------------------------------------------
>
> Key: JBIDE-18912
> URL: https://issues.jboss.org/browse/JBIDE-18912
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.1.CR1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Labels: help_wanted
> Fix For: 4.4.4.AM1
>
>
> This is a follow up of JBIDE-17180 and JBIDE-13445 which added the option to add a custom deployment directory if your remote server is using filesystem operations (for management api it's not relevant since the deployment happens directly, no directory is used).
> Unfortunately it does not work. It seems I haven't really tried it when reviewing those other JIRAs because there were other obstacles.
> I tried this several times and still could not get it to work.
> Perhaps it might be worth to try and get this in the final 4.2.1.Final build?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JBIDE-19368) File not deployed to server on Windows
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19368?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-19368:
-------------------------------
Fix Version/s: 4.4.4.AM1
(was: 4.4.3.AM2)
> File not deployed to server on Windows
> --------------------------------------
>
> Key: JBIDE-19368
> URL: https://issues.jboss.org/browse/JBIDE-19368
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.2.Final
> Environment: Windows 7, JBDS 4.2.2, EAP 6.4 ER1
> Reporter: Lucia Jelinkova
> Assignee: Lucia Jelinkova
> Priority: Minor
> Fix For: 4.4.4.AM1
>
> Attachments: deployments.zip, jsp-project.zip, workspace.zip
>
>
> Sometimes our automated EAP <-> JBDS compatibility UI tests fail on windows machine because one java file of the tested project is not deployed to the server (and is not in the deployment folder either).
> The tests runs like this:
> # Create server and start it
> # Import project with JSP file from ZIP into the workspace
> # Add server as targeted runtime via Properites
> # Right-click server and via Add/Remove modules add the imported project to the server
> # Open module's web page (right click + open in web browser)
> RESULT: JSP file compilation fails because it is not able to resolve HelloWorld.java class
> I have not seen any errors in server's console (except for the compilation error).
> {code}
> 05:25:04,990 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.4.Final-redhat-1
> 05:25:05,678 INFO [org.jboss.msc] (main) JBoss MSC version 1.1.5.Final-redhat-1
> 05:25:05,850 INFO [org.jboss.as] (MSC service thread 1-4) JBAS015899: JBoss EAP 6.4.0.Alpha1 (AS 7.5.0.Final-redhat-11) starting
> 05:25:08,568 INFO [org.xnio] (MSC service thread 1-4) XNIO Version 3.0.11.GA-redhat-2
> 05:25:08,584 INFO [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Version 3.0.11.GA-redhat-2
> 05:25:08,600 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 05:25:08,787 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 45) JBAS010153: Node identifier property is set to the default value. Please make sure it is unique.
> 05:25:08,803 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 30) JBAS010280: Activating Infinispan subsystem.
> 05:25:08,850 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 38) JBAS011800: Activating Naming Subsystem
> 05:25:08,881 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 36) JBAS012605: Activated the following JSF Implementations: [main, 1.2]
> 05:25:08,928 INFO [org.jboss.as.security] (ServerService Thread Pool -- 43) JBAS013171: Activating Security Subsystem
> 05:25:08,975 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 47) JBAS015537: Activating WebServices Extension
> 05:25:09,131 INFO [org.jboss.as.security] (MSC service thread 1-3) JBAS013170: Current PicketBox version=4.1.0.Beta1-redhat-1
> 05:25:09,381 INFO [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 3.3.4.Final-redhat-1
> 05:25:09,584 INFO [org.jboss.as.naming] (MSC service thread 1-4) JBAS011802: Starting Naming Service
> 05:25:09,600 INFO [org.jboss.as.mail.extension] (MSC service thread 1-4) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 05:25:09,725 INFO [org.jboss.as.connector.logging] (MSC service thread 1-4) JBAS010408: Starting JCA Subsystem (IronJacamar 1.0.29.Final-redhat-1)
> 05:25:10,334 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 15) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:25:10,412 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-2) JBWEB003001: Coyote HTTP/1.1 initializing on : http-localhost/127.0.0.1:8080
> 05:25:10,553 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-2) JBWEB003000: Coyote HTTP/1.1 starting on: http-localhost/127.0.0.1:8080
> 05:25:10,881 INFO [org.jboss.as.remoting] (MSC service thread 1-3) JBAS017100: Listening on 127.0.0.1:9999
> 05:25:10,881 INFO [org.jboss.as.remoting] (MSC service thread 1-3) JBAS017100: Listening on 127.0.0.1:4447
> 05:25:10,928 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-4) JBAS015012: Started FileSystemDeploymentService for directory W:\workspace\eap-6x-jbds-compatibility-jbosstools-4.2.x-windows\8b0502d6\tests\org.jboss.ide.eclipse.as.ui.bot.test\target\requirements\jboss-eap-6.4\standalone\deployments
> 05:25:11,287 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 05:25:12,100 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.3.1.Final-redhat-1
> 05:25:12,272 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 05:25:12,272 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 05:25:12,272 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss EAP 6.4.0.Alpha1 (AS 7.5.0.Final-redhat-11) started in 9016ms - Started 152 of 190 services (57 services are lazy, passive or on-demand)
> 05:25:25,990 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015003: Found jsp-project.war in deployment directory. To trigger deployment create a file called jsp-project.war.dodeploy
> 05:25:26,084 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "jsp-project.war" (runtime-name: "jsp-project.war")
> 05:25:26,881 INFO [org.jboss.web] (ServerService Thread Pool -- 24) JBAS018210: Register web context: /jsp-project
> 05:25:27,318 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "jsp-project.war" (runtime-name : "jsp-project.war")
> 05:25:39,693 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/jsp-project].[jsp]] (http-localhost/127.0.0.1:8080-1) JBWEB000236: Servlet.service() for servlet jsp threw exception: org.apache.jasper.JasperException: JBWEB004062: Unable to compile class for JSP:
> JBWEB004060: An error occurred at line: 4 in the jsp file: /index.jsp
> HelloWorld cannot be resolved
> 1: <%@ page language="java" import="org.jboss.tools.tests.as.*" errorPage="" %>
> 2: <html>
> 3: <body>
> 4: <%=HelloWorld.sayHello()%>
> 5: </body>
> 6: </html>
> JBWEB004211: Stacktrace:
> at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:85) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:69) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:461) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:361) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:339) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:326) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:606) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:308) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:309) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:242) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.0.Final-redhat-11.jar:7.5.0.Final-redhat-11]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> {code}
> Do you have any idea why this could happen or how to continue with locating the problem?
> I am attaching the imported project as ZIP file, the workspace after import and also the content of deployments folder.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JBIDE-19225) java.lang.IllegalArgumentException: null source after importing WFK Spring projects
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19225?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-19225:
-------------------------------
Fix Version/s: 4.4.4.AM1
(was: 4.4.3.AM2)
> java.lang.IllegalArgumentException: null source after importing WFK Spring projects
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-19225
> URL: https://issues.jboss.org/browse/JBIDE-19225
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: project-examples, upstream
> Affects Versions: 4.2.2.Final
> Reporter: Jiri Peterka
> Assignee: Fred Bricon
> Fix For: 4.4.4.AM1
>
>
> {code}
> java.lang.IllegalArgumentException: null source
> at java.util.EventObject.<init>(EventObject.java:56)
> at org.springframework.ide.eclipse.core.model.ModelChangeEvent.<init>(ModelChangeEvent.java:43)
> at org.springframework.ide.eclipse.core.model.AbstractModel.notifyListeners(AbstractModel.java:43)
> at org.springframework.ide.eclipse.beans.core.internal.model.BeansModel$ResourceChangeEventHandler.configAdded(BeansModel.java:598)
> at org.springframework.ide.eclipse.beans.core.internal.model.resources.BeansResourceChangeListener$BeansResourceVisitor.resourceAdded(BeansResourceChangeListener.java:97)
> at org.springframework.ide.eclipse.core.internal.model.resources.SpringResourceChangeListener$SpringResourceVisitor.visit(SpringResourceChangeListener.java:145)
> at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:69)
> at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80)
> at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80)
> at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80)
> at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80)
> at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80)
> at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80)
> at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80)
> at org.springframework.ide.eclipse.core.internal.model.resources.SpringResourceChangeListener.resourceChanged(SpringResourceChangeListener.java:83)
> at org.eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.java:291)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285)
> at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:149)
> at org.eclipse.core.internal.resources.Workspace.broadcastBuildEvent(Workspace.java:364)
> at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:146)
> at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JBIDE-19182) Incremental Publish after Full Publish WRT dodeploy markers
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19182?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-19182:
-------------------------------
Fix Version/s: 4.4.4.AM1
(was: 4.4.3.Final)
> Incremental Publish after Full Publish WRT dodeploy markers
> -----------------------------------------------------------
>
> Key: JBIDE-19182
> URL: https://issues.jboss.org/browse/JBIDE-19182
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.Final
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.4.4.AM1
>
>
> THis issue is opened in regards to comments by [~dlmiles] on https://issues.jboss.org/browse/JBIDE-18862
> 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.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JBDS-4066) DevSuite Installer Account step styles are inconsistent with Target Folder step
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-4066?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBDS-4066:
-----------------------------
Fix Version/s: 10.3.0.GA
(was: 10.3.0.AM2)
> DevSuite Installer Account step styles are inconsistent with Target Folder step
> -------------------------------------------------------------------------------
>
> Key: JBDS-4066
> URL: https://issues.jboss.org/browse/JBDS-4066
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Enhancement
> Components: platform-installer
> Affects Versions: 10.1.0.GA
> Reporter: Denis Golovin
> Assignee: Sudhir Verma
> Labels: ui
> Fix For: 10.3.0.GA
>
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> Account page looks different from Target Location page:
> 1. Fields with invalid values have red glow border with gradient;
> 2. There are three areas to show error messages one for each field and one for login error;
> 3. Username and password error have styling different from login error and from validation messages on Target Location page;
> 4. Field height is different from Target Location field;
> 5. When validation messages appear they move elements on Account Page back and forth;
> To Do:
> 1. Always show only one message between fields and buttons
> 2. If username and password are empty show error message: "Please enter your username and password"
> 3. If username is empty show error message: "Please enter your username"
> 4. If password is empty show error message: "Please enter your password"
> 5. Show only one message at a time, if there is "Invalid account information, please try again" message and password or username is changed hide error message.
> Account Step:
> !screenshot-1.png!
> Target Location Step:
> !screenshot-2.png!:
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JBIDE-22305) automate process for fetching latest target platform mirrors
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22305?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-22305:
-------------------------------
Fix Version/s: 4.4.x
(was: 4.4.3.AM2)
> automate process for fetching latest target platform mirrors
> ------------------------------------------------------------
>
> Key: JBIDE-22305
> URL: https://issues.jboss.org/browse/JBIDE-22305
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: target-platform, updatesite, upstream
> Affects Versions: 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Labels: releasework
> Fix For: 4.4.x
>
> Attachments: git.diff.txt
>
>
> Rather than manually pulling requirements, it would be hella sweet if there was a job config into which we could just list all the URLs to mirror and their matching project names.
> Then this job would scrape the *.target files for the current list of URLs used, grep out the /requirements/<reqname>/<version>, fetch a new mirror for each new version*, and dump an updated copy of the .target file into the job's workspace.
> Thus for webtools we might simply define:
> webtools,S-3.8.0M7-20160503010110,http://download.eclipse.org/webtools/do...
> and we'd end up with:
> http://download.jboss.org/jbosstools/updates/requirements/webtools/S-3.8....
> * Since we already have a http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt... job we can just pass parameters to that to invoke the mirroring steps. Would be even better if we could run multiple calls in parallel as neon and wtp can take >2hr
> 1. matrix job. each config is a trio of reqname/version/URL which is passed to a process akin to that of the jbosstools-requirements job to perform the mirror; process is now scripted here: https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/p...
> 2. when all children are done, a downstream job can runs TP update & validation against new .target files
> * fetch http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstoolstargetplatf...
> * parse that into a list of URLs
> * each URL contains REQ_NAME/VERSION, which can then be matched up with similar lines in .target files
> * run p2diff between old/new URLs in .target to generate list of changes and verify new site contains all the same IUs
> * resulting edited .target files will remain in the workspace, and we can then run
> * https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/u...
> * when done if success:
> * ideally, generate a PR and attach link in email to jbosstools-dev@
> * if can't generate PR, then attach patch in email to nickboldt & mistria to apply locally in jbosstools-target-platforms to create a PR
> * email should includes boilerplate text to send mail to list announcing new change for review
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JBIDE-19391) Properties File editor does not work properly
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19391?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-19391:
-------------------------------
Fix Version/s: 4.4.4.AM1
(was: 4.4.3.AM2)
> Properties File editor does not work properly
> ---------------------------------------------
>
> Key: JBIDE-19391
> URL: https://issues.jboss.org/browse/JBIDE-19391
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: common
> Reporter: Ali Hopyar
> Assignee: Viacheslav Kabanovich
> Fix For: 4.4.4.AM1
>
> Attachments: messages_en.properties
>
>
> On eclipse luna, I can not use JBoss editor for properties files. When I clicked add button nothing happens. When I click source tab and try to add some property, it is disappears when saved. Also if I open a property file that has been written before, also its content disappears.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JBIDE-23503) Target platform PR check fails to use p2diff correctly, so build fails
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23503?page=com.atlassian.jira.plugi... ]
Nick Boldt reassigned JBIDE-23503:
----------------------------------
Assignee: Nick Boldt (was: Mickael Istria)
> Target platform PR check fails to use p2diff correctly, so build fails
> ----------------------------------------------------------------------
>
> Key: JBIDE-23503
> URL: https://issues.jboss.org/browse/JBIDE-23503
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build, target-platform
> Affects Versions: 4.4.2.AM3
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.4.AM1
>
> Attachments: dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com.log.txt
>
>
> Recently, it was noticed that the TP PR checks are failing. And have been for a long time.
> So, I'm opening this to track the work needed to make them work again.
> There are two different TP PR jobs:
> * https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/jbosstoo... (which seems to have never worked)
> * https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/jbos... (which has been blue in the past)
> Recent failure:
> {code}
> [INFO] Command line:
> [/qa/tools/opt/x86_64/jdk1.8.0_101/jre/bin/java, -jar, /mnt/hudson_workspace/workspace/jbosstools-target-platform-Pull-Request/.repository/p2/osgi/bundle/org.eclipse.equinox.launcher/1.3.100.v20150511-1540/org.eclipse.equinox.launcher-1.3.100.v20150511-1540.jar, -install, /mnt/hudson_workspace/workspace/jbosstools-target-platform-Pull-Request/jbosstools/multiple/target/eclipserun-work, -configuration, /mnt/hudson_workspace/workspace/jbosstools-target-platform-Pull-Request/jbosstools/multiple/target/eclipserun-work/configuration, -application, org.eclipse.equinox.p2.example.p2diff.application, -outputFile=/mnt/hudson_workspace/workspace/jbosstools-target-platform-Pull-Request/jbosstools/multiple/target/jbosstools-multiple-ignoreVersions.p2diff, -mode=ignoreVersions, file:/mnt/hudson_workspace/workspace/jbosstools-target-platform-Pull-Request/jbosstools/multiple/target/jbosstools-multiple.target.repo, http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.6...]
> An error has occurred. See the log file
> /mnt/hudson_workspace/workspace/jbosstools-target-platform-Pull-Request/jbosstools/multiple/target/eclipserun-work/configuration/1479683354475.log.{code}
> https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/jbosstoo...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JBIDE-19454) Malformed strings when starting a remote host via localhost
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19454?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-19454:
-------------------------------
Fix Version/s: 4.4.4.AM1
(was: 4.4.3.AM2)
> Malformed strings when starting a remote host via localhost
> -----------------------------------------------------------
>
> Key: JBIDE-19454
> URL: https://issues.jboss.org/browse/JBIDE-19454
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.3.Beta1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.4.4.AM1
>
>
> This is strange.
> When I create a remote WildFly 8.2 server on a remote server (I use a SSH-only remote host), everything works fine.
> But when I try to create a remote host that is actually localhost and then start WildFly, I get errors because some of the strings are broken.
> This is in the console in Eclipse:
> {code}
> echo $PWD'>'
> echo $PWD'>'
> java "-Dprogram.name=JBossTools: WildFly 8 remote localhost" -Xms64m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true "-Dorg.jboss.boot.log.file=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final" -Dorg.jboss.logmanager.nocolor=true -Djboss.bind.address.management=LOCALHOST -jar /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/jboss-modules.jar -mp "/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b 0.0.0.0 --server-config=standalone.xml -Djboss.server.base.dir=/Users/rasp/jbossqa/runtimes/wildfly-nattura:/ rasp$
> nattura:/ rasp$ cd /
> echo $PWD'>'
> echo $PWD'>'
> java "-Dprogram.name=JBossTools: WildFly 8 remote localhost" -Xms64m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true "-Dorg.jboss.boot.log.file=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final" -Dorg.jboss.logmanager.nocolor=true -Djboss.bind.address.management=LOCALHOST -jar /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/jboss-modules.jar -mp "/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b 0.0.0.0 --server-config=standalone.xml -Djboss.server.base.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.janattura:/ rasp$
> nattura:/ rasp$ echo $PWD'>'
> echo $PWD'>'
> java "-Dprogram.name=JBossTools: WildFly 8 remote localhost" -Xms64m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true "-Dorg.jboss.boot.log.file=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final" -Dorg.jboss.logmanager.nocolor=true -Djboss.bind.address.management=LOCALHOST -jar /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/jboss-modules.jar -mp "/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b 0.0.0.0 --server-config=standalone.xml -Djboss.server.base.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.javal/java "-Dne&/>
> nattura:/ rasp$ echo $PWD'>'
> />
> java "-Dprogram.name=JBossTools: WildFly 8 remote localhost" -Xms64m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true "-Dorg.jboss.boot.log.file=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final" -Dorg.jboss.logmanager.nocolor=true -Djboss.bind.address.management=LOCALHOST -jar /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/jboss-modules.jar -mp "/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b 0.0.0.0 --server-config=standalone.xml -Djboss.server.base.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.javal/java "-Dne&
> eeeeeeeeTOOLnattura:/ rasp$ java "-Dprogram.name=JBossTools: WildFly 8 remote localhost" -Xm s64m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Djava.net. preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.serve r.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.he adless=true "-Dorg.jboss.boot.log.file=/Users/rasp/jbossqa/runtimes/wildfly-8.2. 0.Final/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/rasp/jboss qa/runtimes/wildfly-8.2.0.Final/standalone/configuration/logging.properties" "-D jboss.home.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final" -Dorg.jboss.log manager.nocolor=true -Djboss.bind.address.management=LOCALHOST -jar /Users/rasp/ jbossqa/runtimes/wildfly-8.2.0.Final/jboss-modules.jar -mp "/Users/rasp/jbossqa /runtimes/wildfly-8.2.0.Final/modules" -jaxpmodule javax.xml.jaxp-provider org.j boss.as.standalone -b 0.0.0.0 --server-config=standalone.xml -Djboss.server.base .dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.javal/java "-Dne&
> > eeeeeeeeTOOLS_SERVER_START_CMD:WildFly 8 remote localhost:"$!
> 13:51:37,472 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final
> java.lang.IllegalStateException: JBAS018702: Server base directory does not exist: /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.javal/java
> at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:365)
> at org.jboss.as.server.Main.determineEnvironment(Main.java:262)
> at org.jboss.as.server.Main.main(Main.java:92)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:460)
> nattura:/ rasp$
> {code}
> The correct path to the server is /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final as was set up. But for some reason, some of the strings are wrong in the startup command. Most notably this: -Djboss.server.base.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.javal/java
> PS: I'm on OS X, so it might have something to do with that.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month