[JBoss JIRA] (JBIDE-16308) Cannot start JBT 4.2.0.Alpha1 on Fedora 19
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16308?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-16308:
-------------------------------
Attachment: hs_err_pid17371.log
> Cannot start JBT 4.2.0.Alpha1 on Fedora 19
> ------------------------------------------
>
> Key: JBIDE-16308
> URL: https://issues.jboss.org/browse/JBIDE-16308
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.2.0.Alpha1
> Environment: JBT 4.2.Alpha1, L64, Fedora 19, 64-bit, Open JDK 1.7
> Reporter: Jiri Peterka
> Priority: Blocker
> Fix For: 4.2.0.Alpha1
>
> Attachments: hs_err_pid17371.log
>
>
> Installing JBT on Eclipse -4.4.M4- 4.4.M3 JEE package (linux_64), after JBT installation update site and restart I have:
> {code}
> !ENTRY org.eclipse.osgi 4 0 2013-12-16 15:35:03.535
> !MESSAGE FrameworkEvent ERROR
> !STACK 0
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.util.ArrayList.iterator(ArrayList.java:814)
> at org.apache.felix.resolver.ResolverImpl.mergeUses(ResolverImpl.java:962)
> at org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:787)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:252)
> at org.eclipse.osgi.container.ModuleResolver$ResolveProcess.resolve(ModuleResolver.java:652)
> at org.eclipse.osgi.container.ModuleResolver.resolveDelta(ModuleResolver.java:75)
> at org.eclipse.osgi.container.ModuleContainer.resolveAndApply(ModuleContainer.java:454)
> at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:412)
> at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:402)
> at org.eclipse.osgi.container.Module.start(Module.java:406)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1530)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1510)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1481)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1424)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
> at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
> {code}
> Even if I raise a memory for JVM, Eclipse doesn't start but not error message is written
--
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
12 years, 4 months
[JBoss JIRA] (JBIDE-16308) Cannot start JBT 4.2.0.Alpha1 on Fedora 19
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16308?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-16308:
----------------------------------------
Could it be related to http://www.youtube.com/watch?v=IAZenG98E38 ?
> Cannot start JBT 4.2.0.Alpha1 on Fedora 19
> ------------------------------------------
>
> Key: JBIDE-16308
> URL: https://issues.jboss.org/browse/JBIDE-16308
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.2.0.Alpha1
> Environment: JBT 4.2.Alpha1, L64, Fedora 19, 64-bit, Open JDK 1.7
> Reporter: Jiri Peterka
> Priority: Blocker
> Fix For: 4.2.0.Alpha1
>
>
> Installing JBT on Eclipse -4.4.M4- 4.4.M3 JEE package (linux_64), after JBT installation update site and restart I have:
> {code}
> !ENTRY org.eclipse.osgi 4 0 2013-12-16 15:35:03.535
> !MESSAGE FrameworkEvent ERROR
> !STACK 0
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.util.ArrayList.iterator(ArrayList.java:814)
> at org.apache.felix.resolver.ResolverImpl.mergeUses(ResolverImpl.java:962)
> at org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:787)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:252)
> at org.eclipse.osgi.container.ModuleResolver$ResolveProcess.resolve(ModuleResolver.java:652)
> at org.eclipse.osgi.container.ModuleResolver.resolveDelta(ModuleResolver.java:75)
> at org.eclipse.osgi.container.ModuleContainer.resolveAndApply(ModuleContainer.java:454)
> at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:412)
> at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:402)
> at org.eclipse.osgi.container.Module.start(Module.java:406)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1530)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1510)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1481)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1424)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
> at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
> {code}
> Even if I raise a memory for JVM, Eclipse doesn't start but not error message is written
--
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
12 years, 4 months
[JBoss JIRA] (JBIDE-16308) Cannot start JBT 4.2.0.Alpha1 on Fedora 19
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16308?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-16308:
------------------------------------
I can reproduce this on Fedora 18 using this launch script for Eclipse 4.4.M3 Standard (not JEE) bundle, installing ALL categorized features from http://download.jboss.org/jbosstools/updates/JBossTools-4.2.0.Alpha1.core/.
{code}
$➔ uname -a
Linux thunk 3.11.9-100.fc18.x86_64 #1 SMP Wed Nov 20 21:22:39 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
$➔ /opt/sun-java2-7.0/bin/java -version
java version "1.7.0_17"
Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
{code}
{code}
#!/bin/bash
workspace=/home/nboldt/eclipse/workspace-clean44
target=/home/nboldt/eclipse/44clean
eclipse=/home/nboldt/tmp/Eclipse_Bundles/eclipse-standard-luna-M3-linux-gtk-x86_64.tar.gz
cd ${target}
if [[ $1 == "e" ]]; then
echo "Wipe $target/eclipse and $workspace ..."
rm -fr $target/eclipse $workspace
echo "Unpack $eclipse ..."
tar xzf $eclipse
shift
fi
#export GDK_NATIVE_WINDOWS=true
${target}/eclipse/eclipse -clean -showLocation -data $workspace -consolelog -console -vm /opt/sun-java2-7.0/bin/java "$*" 2>&1 | tee "logs/eclipse.log.`date`.txt"
{code}
After installation and warm restart, I get this:
{code}
Wipe /home/nboldt/eclipse/44clean/eclipse and /home/nboldt/eclipse/workspace-clean44 ...
Unpack /home/nboldt/tmp/Eclipse_Bundles/eclipse-standard-luna-M3-linux-gtk-x86_64.tar.gz ...
osgi> osgi> #
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f7e952f2255, pid=15646, tid=140184237340416
#
# JRE version: 7.0_17-b02
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.7-b01 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libxul.so+0xc81255] JSD_DebuggerOnForUser+0x978a2
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/nboldt/eclipse/43clean/hs_err_pid15646.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
{code}
Same crash occurs for a cold restart, though it may take over a minute for the crash to occur.
> Cannot start JBT 4.2.0.Alpha1 on Fedora 19
> ------------------------------------------
>
> Key: JBIDE-16308
> URL: https://issues.jboss.org/browse/JBIDE-16308
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.2.0.Alpha1
> Environment: JBT 4.2.Alpha1, L64, Fedora 19, 64-bit, Open JDK 1.7
> Reporter: Jiri Peterka
> Priority: Blocker
> Fix For: 4.2.0.Alpha1
>
>
> Installing JBT on Eclipse -4.4.M4- 4.4.M3 JEE package (linux_64), after JBT installation update site and restart I have:
> {code}
> !ENTRY org.eclipse.osgi 4 0 2013-12-16 15:35:03.535
> !MESSAGE FrameworkEvent ERROR
> !STACK 0
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.util.ArrayList.iterator(ArrayList.java:814)
> at org.apache.felix.resolver.ResolverImpl.mergeUses(ResolverImpl.java:962)
> at org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:787)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:252)
> at org.eclipse.osgi.container.ModuleResolver$ResolveProcess.resolve(ModuleResolver.java:652)
> at org.eclipse.osgi.container.ModuleResolver.resolveDelta(ModuleResolver.java:75)
> at org.eclipse.osgi.container.ModuleContainer.resolveAndApply(ModuleContainer.java:454)
> at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:412)
> at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:402)
> at org.eclipse.osgi.container.Module.start(Module.java:406)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1530)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1510)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1481)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1424)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
> at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
> {code}
> Even if I raise a memory for JVM, Eclipse doesn't start but not error message is written
--
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
12 years, 4 months
[JBoss JIRA] (JBIDE-16309) Move inter-JBT dependencies to component poms
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16309?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-16309:
----------------------------------------
{quote}Should jbosstools-site-stream be set in each root pom rather than in parent pom so as to break the link/dependency on that definition?{quote}
I believe that's something we can consider for the (near) future. But I feel that for now, it's still safer if we take care of the stream in the parent pom. The change I'm suggesting doesn't require component leads to change their habits for now.
IMO, moving jbosstools-site-stream to projects should be another increment once we've applied and validated this one. And next one could be to let project leads fully take care of their dependencies.
> Move inter-JBT dependencies to component poms
> ---------------------------------------------
>
> Key: JBIDE-16309
> URL: https://issues.jboss.org/browse/JBIDE-16309
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: 4.2.0.Alpha2
>
>
> It has been discussed several times that the composite site is a kind of "weak point" in our build chain, because it allows cyclic dependencies, and it also introduces indirections that make it less straightforward to find out what a project should/does depend on to build.
> The benefit of composite now seem a bit light: it's cool because we can put it in parent pom and all builds succeed to get there dependencies, but out of that, there hasn't been much other use-cases. And as we want to provide more and more autonomy to project, this composite site they'd depend on is something that doesn't make them autonomous.
> So the idea is to move dependencies to project root poms. I've made a draft of how it would look like in project pom if we remove the "jbosstools-site" from parent pom and let projects manage their inter-dependencies: https://github.com/mickaelistria/jbosstools-javaee/tree/JBIDE-16309
> You can try this by running "mvn clean verify -P\!jbosstools-site". The "-P\!jbosstools-site" disable the jbosstools-site profile, which is the one controlling addition of the composite or ggregate to the resolver
> https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml...
--
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
12 years, 4 months
[JBoss JIRA] (JBIDE-16309) Move inter-JBT dependencies to component poms
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16309?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-16309:
------------------------------------
Should jbosstools-site-stream be set in each root pom rather than in parent pom so as to break the link/dependency on that definition?
That way the onus is on the project lead to, after branching, set the correct value of jbosstools-site-stream=4.2.luna or jbosstools-site-stream=master so they'll build against the correct upstream stack.
Admittedly it's one more step for leads to remember to do when we branch, AND it complicates a move to the "tag and move on in the same branch" workflow, because you'd have to either:
a) change that value to jbosstools-site-stream=4.2.luna, tag, change it back to jbosstools-site-stream=master, and continue
- or -
b) always use jbosstools-site-stream=master, but use commandline override when building locally or in Jenkins for the non-master jobs (formerly _42, now _4.2.luna).
But it also separates further the dependency that projects have on the parent pom.
> Move inter-JBT dependencies to component poms
> ---------------------------------------------
>
> Key: JBIDE-16309
> URL: https://issues.jboss.org/browse/JBIDE-16309
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: 4.2.0.Alpha2
>
>
> It has been discussed several times that the composite site is a kind of "weak point" in our build chain, because it allows cyclic dependencies, and it also introduces indirections that make it less straightforward to find out what a project should/does depend on to build.
> The benefit of composite now seem a bit light: it's cool because we can put it in parent pom and all builds succeed to get there dependencies, but out of that, there hasn't been much other use-cases. And as we want to provide more and more autonomy to project, this composite site they'd depend on is something that doesn't make them autonomous.
> So the idea is to move dependencies to project root poms. I've made a draft of how it would look like in project pom if we remove the "jbosstools-site" from parent pom and let projects manage their inter-dependencies: https://github.com/mickaelistria/jbosstools-javaee/tree/JBIDE-16309
> You can try this by running "mvn clean verify -P\!jbosstools-site". The "-P\!jbosstools-site" disable the jbosstools-site profile, which is the one controlling addition of the composite or ggregate to the resolver
> https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml...
--
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
12 years, 4 months
[JBoss JIRA] (JBIDE-16309) Move inter-JBT dependencies to component poms
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16309?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-16309:
-----------------------------------
Description:
It has been discussed several times that the composite site is a kind of "weak point" in our build chain, because it allows cyclic dependencies, and it also introduces indirections that make it less straightforward to find out what a project should/does depend on to build.
The benefit of composite now seem a bit light: it's cool because we can put it in parent pom and all builds succeed to get there dependencies, but out of that, there hasn't been much other use-cases. And as we want to provide more and more autonomy to project, this composite site they'd depend on is something that doesn't make them autonomous.
So the idea is to move dependencies to project root poms. I've made a draft of how it would look like in project pom if we remove the "jbosstools-site" from parent pom and let projects manage their inter-dependencies: https://github.com/mickaelistria/jbosstools-javaee/tree/JBIDE-16309
You can try this by running "mvn clean verify -P\!jbosstools-site". The "-P\!jbosstools-site" disable the jbosstools-site profile, which is the one controlling addition of the composite or ggregate to the resolver
https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml...
was:
It has been discussed several times that the composite site is a kind
of "weak point" in our build chain, because it allows cyclic
dependencies, and it also introduces indirections that make it less
straightforward to find out what a project should/does depend on to build.
The benefit of composite now seem a bit light: it's cool because we
can put it in parent pom and all builds succeed to get there
dependencies, but out of that, there hasn't been much other use-cases.
And as we want to provide more and more autonomy to project, this
composite site they'd depend on is something that doesn't make them
autonomous.
So the idea is to move dependencies to project root poms. I've made a
draft of how it would look like in project pom if we remove the
"jbosstools-site" from parent pom and let projects manage their
inter-dependencies:
https://github.com/mickaelistria/jbosstools-javaee/commit/bf288fd288331c7...
You can try this by running "mvn clean verify -P\!jbosstools-site".
The "-P\!jbosstools-site" disable the jbosstools-site profile, which
is the one controlling addition of the composite or aggregate to the
resolver
https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml...
> Move inter-JBT dependencies to component poms
> ---------------------------------------------
>
> Key: JBIDE-16309
> URL: https://issues.jboss.org/browse/JBIDE-16309
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: 4.2.0.Alpha2
>
>
> It has been discussed several times that the composite site is a kind of "weak point" in our build chain, because it allows cyclic dependencies, and it also introduces indirections that make it less straightforward to find out what a project should/does depend on to build.
> The benefit of composite now seem a bit light: it's cool because we can put it in parent pom and all builds succeed to get there dependencies, but out of that, there hasn't been much other use-cases. And as we want to provide more and more autonomy to project, this composite site they'd depend on is something that doesn't make them autonomous.
> So the idea is to move dependencies to project root poms. I've made a draft of how it would look like in project pom if we remove the "jbosstools-site" from parent pom and let projects manage their inter-dependencies: https://github.com/mickaelistria/jbosstools-javaee/tree/JBIDE-16309
> You can try this by running "mvn clean verify -P\!jbosstools-site". The "-P\!jbosstools-site" disable the jbosstools-site profile, which is the one controlling addition of the composite or ggregate to the resolver
> https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml...
--
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
12 years, 4 months
[JBoss JIRA] (JBDS-2745) Support installation of Early Access / Experimental / Incubating plugins
by Paul Leacu (JIRA)
[ https://issues.jboss.org/browse/JBDS-2745?page=com.atlassian.jira.plugin.... ]
Paul Leacu commented on JBDS-2745:
----------------------------------
Although I really like the idea of rolling new IS content through "Tech Preview" - I don't think we should roll with the 7.0.0.CR1 JBDSIS capture. There were significant issues found by QE in bpmn2, SwitchYard and Fuse and teiid has a bunch of fixes pending as well. I'd say lets wait for the JBDSIS 7.0.0.GA that has these issue addressed for a more favorable initial impression.
> Support installation of Early Access / Experimental / Incubating plugins
> ------------------------------------------------------------------------
>
> Key: JBDS-2745
> URL: https://issues.jboss.org/browse/JBDS-2745
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: central, requirements
> Affects Versions: 7.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Burr Sutter
>
> It's been suggested that it would be nice to have Central available to install non-GA content. How might this appear?
> [~burrsutter], [~maxandersen], are we talking about:
> * an additional dialog warning users about untested content? (that might be ignored / blindclicked)
> * an additional tab in Central for this type of content (what label would you use?)
> * relabelling the content's feature descriptions / titles / copyright / license terms to be clear it's unstable content? (might be ignored)
> * some other workflow?
> See also JBDS-2068.
--
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
12 years, 4 months
[JBoss JIRA] (JBIDE-16309) Move inter-JBT dependencies to component poms
by Mickael Istria (JIRA)
Mickael Istria created JBIDE-16309:
--------------------------------------
Summary: Move inter-JBT dependencies to component poms
Key: JBIDE-16309
URL: https://issues.jboss.org/browse/JBIDE-16309
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: build
Reporter: Mickael Istria
Assignee: Mickael Istria
Fix For: 4.2.0.Alpha2
It has been discussed several times that the composite site is a kind
of "weak point" in our build chain, because it allows cyclic
dependencies, and it also introduces indirections that make it less
straightforward to find out what a project should/does depend on to build.
The benefit of composite now seem a bit light: it's cool because we
can put it in parent pom and all builds succeed to get there
dependencies, but out of that, there hasn't been much other use-cases.
And as we want to provide more and more autonomy to project, this
composite site they'd depend on is something that doesn't make them
autonomous.
So the idea is to move dependencies to project root poms. I've made a
draft of how it would look like in project pom if we remove the
"jbosstools-site" from parent pom and let projects manage their
inter-dependencies:
https://github.com/mickaelistria/jbosstools-javaee/commit/bf288fd288331c7...
You can try this by running "mvn clean verify -P\!jbosstools-site".
The "-P\!jbosstools-site" disable the jbosstools-site profile, which
is the one controlling addition of the composite or aggregate to the
resolver
https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml...
--
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
12 years, 4 months
[JBoss JIRA] (JBIDE-14522) Arquillian Cruiser content view should link back to source view
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14522?page=com.atlassian.jira.plugi... ]
Snjezana Peco commented on JBIDE-14522:
---------------------------------------
I suppose you want to open a file when you double-click it.
> Arquillian Cruiser content view should link back to source view
> ---------------------------------------------------------------
>
> Key: JBIDE-14522
> URL: https://issues.jboss.org/browse/JBIDE-14522
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: testing-tools
> Reporter: Aslak Knutsen
> Assignee: Snjezana Peco
> Fix For: 4.2.0.Alpha2
>
>
> {code}
> @RunWith(Arquillian.class)
> class MangerTest {
> @Deployment
> public Archive<?> create() {
> return ShrinkWrap.create(JavaArchive.class).addClass(MyClass.class);
> }
> }
> {code}
> Given this code snippet, the Arquillian Cruiser deployment Archive overview will show a similar structure to:
> {code}
> ManagerTest
> - create
> org
> my
> MyClass.class
> {code}
> The MyClass.class line in the overview should link back to the source view of MyClass.java.
--
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
12 years, 4 months