[JBoss JIRA] (JBDS-3044) Align installation default path with installer filename
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3044?page=com.atlassian.jira.plugin.... ]
Nick Boldt edited comment on JBDS-3044 at 5/28/14 10:36 AM:
------------------------------------------------------------
Martin did a quick test on OSX to see what the longest file paths are inside JBDS 8 Beta2:
{quote}
{code}
find jbdevstudio-* |awk '{ print length($0) ; }'|sort|uniq|egrep "2.+"
{code}
shows 251 as the longest path on Mac so not really safe
longest is ./studio/configuration/org.eclipse.osgi/949/data/c7ff8a0a591e0e90fe36069138e75f68/1012-1401176993555/org.springframework.ide.eclipse.core.java.ProjectClassLoaderCache$SourceAndOutputLocationResourceChangeListener$SourceAndOutputLocationResourceVisitor
but that is spring and it's data
{quote}
So we're already pushing the limit here for long paths on Windows / NTFS...
Related (with some LOLs): http://blog.codinghorror.com/filesystem-paths-how-long-is-too-long/
There are ways to achieve more-than-260-char paths, but do we want to?
was (Author: nickboldt):
Martin did a quick test on OSX to see what the longest file paths are inside JBDS 8 Beta2:
{quote}
{code}
find jbdevstudio-* |awk '{ print length($0) ; }'|sort|uniq|egrep "2.+"
{code}
shows 251 as the longest path on Mac so not really safe
longest is ./studio/configuration/org.eclipse.osgi/949/data/c7ff8a0a591e0e90fe36069138e75f68/1012-1401176993555/org.springframework.ide.eclipse.core.java.ProjectClassLoaderCache$SourceAndOutputLocationResourceChangeListener$SourceAndOutputLocationResourceVisitor
but that is spring and it's data
{quote}
So we're already pushing the limit here for long paths on Windows / NTFS...
> Align installation default path with installer filename
> -------------------------------------------------------
>
> Key: JBDS-3044
> URL: https://issues.jboss.org/browse/JBDS-3044
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: installer
> Affects Versions: 8.0.0.Beta2
> Reporter: Martin Malina
> Assignee: Denis Golovin
> Priority: Blocker
> Labels: discuss
> Fix For: 8.0.0.Beta3
>
>
> Now that Nick changed the installer filenames to jboss-devstudio in JBIDE-16871 (was jbdevstudio), shouldn't the default install path be changed similarly? Because it just went out of sync.
> This question is open for discussion. Nick pointed out some reasons against this suggestion:
> {quote}
> Martin Malina Re: changing the installation folder, I'll hold off on that change for the moment for a few reasons:
> a) Max is AFK, and will want to vet/veto this idea
> b) long paths for Windows users (80% of our user base) = bad news, especially considering how long some file paths can get already within Eclipse workspaces
> c) short paths for Windows (c:\jbdevstudio) & long paths for everyone else ~/jboss-devstudio) would be ill-advised from a documentation and cross-platform user experience
> So, either we stick w/ jbdevstudio, or we shorten to devstudio (losing the "jb" branding fragment). If we move to "jboss-devstudio" we increase the path by only 4 characters.
> Max Rydahl Andersen WDYT?
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
1 month
[JBoss JIRA] (JBDS-2719) Multiple Spring AOP problems when travel example is imported
by Joshua Wilson (JIRA)
[ https://issues.jboss.org/browse/JBDS-2719?page=com.atlassian.jira.plugin.... ]
Joshua Wilson commented on JBDS-2719:
-------------------------------------
[~nickboldt] I will need to test several different configurations to confirm my earlier guess. This is what I know so far.
First I would ask that you test with the [Kitchensink-Spring Quickstarts|https://github.com/jboss-developer/jboss-wfk-quickstarts] as I am working to keep them up to date and error free as much as possible. This specific error can be seen in the [kitchensink-spring-matrixvariable|https://github.com/jboss-developer/jbos...] quickstart. The Travel and PetClinic will be kept as close to the original as possible (and I haven't had a chance to update them yet).
With that in mind if I Build (with Eclipse/JBDS) [kitchensink-spring-matrixvariable|https://github.com/jboss-developer/jbos...] in JBDS 7.0.1 with Spring IDE 3.3 installed from JBoss Central, I get the aspectj error. However if I Build while in a standard Eclipse JEE install with JBDS and the stock Spring IDE/STS 3.4 installed, I do NOT get the aspectj error.
In order to truly confirm that adding both "AspectJ Compiler" and "AspectJ Development Tools" will fix the error, I would need to test that on my JBDS 7.0.1/SpringIDE 3.3 set up.
> Multiple Spring AOP problems when travel example is imported
> ------------------------------------------------------------
>
> Key: JBDS-2719
> URL: https://issues.jboss.org/browse/JBDS-2719
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: 3rd-party-certification, upstream
> Affects Versions: 7.0.0.GA
> Environment: JBDS 7.0.0.GA, L64, Spring IDE 3.3 installed from JBoss Central
> Reporter: Jiri Peterka
> Assignee: Nick Boldt
> Fix For: 7.1.0.Beta1
>
>
> There are Multiple Spring AOP Errors after travel example is imported:
> {code}
> Build path is incomplete. Cannot find class file for org/aspectj/weaver/reflect/ReflectionWorld$ReflectionWorldException
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
4 months
[JBoss JIRA] (JBIDE-25438) Refactor CDK itests to be more stable against CDK starts that fail sometimes
by Ondrej Dockal (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25438?page=com.atlassian.jira.plugi... ]
Ondrej Dockal updated JBIDE-25438:
----------------------------------
Description:
Refactor cdk itests to avoid starting cdk over and over again in each test case which will result in better performance and health of jenkins jobs.
* repair discovery itests
* finish adding of mocking cdk binaries in unsupported cdk versions
* update suites to run faster test classes
* remove deprecated test cases
* think of skipping registration and adding one test case that will start cdk with registration
* extends shellisavailable condition to accept other error dialogs as well ("Multiple problems have occured") during adapter operations
Issues to be addressed or incidents that cause fail of job run:
* CDK-216
* JBIDE-25443
* https://status.redhat.com/incidents/s7tzh47440f5
* JBIDE-25446
was:
Refactor cdk itests to avoid starting cdk over and over again in each test case which will result in better performance and health of jenkins jobs.
* repair discovery itests
* finish adding of mocking cdk binaries in unsupported cdk versions
* update suites to run faster test classes
* remove deprecated test cases
* think of skipping registration and adding one test case that will start cdk with registration
* extends shellisavailable condition to accept other error dialogs as well ("Multiple problems have occured") during adapter operations
Issues to be addressed or incidents that cause fail of job run:
* CDK-216
* JBIDE-25443
* https://status.redhat.com/incidents/s7tzh47440f5
* https://issues.jboss.org/browse/JBIDE-25446
> Refactor CDK itests to be more stable against CDK starts that fail sometimes
> ----------------------------------------------------------------------------
>
> Key: JBIDE-25438
> URL: https://issues.jboss.org/browse/JBIDE-25438
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: integration-tests
> Affects Versions: 4.5.2.AM2
> Reporter: Ondrej Dockal
> Assignee: Ondrej Dockal
> Priority: Critical
> Fix For: 4.5.2.AM2
>
>
> Refactor cdk itests to avoid starting cdk over and over again in each test case which will result in better performance and health of jenkins jobs.
> * repair discovery itests
> * finish adding of mocking cdk binaries in unsupported cdk versions
> * update suites to run faster test classes
> * remove deprecated test cases
> * think of skipping registration and adding one test case that will start cdk with registration
> * extends shellisavailable condition to accept other error dialogs as well ("Multiple problems have occured") during adapter operations
> Issues to be addressed or incidents that cause fail of job run:
> * CDK-216
> * JBIDE-25443
> * https://status.redhat.com/incidents/s7tzh47440f5
> * JBIDE-25446
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (JBIDE-25438) Refactor CDK itests to be more stable against CDK starts that fail sometimes
by Ondrej Dockal (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25438?page=com.atlassian.jira.plugi... ]
Ondrej Dockal updated JBIDE-25438:
----------------------------------
Description:
Refactor cdk itests to avoid starting cdk over and over again in each test case which will result in better performance and health of jenkins jobs.
* repair discovery itests
* finish adding of mocking cdk binaries in unsupported cdk versions
* update suites to run faster test classes
* remove deprecated test cases
* think of skipping registration and adding one test case that will start cdk with registration
* extends shellisavailable condition to accept other error dialogs as well ("Multiple problems have occured") during adapter operations
Issues to be addressed or incidents that cause fail of job run:
* CDK-216
* JBIDE-25443
* https://status.redhat.com/incidents/s7tzh47440f5
* https://issues.jboss.org/browse/JBIDE-25446
was:
Refactor cdk itests to avoid starting cdk over and over again in each test case which will result in better performance and health of jenkins jobs.
* repair discovery itests
* finish adding of mocking cdk binaries in unsupported cdk versions
* update suites to run faster test classes
* remove deprecated test cases
* think of skipping registration and adding one test case that will start cdk with registration
* extends shellisavailable condition to accept other error dialogs as well ("Multiple problems have occured") during adapter operations
Issues to be addressed or incidents that cause fail of job run:
* CDK-216
* JBIDE-25443
* https://status.redhat.com/incidents/s7tzh47440f5
> Refactor CDK itests to be more stable against CDK starts that fail sometimes
> ----------------------------------------------------------------------------
>
> Key: JBIDE-25438
> URL: https://issues.jboss.org/browse/JBIDE-25438
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: integration-tests
> Affects Versions: 4.5.2.AM2
> Reporter: Ondrej Dockal
> Assignee: Ondrej Dockal
> Priority: Critical
> Fix For: 4.5.2.AM2
>
>
> Refactor cdk itests to avoid starting cdk over and over again in each test case which will result in better performance and health of jenkins jobs.
> * repair discovery itests
> * finish adding of mocking cdk binaries in unsupported cdk versions
> * update suites to run faster test classes
> * remove deprecated test cases
> * think of skipping registration and adding one test case that will start cdk with registration
> * extends shellisavailable condition to accept other error dialogs as well ("Multiple problems have occured") during adapter operations
> Issues to be addressed or incidents that cause fail of job run:
> * CDK-216
> * JBIDE-25443
> * https://status.redhat.com/incidents/s7tzh47440f5
> * https://issues.jboss.org/browse/JBIDE-25446
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (JBIDE-25446) Slave gets disconnected during job execution
by Ondrej Dockal (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25446?page=com.atlassian.jira.plugi... ]
Ondrej Dockal updated JBIDE-25446:
----------------------------------
Summary: Slave gets disconnected during job execution (was: Windows slave gets disconnected during job execution)
> Slave gets disconnected during job execution
> --------------------------------------------
>
> Key: JBIDE-25446
> URL: https://issues.jboss.org/browse/JBIDE-25446
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: qa
> Affects Versions: 4.5.2.AM2
> Reporter: Ondrej Dockal
> Assignee: Pavol Srna
> Priority: Critical
> Labels: jenkins
>
> During jenkins job execution slaves is disconnected with exception
> {code}
> 19:09:27 19:09:27.096 DEBUG [WorkbenchTestable][AbstractWait] Waiting until shell matching Matcher matching when all matchers match: [Matcher matching widget which text matches: "Problem Occured"] is available....
> 19:09:32 FATAL: command execution failed
> 19:09:32 java.io.IOException: Backing channel 'Channel to /10.8.247.148' is disconnected.
> 19:09:32 at hudson.remoting.RemoteInvocationHandler.channelOrFail(RemoteInvocationHandler.java:191)
> 19:09:32 at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:256)
> 19:09:32 at com.sun.proxy.$Proxy68.isAlive(Unknown Source)
> 19:09:32 at hudson.Launcher$RemoteLauncher$ProcImpl.isAlive(Launcher.java:1043)
> 19:09:32 at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:1035)
> 19:09:32 at hudson.Launcher$ProcStarter.join(Launcher.java:399)
> 19:09:32 at hudson.tasks.Maven.perform(Maven.java:367)
> 19:09:32 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
> 19:09:32 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
> 19:09:32 at hudson.model.Build$BuildExecution.build(Build.java:205)
> 19:09:32 at hudson.model.Build$BuildExecution.doRun(Build.java:162)
> 19:09:32 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
> 19:09:32 at hudson.model.Run.execute(Run.java:1728)
> 19:09:32 at hudson.matrix.MatrixRun.run(MatrixRun.java:146)
> 19:09:32 at hudson.model.ResourceController.execute(ResourceController.java:98)
> 19:09:32 at hudson.model.Executor.run(Executor.java:404)
> 19:09:32 Caused by: java.io.IOException: Connection aborted: org.jenkinsci.remoting.nio.NioChannelHub$MonoNioTransport@5af9151e[name=Channel to /10.8.247.148]
> 19:09:32 at org.jenkinsci.remoting.nio.NioChannelHub$NioTransport.abort(NioChannelHub.java:210)
> 19:09:32 at org.jenkinsci.remoting.nio.NioChannelHub.run(NioChannelHub.java:635)
> 19:09:32 at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
> 19:09:32 at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 19:09:32 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 19:09:32 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 19:09:32 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 19:09:32 at java.lang.Thread.run(Thread.java:748)
> 19:09:32 Caused by: java.io.IOException: Connection reset by peer
> 19:09:32 at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> 19:09:32 at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> 19:09:32 at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> 19:09:32 at sun.nio.ch.IOUtil.read(IOUtil.java:197)
> 19:09:32 at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
> 19:09:32 at org.jenkinsci.remoting.nio.FifoBuffer$Pointer.receive(FifoBuffer.java:142)
> 19:09:32 at org.jenkinsci.remoting.nio.FifoBuffer.receive(FifoBuffer.java:359)
> 19:09:32 at org.jenkinsci.remoting.nio.NioChannelHub.run(NioChannelHub.java:564)
> 19:09:32 ... 6 more
> 19:09:32 Build step 'Invoke top-level Maven targets' marked build as failure
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months