[JBoss JIRA] (JBIDE-17736) org.jboss.tools.seam.xml.test.SeamXMLAllTests failure
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17736?page=com.atlassian.jira.plugi... ]
Alexey Kazakov reassigned JBIDE-17736:
--------------------------------------
Assignee: Viacheslav Kabanovich
> org.jboss.tools.seam.xml.test.SeamXMLAllTests failure
> -----------------------------------------------------
>
> Key: JBIDE-17736
> URL: https://issues.jboss.org/browse/JBIDE-17736
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: seam2
> Affects Versions: 4.2.0.Beta3
> Reporter: Daniel Azarov
> Assignee: Viacheslav Kabanovich
> Fix For: 4.2.0.CR1
>
>
> {code}
> -------------------------------------------------------------------------------
> Test set: org.jboss.tools.seam.xml.test.SeamXMLAllTests
> -------------------------------------------------------------------------------
> Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.651 sec <<< FAILURE!
> testDebugAttribute(org.jboss.tools.seam.xml.test.SeamXMLModelTest) Time elapsed: 1.878 sec <<< FAILURE!
> junit.framework.AssertionFailedError: Validator failed to report an error in component org.jboss.seam.core.init1
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at org.jboss.tools.seam.xml.test.SeamXMLModelTest.testDebugAttribute(SeamXMLModelTest.java:108)
> 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:601)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.extensions.TestSetup.run(TestSetup.java:27)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
> 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:601)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:123)
> at org.eclipse.tycho.surefire.osgibooter.OsgiSurefireBooter.run(OsgiSurefireBooter.java:86)
> at org.eclipse.tycho.surefire.osgibooter.AbstractUITestApplication$1.run(AbstractUITestApplication.java:35)
> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
> at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:136)
> at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3806)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3444)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135)
> at org.eclipse.tycho.surefire.osgibooter.UITestApplication.runApplication(UITestApplication.java:31)
> at org.eclipse.tycho.surefire.osgibooter.AbstractUITestApplication.run(AbstractUITestApplication.java:114)
> at org.eclipse.tycho.surefire.osgibooter.UITestApplication.start(UITestApplication.java:37)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:236)
> 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:601)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
> testComponentFile(org.jboss.tools.seam.xml.test.SeamXMLModelTest) Time elapsed: 0.001 sectestNavigationPagesComponent(org.jboss.tools.seam.xml.test.SeamXMLModelTest) Time elapsed: 0.001 sectestXMLModel(org.jboss.tools.seam.xml.test.SeamXMLModelTest) Time elapsed: 0.001 sectestXML23Model(org.jboss.tools.seam.xml.test.SeamXMLModelTest) Time elapsed: 0.033 sec
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years
[JBoss JIRA] (JBIDE-17736) org.jboss.tools.seam.xml.test.SeamXMLAllTests failure
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17736?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-17736:
-----------------------------------
Fix Version/s: 4.2.0.CR1
> org.jboss.tools.seam.xml.test.SeamXMLAllTests failure
> -----------------------------------------------------
>
> Key: JBIDE-17736
> URL: https://issues.jboss.org/browse/JBIDE-17736
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: seam2
> Affects Versions: 4.2.0.Beta3
> Reporter: Daniel Azarov
> Assignee: Viacheslav Kabanovich
> Fix For: 4.2.0.CR1
>
>
> {code}
> -------------------------------------------------------------------------------
> Test set: org.jboss.tools.seam.xml.test.SeamXMLAllTests
> -------------------------------------------------------------------------------
> Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.651 sec <<< FAILURE!
> testDebugAttribute(org.jboss.tools.seam.xml.test.SeamXMLModelTest) Time elapsed: 1.878 sec <<< FAILURE!
> junit.framework.AssertionFailedError: Validator failed to report an error in component org.jboss.seam.core.init1
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at org.jboss.tools.seam.xml.test.SeamXMLModelTest.testDebugAttribute(SeamXMLModelTest.java:108)
> 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:601)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.extensions.TestSetup.run(TestSetup.java:27)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
> 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:601)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:123)
> at org.eclipse.tycho.surefire.osgibooter.OsgiSurefireBooter.run(OsgiSurefireBooter.java:86)
> at org.eclipse.tycho.surefire.osgibooter.AbstractUITestApplication$1.run(AbstractUITestApplication.java:35)
> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
> at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:136)
> at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3806)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3444)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135)
> at org.eclipse.tycho.surefire.osgibooter.UITestApplication.runApplication(UITestApplication.java:31)
> at org.eclipse.tycho.surefire.osgibooter.AbstractUITestApplication.run(AbstractUITestApplication.java:114)
> at org.eclipse.tycho.surefire.osgibooter.UITestApplication.start(UITestApplication.java:37)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:236)
> 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:601)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
> testComponentFile(org.jboss.tools.seam.xml.test.SeamXMLModelTest) Time elapsed: 0.001 sectestNavigationPagesComponent(org.jboss.tools.seam.xml.test.SeamXMLModelTest) Time elapsed: 0.001 sectestXMLModel(org.jboss.tools.seam.xml.test.SeamXMLModelTest) Time elapsed: 0.001 sectestXML23Model(org.jboss.tools.seam.xml.test.SeamXMLModelTest) Time elapsed: 0.033 sec
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years
[JBoss JIRA] (JBIDE-17700) Cannot deploy jsf war with eclipse luna and jboss 7.1.x
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17700?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-17700:
-------------------------------------
[~fbricon] I might need your help on determining if m2e is somehow at fault here.
[~olpf] Can you do a grep on your eclipse installation to see if any other plugins have classworlds in it or is using it? grep -R "classworlds" * should be sufficient. In my installation, only m2e matches.
> Cannot deploy jsf war with eclipse luna and jboss 7.1.x
> -------------------------------------------------------
>
> Key: JBIDE-17700
> URL: https://issues.jboss.org/browse/JBIDE-17700
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Environment: Win 7, Eclilpse Luna, JBoss Tools (via market place)
> Reporter: Oliver Pfau
> Priority: Critical
>
> When I publish my war to jboss 7.1 the following error occurs:
> An internal error occurred during: "Publishing to JBoss AS 7.1...".
> Could not initialize class de.schlichtherle.io.ArchiveControllers
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years
[JBoss JIRA] (JBIDE-17700) Cannot deploy jsf war with eclipse luna and jboss 7.1.x
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17700?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-17700:
-------------------------------------
I actually can't think of *ANY* reason at all why any thread running in eclipse would have org.codehaus.plexus.classworlds.realm.ClassRealm as its class loader. It would seem to me that eclipse, as an osgi-container basically, should be in charge of the classloaders entirely.
I did a grep on my installation's "plugins" folder, and the only plugins that seem to mention org.codehaus.plexus.classworlds is org.eclipse.m2e.maven.runtime_1.5.0.20140505-1310
Is m2e behaving badly here? Is it setting its classloader and not putting it back?
> Cannot deploy jsf war with eclipse luna and jboss 7.1.x
> -------------------------------------------------------
>
> Key: JBIDE-17700
> URL: https://issues.jboss.org/browse/JBIDE-17700
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Environment: Win 7, Eclilpse Luna, JBoss Tools (via market place)
> Reporter: Oliver Pfau
> Priority: Critical
>
> When I publish my war to jboss 7.1 the following error occurs:
> An internal error occurred during: "Publishing to JBoss AS 7.1...".
> Could not initialize class de.schlichtherle.io.ArchiveControllers
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years
[JBoss JIRA] (JBDS-3071) JBDS Installer shouldn't contain source features/plugins
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3071?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-3071:
-------------------------------------
{quote}b) put these 3 features in the installer so that the installer contents == the update site contents (except for sources){quote}
This is not needed, because first, even if you add them it doesn't make installer content the same as update site content, second, installer's update site used to materialize product during installation is never used after taht, so if additional features required they going to be installed from remote JBDS p2 repository.
Please, revert PR https://github.com/jbdevstudio/jbdevstudio-product/pull/202.
> JBDS Installer shouldn't contain source features/plugins
> --------------------------------------------------------
>
> Key: JBDS-3071
> URL: https://issues.jboss.org/browse/JBDS-3071
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: installer
> Affects Versions: 8.0.0.Beta2
> Reporter: Fred Bricon
> Assignee: Nick Boldt
>
> {quote}
> So the basic JBDS installer is 70MB fatter. From my understanding it's because we now ship a *huge* forge2 runtime (50MB), Tern, the JVM Monitor and probably some other minor stuff.
> Fair enough. But do we *really* need to add all the source features/plugins to the installer? *If* we're legally bound to provide sources for JBoss plugins, couldn't we provide them via an other way? (p2 only).
> I reckon we could save ~37 MB by not shipping sources in the installer. I know storage is cheap and d/l speeds are faster but that's not an excuse.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years
[JBoss JIRA] (JBIDE-17700) Cannot deploy jsf war with eclipse luna and jboss 7.1.x
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17700?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-17700:
-------------------------------------
The code that is being run to find the class is:
{code}
public static synchronized KeyManager getInstance() {
if (keyManager != null)
return keyManager;
final String cn = System.getProperty(
"de.schlichtherle.key.KeyManager",
getDefaultKeyManagerClassName());
try {
final Class c = Thread.currentThread()
.getContextClassLoader().loadClass(cn);
keyManager = (KeyManager) c.newInstance();
} catch (RuntimeException ex) {
throw ex;
} catch (Exception ex) {
throw new UndeclaredThrowableException(ex);
}
return keyManager;
}
{code}
I can't know for sure why this is happening, but, let's assume that the publish event is starting in a Job, and jobs are run by workers. Perhaps archives.core should be sure to 'start' when any of its classes are referenced, and archives.core's start method should be sure to initialize the framework properly?
> Cannot deploy jsf war with eclipse luna and jboss 7.1.x
> -------------------------------------------------------
>
> Key: JBIDE-17700
> URL: https://issues.jboss.org/browse/JBIDE-17700
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Environment: Win 7, Eclilpse Luna, JBoss Tools (via market place)
> Reporter: Oliver Pfau
> Priority: Critical
>
> When I publish my war to jboss 7.1 the following error occurs:
> An internal error occurred during: "Publishing to JBoss AS 7.1...".
> Could not initialize class de.schlichtherle.io.ArchiveControllers
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years
[JBoss JIRA] (JBIDE-17700) Cannot deploy jsf war with eclipse luna and jboss 7.1.x
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17700?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-17700:
-------------------------------------
So... I've come nowhere in terms of replication, but I think it's pretty clear the issue isn't related to signed jars or anytthing of that nature. This is all done when truezip is initializing itself. The Servertools publishers issue a truezip.umount() command to start. This command basically tells truezip to write any changes it has to disk, but the evidence shows pretty strongly that this is the first call done to the framework, and it hasn't yet initialized.
Execution flows to KeyManager.getInstance(), which is just one of the initialization steps in TrueZip.
Here's the juicy part:
{code}
ContextFinder.loadClass(String, boolean) line: 119
ContextFinder(ClassLoader).loadClass(String) line: 358
KeyManager.getInstance() line: 117
ArchiveControllers$ShutdownHook.<init>() line: 388
{code}
This is the stacktrace *I* see. It's not using org.codehaus.plexus.classworlds.realm.ClassRealm to load the class when *I* run it in my unit tests or when I trace through my workspace, but in your stacktrace, it is, and the org.codehaus.plexus.classworlds.realm.ClassRealm classloader can't find the class it needs to initialize properly.
That's all I've got for now though.
> Cannot deploy jsf war with eclipse luna and jboss 7.1.x
> -------------------------------------------------------
>
> Key: JBIDE-17700
> URL: https://issues.jboss.org/browse/JBIDE-17700
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Environment: Win 7, Eclilpse Luna, JBoss Tools (via market place)
> Reporter: Oliver Pfau
> Priority: Critical
>
> When I publish my war to jboss 7.1 the following error occurs:
> An internal error occurred during: "Publishing to JBoss AS 7.1...".
> Could not initialize class de.schlichtherle.io.ArchiveControllers
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years
[JBoss JIRA] (JBDS-3071) JBDS Installer shouldn't contain source features/plugins
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3071?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-3071:
-------------------------------------
IMO they should not be added nether to pom.xml for mirroring not to product feature, fact is they never were installed as through installer.jar. Installer materialize only JBDS Branded Product Feature and nothing else. They just add weight to installer jar :)
> JBDS Installer shouldn't contain source features/plugins
> --------------------------------------------------------
>
> Key: JBDS-3071
> URL: https://issues.jboss.org/browse/JBDS-3071
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: installer
> Affects Versions: 8.0.0.Beta2
> Reporter: Fred Bricon
> Assignee: Nick Boldt
> Fix For: 8.0.0.Beta3
>
>
> {quote}
> So the basic JBDS installer is 70MB fatter. From my understanding it's because we now ship a *huge* forge2 runtime (50MB), Tern, the JVM Monitor and probably some other minor stuff.
> Fair enough. But do we *really* need to add all the source features/plugins to the installer? *If* we're legally bound to provide sources for JBoss plugins, couldn't we provide them via an other way? (p2 only).
> I reckon we could save ~37 MB by not shipping sources in the installer. I know storage is cheap and d/l speeds are faster but that's not an excuse.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years