[JBoss JIRA] (JBIDE-18837) because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18837?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-18837:
---------------------------------------------
The part about ide-config.properties need testing I've put a PR for at JBIDE-18848.
> because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-18837
> URL: https://issues.jboss.org/browse/JBIDE-18837
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, central, common/jst/core, project-examples
> Affects Versions: 4.2.1.CR1
> Reporter: Nick Boldt
> Fix For: 4.3.0.Alpha1
>
>
> When updating from 4.2.0 to 4.2.1, a user might decide to only update Central or Project Examples, and NOT update Foundation.core, which means his Eclipse will still think it's 4.2.0, not 4.2.1, and he might get the wrong version of central/examples.
> Therefore we need manifest-level [4.2.1,) requirements on upstream foundation.core in examples and central, to force this lock-step updating.
> And we need to use the maven enforcer plugin to fail the build if these versions get out of sync.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18848) setup tests for ide-config.properties
by Max Rydahl Andersen (JIRA)
Max Rydahl Andersen created JBIDE-18848:
-------------------------------------------
Summary: setup tests for ide-config.properties
Key: JBIDE-18848
URL: https://issues.jboss.org/browse/JBIDE-18848
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Reporter: Max Rydahl Andersen
JBIDE-18837 and other jiras showed that ide-config.properties risk having errors introduced into it.
we should have a test that runs every day to check if it is still consistent.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18837) because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18837?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-18837:
---------------------------------------------
[~nickboldt] we have been linking our test builds to different version of central/examples/EA through most if not all of our majority test phase thus that comment is just factually false.
The only time this could actually happen is if a user/QE/dev *Explicitly* goes and install a *subpart* of jbosstools and go out of his ways to make sure he does not have the latest update to foundation.
JBT already looks for specific versions. There is no need to introduce -D flags.
It should be sufficient to just have:
jboss.discovery.site.url|jbosstools|4.2=http://download.jboss.org/jbossto...
jboss.discovery.site.url|jbosstools|4.2.1.CR1=http://download.jboss.org/j...
or if you want nightlies to pick up latest development no matter what:
jboss.discovery.site.url|jbosstools|4.2=http://download.jboss.org/jbossto...
jboss.discovery.site.url|jbosstools|4.2.0=http://download.jboss.org/jboss...
This is what we did until now - why is that now considered possible anymore ?
The above stuff of course assumes we actually bump the version correctly but that is what we found we missed - that is now fixed. None of that requires *forceful* linking from parent pom to foundation down to the micro level.
> because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-18837
> URL: https://issues.jboss.org/browse/JBIDE-18837
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, central, common/jst/core, project-examples
> Affects Versions: 4.2.1.CR1
> Reporter: Nick Boldt
> Fix For: 4.3.0.Alpha1
>
>
> When updating from 4.2.0 to 4.2.1, a user might decide to only update Central or Project Examples, and NOT update Foundation.core, which means his Eclipse will still think it's 4.2.0, not 4.2.1, and he might get the wrong version of central/examples.
> Therefore we need manifest-level [4.2.1,) requirements on upstream foundation.core in examples and central, to force this lock-step updating.
> And we need to use the maven enforcer plugin to fail the build if these versions get out of sync.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18837) because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18837?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-18837 at 11/28/14 12:44 AM:
---------------------------------------------------------------
Net result is that during dev phase, we cannot link QE to a different version of Central/Examples/EA than the released version, because users will see their JBT 4.2.1.CR1, 4.2.1.Final, 4.2.2.\*, 4,2.3.\* as all being the same version: 4.2. Therefore when we introduce changes to Central (for example, the upcoming change to m2e-apt 1.1.1) we'll have no way to feed a JBT 4.2.1.CR1a user to a different URL for Central than the one that's live for 4.2.x users. (Actually, we'll be able to go back to using -D flags, which ya'll loved so much.)
Without the ability to cause JBT to look for different versions of Central, we have no need to have three different URLs for JBT 4.2.1.CR1a/CR2/Final [1], 4.2.1.CR1 [2], or 4.2.0.Final [3].
[1] jboss.discovery.site.url|jbosstools|4.2.1=http://download.jboss.org/jboss...
[2] jboss.discovery.site.url|jbosstools|4.2.1.CR1=http://download.jboss.org/j...
[3] jboss.discovery.site.url|jbosstools|4.2.0.Final=http://download.jboss.org...
Because, if all three think they're simply 4.2.0.Final, then they'll all fall back to [3].
was (Author: nickboldt):
Net result is that during dev phase, we cannot link QE to a different version of Central/Examples/EA than the released version, because users will see their JBT 4.2.1.CR1, 4.2.1.Final, 4.2.2.*, 4,2.3.* as all being the same version: 4.2. Therefore when we introduce changes to Central (for example, the upcoming change to m2e-apt 1.1.1) we'll have no way to feed a JBT 4.2.1.CR1a user to a different URL for Central than the one that's live for 4.2.x users. (Actually, we'll be able to go back to using -D flags, which ya'll loved so much.)
Without the ability to cause JBT to look for different versions of Central, we have no need to have three different URLs for JBT 4.2.1.CR1a/CR2/Final [1], 4.2.1.CR1 [2], or 4.2.0.Final [3].
[1] jboss.discovery.site.url|jbosstools|4.2.1=http://download.jboss.org/jboss...
[2] jboss.discovery.site.url|jbosstools|4.2.1.CR1=http://download.jboss.org/j...
[3] jboss.discovery.site.url|jbosstools|4.2.0.Final=http://download.jboss.org...
Because, if all three think they're simply 4.2.0.Final, then they'll all fall back to [3].
> because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-18837
> URL: https://issues.jboss.org/browse/JBIDE-18837
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, central, common/jst/core, project-examples
> Affects Versions: 4.2.1.CR1
> Reporter: Nick Boldt
> Fix For: 4.3.0.Alpha1
>
>
> When updating from 4.2.0 to 4.2.1, a user might decide to only update Central or Project Examples, and NOT update Foundation.core, which means his Eclipse will still think it's 4.2.0, not 4.2.1, and he might get the wrong version of central/examples.
> Therefore we need manifest-level [4.2.1,) requirements on upstream foundation.core in examples and central, to force this lock-step updating.
> And we need to use the maven enforcer plugin to fail the build if these versions get out of sync.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18837) because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18837?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-18837:
------------------------------------
Net result is that during dev phase, we cannot link QE to a different version of Central/Examples/EA than the released version, because users will see their JBT 4.2.1.CR1, 4.2.1.Final, 4.2.2.*, 4,2.3.* as all being the same version: 4.2. Therefore when we introduce changes to Central (for example, the upcoming change to m2e-apt 1.1.1) we'll have no way to feed a JBT 4.2.1.CR1a user to a different URL for Central than the one that's live for 4.2.x users. (Actually, we'll be able to go back to using -D flags, which ya'll loved so much.)
Without the ability to cause JBT to look for different versions of Central, we have no need to have three different URLs for JBT 4.2.1.CR1a/CR2/Final [1], 4.2.1.CR1 [2], or 4.2.0.Final [3].
[1] jboss.discovery.site.url|jbosstools|4.2.1=http://download.jboss.org/jboss...
[2] jboss.discovery.site.url|jbosstools|4.2.1.CR1=http://download.jboss.org/j...
[3] jboss.discovery.site.url|jbosstools|4.2.0.Final=http://download.jboss.org...
Because, if all three think they're simply 4.2.0.Final, then they'll all fall back to [3].
> because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-18837
> URL: https://issues.jboss.org/browse/JBIDE-18837
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, central, common/jst/core, project-examples
> Affects Versions: 4.2.1.CR1
> Reporter: Nick Boldt
> Fix For: 4.3.0.Alpha1
>
>
> When updating from 4.2.0 to 4.2.1, a user might decide to only update Central or Project Examples, and NOT update Foundation.core, which means his Eclipse will still think it's 4.2.0, not 4.2.1, and he might get the wrong version of central/examples.
> Therefore we need manifest-level [4.2.1,) requirements on upstream foundation.core in examples and central, to force this lock-step updating.
> And we need to use the maven enforcer plugin to fail the build if these versions get out of sync.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18366) Sometimes, EAP6/WildFly8/AS7 fails to start - Failed initializing module org.jboss.as.logging
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18366?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-18366:
-----------------------------------
Fix Version/s: 4.2.1.CR1
(was: 4.2.1.Final)
> Sometimes, EAP6/WildFly8/AS7 fails to start - Failed initializing module org.jboss.as.logging
> ---------------------------------------------------------------------------------------------
>
> Key: JBIDE-18366
> URL: https://issues.jboss.org/browse/JBIDE-18366
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.CR1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Priority: Critical
> Labels: respin-a
> Fix For: 4.2.1.CR1, 4.3.0.Alpha1
>
>
> Sometimes, right after start of the IDE, a server fails to start. When this happens, it produces something like this in the server log:
> {code}
> INFO: JBoss MSC version 1.1.5.Final-redhat-1
> Sep 17, 2014 11:27:40 AM org.jboss.as.server.ApplicationServerService start
> INFO: JBAS015899: JBoss EAP 6.3.0.GA (AS 7.4.0.Final-redhat-19) starting
> Sep 17, 2014 11:27:40 AM org.jboss.as.controller.AbstractOperationContext executeStep
> ERROR: JBAS014612: Operation ("parallel-extension-add") failed - address: ([])
> java.lang.RuntimeException: JBAS014670: Failed initializing module org.jboss.as.logging
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:111)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:611)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:489)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:290)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:285)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1132)
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:299)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:292)
> at org.jboss.as.server.ServerService.boot(ServerService.java:346)
> at org.jboss.as.server.ServerService.boot(ServerService.java:321)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:254)
> at java.lang.Thread.run(Thread.java:695)
> Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: JBAS011592: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
> at java.util.concurrent.FutureTask.get(FutureTask.java:83)
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:103)
> ... 11 more
> Caused by: java.lang.IllegalStateException: JBAS011592: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
> at org.jboss.as.logging.LoggingExtension.initialize(LoggingExtension.java:106)
> at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:97)
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:139)
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:125)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:695)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Sep 17, 2014 11:27:40 AM org.jboss.as.server.ServerService boot
> FATAL: JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> Unfortunately I don't have a reliable way to reproduce this. It happened to me like 3 times over the last few days.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18366) Sometimes, EAP6/WildFly8/AS7 fails to start - Failed initializing module org.jboss.as.logging
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18366?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-18366:
-----------------------------------
Labels: respin-a (was: )
> Sometimes, EAP6/WildFly8/AS7 fails to start - Failed initializing module org.jboss.as.logging
> ---------------------------------------------------------------------------------------------
>
> Key: JBIDE-18366
> URL: https://issues.jboss.org/browse/JBIDE-18366
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.CR1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Priority: Critical
> Labels: respin-a
> Fix For: 4.2.1.CR1, 4.3.0.Alpha1
>
>
> Sometimes, right after start of the IDE, a server fails to start. When this happens, it produces something like this in the server log:
> {code}
> INFO: JBoss MSC version 1.1.5.Final-redhat-1
> Sep 17, 2014 11:27:40 AM org.jboss.as.server.ApplicationServerService start
> INFO: JBAS015899: JBoss EAP 6.3.0.GA (AS 7.4.0.Final-redhat-19) starting
> Sep 17, 2014 11:27:40 AM org.jboss.as.controller.AbstractOperationContext executeStep
> ERROR: JBAS014612: Operation ("parallel-extension-add") failed - address: ([])
> java.lang.RuntimeException: JBAS014670: Failed initializing module org.jboss.as.logging
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:111)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:611)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:489)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:290)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:285)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1132)
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:299)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:292)
> at org.jboss.as.server.ServerService.boot(ServerService.java:346)
> at org.jboss.as.server.ServerService.boot(ServerService.java:321)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:254)
> at java.lang.Thread.run(Thread.java:695)
> Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: JBAS011592: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
> at java.util.concurrent.FutureTask.get(FutureTask.java:83)
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:103)
> ... 11 more
> Caused by: java.lang.IllegalStateException: JBAS011592: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
> at org.jboss.as.logging.LoggingExtension.initialize(LoggingExtension.java:106)
> at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:97)
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:139)
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:125)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:695)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Sep 17, 2014 11:27:40 AM org.jboss.as.server.ServerService boot
> FATAL: JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> Unfortunately I don't have a reliable way to reproduce this. It happened to me like 3 times over the last few days.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months