I actually worked in the release-3.0.0 branch. We are using the official Version of RHQ right now (tagged RHQ_3_0_0) and wanted to upgrade. I did not want to take some SNAPSHOT version so I took the RHQ_3_0_0_EmbJopr2 tag (which is an descendant of the last officially tagged RHQ_3_0_0_GA version).
So I cannot expect the EmbJopr releases will fit into the upgrade process? My guess was that the DB updates are in a way community-supported like this?: RHQ_3_0_0 => RHQ_3_0_0_GA => RHQ_EmbJopr => RHQ_EmbJopr2 => RHQ_3_0_1 => ...
I just retried the deployment with the RHQ_3_0_0_GA version and get the same error. Maybe the automatically downloaded JBoss installation has some errors (related to the Maven build process?).
I will retry with the RHQ_3_0_0 version and if this does not help setup a new Maven repository and start from scratch.
Another question related to this one and maybe more general is: Currently I see two branches "release-3.0.0-patch1" and "release-3.0.0-patch2" but they are not tagged. So I guess I can't consider the latest revisions in the patch branches as "community-supported to work for patches" (at least till they are untagged) right? I mean do I get in a "Beta-" state (especially related to the DB) if I would upgrade to those revisions?
If you should not know what I mean I'll explain with an example: Let's assume: Rev (ordered) | tag | branch | description rev1 rhq3 rhq3 official version rev3 <none> rhq3 some untagged version not contained in rhq3.1 rev6 <none> rhq3.1 some untagged patch branch revision rev9 rhq3.0.1 rhq3.1 officially tagged patch version
If I upgrade my RHQ installation based on rev1 to rev9 everything should be fine. If there are bugs found in rev9 I will wait for some official update and my DB will not be corrupted or at least be repaired later.
Is it correct that if I would upgrade based on rev1 to rev6 or even rev3 I cannot expect a later upgrade to rev9 to work at all?
Thanks Andreas :-)
-------- Original Message -------- Subject: Re: RHQ initial server startup error: NoClassDefFoundError: org/jboss/wsf/spi/deployment/UnifiedVirtualFile (RHQ_3_0_0_EmbJopr2 tag) Date: Thu, 14 Oct 2010 08:19:01 -0400 From: John Mazzitelli mazz@redhat.com Reply-To: mazz@redhat.com, rhq-devel@lists.fedorahosted.org To: rhq-devel@lists.fedorahosted.org
I'm not seeing anything RHQ specific that is failing here. However, can I ask what you are trying to do? Are you trying to build an RHQ Server distribution or an Embedded Jopr distribution? If the former, I think you are using the wrong tagged version. That "EmpJopr2" tag name infers that it was needed to build the Embedded Jopr stuff - I would not use that - instead, use the "release-3.0.0" branch or something like that. See:
http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=shortlog;h=refs/heads/relea...
If you want to build/run Embedded Jopr, I'm actually not too familiar with how to build that. Hopefully Ian is around that can help or point to a wiki page that explains the Embedded Jopr build process.
On 10/14/2010 07:12 AM, Andreas Dietrich wrote:
Hi,
can somebody give me a hint why I get this error trying to startup the RHQ server (RHQ_3_0_0_EmbJopr2 tagged revision).
I built it in Eclipse Helios using an external Maven 2.2.1 install.
Thanks for any hint Andreas :-)
2010-10-12 17:30:32,960 INFO [org.jboss.resource.adapter.quartz.inflow.QuartzResourceAdapter] start quartz!!! 2010-10-12 17:30:33,008 INFO [org.quartz.simpl.SimpleThreadPool] Job execution threads will use class loader of thread: main 2010-10-12 17:30:33,043 INFO [org.quartz.core.SchedulerSignalerImpl] Initialized Scheduler Signaller of type: class org.quartz.core.SchedulerSignalerImpl 2010-10-12 17:30:33,043 INFO [org.quartz.core.QuartzScheduler] Quartz Scheduler v.1.6.5 created. 2010-10-12 17:30:33,045 INFO [org.quartz.simpl.RAMJobStore] RAMJobStore initialized. 2010-10-12 17:30:33,045 INFO [org.quartz.impl.StdSchedulerFactory] Quartz scheduler 'DefaultQuartzScheduler' initialized from default resource file in Quartz package: 'quartz.properties' 2010-10-12 17:30:33,045 INFO [org.quartz.impl.StdSchedulerFactory] Quartz scheduler version: 1.6.5 2010-10-12 17:30:33,045 INFO [org.quartz.core.QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started. 2010-10-12 17:30:33,060 ERROR [org.jboss.deployment.MainDeployer] Could not create deployment: file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/rhq-installer.war/ java.lang.NoClassDefFoundError: org/jboss/wsf/spi/deployment/UnifiedVirtualFile at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Unknown Source) at java.lang.Class.getConstructor0(Unknown Source) at java.lang.Class.newInstance0(Unknown Source) at java.lang.Class.newInstance(Unknown Source) ... at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:304) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy5.deploy(Unknown Source) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362) at org.jboss.Main.boot(Main.java:200) at org.jboss.Main$1.run(Main.java:508) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.ClassNotFoundException: No ClassLoaders found for: org.jboss.wsf.spi.deployment.UnifiedVirtualFile at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:212) at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:521) at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:415) at java.lang.ClassLoader.loadClass(Unknown Source) ... 89 more 2010-10-12 17:30:33,062 ERROR [org.jboss.deployment.scanner.URLDeploymentScanner] Incomplete Deployment listing:
--- Incompletely deployed packages --- org.jboss.deployment.DeploymentInfo@13642991 { url=file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/jboss-web.deployer/ROOT.war/ } deployer: MBeanProxyExt[jboss.web:service=WebServer] status: Deployment FAILED reason: org/jboss/wsf/spi/deployment/UnifiedVirtualFile state: FAILED watch: file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/jboss-web.deployer/ROOT.war/WEB-INF/web.xml altDD: null lastDeployed: 1286897432575 lastModified: 1286896122000 mbeans:
org.jboss.deployment.DeploymentInfo@52727534 { url=file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/client-deployer-service.xml } deployer: org.jboss.deployment.SARDeployer@419d05 status: Deployment FAILED reason: - nested throwable: (java.lang.reflect.UndeclaredThrowableException) state: FAILED watch: file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/client-deployer-service.xml altDD: null lastDeployed: 1286897430841 lastModified: 1286897430000 mbeans:
org.jboss.deployment.DeploymentInfo@39f18328 { url=file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/rhq-installer.war/ } deployer: MBeanProxyExt[jboss.web:service=WebServer] status: Deployment FAILED reason: org/jboss/wsf/spi/deployment/UnifiedVirtualFile state: FAILED watch: file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/rhq-installer.war/WEB-INF/web.xml altDD: null lastDeployed: 1286897433058 lastModified: 1286896118000 mbeans:
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________ rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
----- End forwarded message -----
On 10/14/2010 10:11 AM, Andreas Dietrich wrote:
RHQ_3_0_0 => RHQ_3_0_0_GA => RHQ_EmbJopr => RHQ_EmbJopr2 => RHQ_3_0_1 => ...
Those EmbJopr branches have no relation to the others really. That order you list is not correct. For example, RHQ_EmbJopr does not "come after" or is an "upgrade from" RHQ_3_0_0_GA - they really aren't (or shouldn't be) releated.
As for your other questions, I know Heiko has been deeply involved in building the latest RHQ releases so he might be able to answer your questions more definitively - I'll let him answer them if he can.
Or, if anyone else is out there that knows how to describe what the different branches and tags are, please chime in.
On 10/14/2010 10:11 AM, Andreas Dietrich wrote:
I actually worked in the release-3.0.0 branch. We are using the official Version of RHQ right now (tagged RHQ_3_0_0) and wanted to upgrade. I did not want to take some SNAPSHOT version so I took the RHQ_3_0_0_EmbJopr2 tag (which is an descendant of the last officially tagged RHQ_3_0_0_GA version).
So I cannot expect the EmbJopr releases will fit into the upgrade process? My guess was that the DB updates are in a way community-supported like this?: RHQ_3_0_0 => RHQ_3_0_0_GA => RHQ_EmbJopr => RHQ_EmbJopr2 => RHQ_3_0_1 => ...
I just retried the deployment with the RHQ_3_0_0_GA version and get the same error. Maybe the automatically downloaded JBoss installation has some errors (related to the Maven build process?).
I will retry with the RHQ_3_0_0 version and if this does not help setup a new Maven repository and start from scratch.
Another question related to this one and maybe more general is: Currently I see two branches "release-3.0.0-patch1" and "release-3.0.0-patch2" but they are not tagged. So I guess I can't consider the latest revisions in the patch branches as "community-supported to work for patches" (at least till they are untagged) right? I mean do I get in a "Beta-" state (especially related to the DB) if I would upgrade to those revisions?
If you should not know what I mean I'll explain with an example: Let's assume: Rev (ordered) | tag | branch | description rev1 rhq3 rhq3 official version rev3<none> rhq3 some untagged version not contained in rhq3.1 rev6<none> rhq3.1 some untagged patch branch revision rev9 rhq3.0.1 rhq3.1 officially tagged patch version
If I upgrade my RHQ installation based on rev1 to rev9 everything should be fine. If there are bugs found in rev9 I will wait for some official update and my DB will not be corrupted or at least be repaired later.
Is it correct that if I would upgrade based on rev1 to rev6 or even rev3 I cannot expect a later upgrade to rev9 to work at all?
Thanks Andreas :-)
-------- Original Message -------- Subject: Re: RHQ initial server startup error: NoClassDefFoundError: org/jboss/wsf/spi/deployment/UnifiedVirtualFile (RHQ_3_0_0_EmbJopr2 tag) Date: Thu, 14 Oct 2010 08:19:01 -0400 From: John Mazzitellimazz@redhat.com Reply-To: mazz@redhat.com, rhq-devel@lists.fedorahosted.org To: rhq-devel@lists.fedorahosted.org
I'm not seeing anything RHQ specific that is failing here. However, can I ask what you are trying to do? Are you trying to build an RHQ Server distribution or an Embedded Jopr distribution? If the former, I think you are using the wrong tagged version. That "EmpJopr2" tag name infers that it was needed to build the Embedded Jopr stuff - I would not use that - instead, use the "release-3.0.0" branch or something like that. See:
http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=shortlog;h=refs/heads/relea...
If you want to build/run Embedded Jopr, I'm actually not too familiar with how to build that. Hopefully Ian is around that can help or point to a wiki page that explains the Embedded Jopr build process.
On 10/14/2010 07:12 AM, Andreas Dietrich wrote:
Hi,
can somebody give me a hint why I get this error trying to startup the RHQ server (RHQ_3_0_0_EmbJopr2 tagged revision).
I built it in Eclipse Helios using an external Maven 2.2.1 install.
Thanks for any hint Andreas :-)
2010-10-12 17:30:32,960 INFO [org.jboss.resource.adapter.quartz.inflow.QuartzResourceAdapter] start quartz!!! 2010-10-12 17:30:33,008 INFO [org.quartz.simpl.SimpleThreadPool] Job execution threads will use class loader of thread: main 2010-10-12 17:30:33,043 INFO [org.quartz.core.SchedulerSignalerImpl] Initialized Scheduler Signaller of type: class org.quartz.core.SchedulerSignalerImpl 2010-10-12 17:30:33,043 INFO [org.quartz.core.QuartzScheduler] Quartz Scheduler v.1.6.5 created. 2010-10-12 17:30:33,045 INFO [org.quartz.simpl.RAMJobStore] RAMJobStore initialized. 2010-10-12 17:30:33,045 INFO [org.quartz.impl.StdSchedulerFactory] Quartz scheduler 'DefaultQuartzScheduler' initialized from default resource file in Quartz package: 'quartz.properties' 2010-10-12 17:30:33,045 INFO [org.quartz.impl.StdSchedulerFactory] Quartz scheduler version: 1.6.5 2010-10-12 17:30:33,045 INFO [org.quartz.core.QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started. 2010-10-12 17:30:33,060 ERROR [org.jboss.deployment.MainDeployer] Could not create deployment: file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/rhq-installer.war/ java.lang.NoClassDefFoundError: org/jboss/wsf/spi/deployment/UnifiedVirtualFile at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Unknown Source) at java.lang.Class.getConstructor0(Unknown Source) at java.lang.Class.newInstance0(Unknown Source) at java.lang.Class.newInstance(Unknown Source) ... at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:304) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy5.deploy(Unknown Source) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362) at org.jboss.Main.boot(Main.java:200) at org.jboss.Main$1.run(Main.java:508) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.ClassNotFoundException: No ClassLoaders found for: org.jboss.wsf.spi.deployment.UnifiedVirtualFile at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:212) at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:521) at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:415) at java.lang.ClassLoader.loadClass(Unknown Source) ... 89 more 2010-10-12 17:30:33,062 ERROR [org.jboss.deployment.scanner.URLDeploymentScanner] Incomplete Deployment listing:
--- Incompletely deployed packages --- org.jboss.deployment.DeploymentInfo@13642991 { url=file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/jboss-web.deployer/ROOT.war/ } deployer: MBeanProxyExt[jboss.web:service=WebServer] status: Deployment FAILED reason: org/jboss/wsf/spi/deployment/UnifiedVirtualFile state: FAILED watch: file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/jboss-web.deployer/ROOT.war/WEB-INF/web.xml altDD: null lastDeployed: 1286897432575 lastModified: 1286896122000 mbeans:
org.jboss.deployment.DeploymentInfo@52727534 { url=file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/client-deployer-service.xml } deployer: org.jboss.deployment.SARDeployer@419d05 status: Deployment FAILED reason: - nested throwable: (java.lang.reflect.UndeclaredThrowableException) state: FAILED watch: file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/client-deployer-service.xml altDD: null lastDeployed: 1286897430841 lastModified: 1286897430000 mbeans:
org.jboss.deployment.DeploymentInfo@39f18328 { url=file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/rhq-installer.war/ } deployer: MBeanProxyExt[jboss.web:service=WebServer] status: Deployment FAILED reason: org/jboss/wsf/spi/deployment/UnifiedVirtualFile state: FAILED watch: file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/rhq-installer.war/WEB-INF/web.xml altDD: null lastDeployed: 1286897433058 lastModified: 1286896118000 mbeans:
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
----- End forwarded message -----
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
Hi there,
I just spoke with Heiko about it and would like post the outcome here for later reference. The whole release structure is not to be considered cleanly streamlined in all places:
1) the *_GA tags/releases are the basis for the JON releases and as such provide "clean" update paths regarding DB updates 1.1) branch release-3.0.0 may be tagged at some point with something like RHQ_3_0_1_GA which should be the next official patch nb. 1 for the RHQ_3_0_0_GA release 1.2) interestingly (from my point of view) the official binaries based on RHQ_3_0_0 are kind of exceptional (likely the upgrade from RHQ_3_0_0 to RHQ_3_0_0_GA will be ok) 1.2.1 => I would recommend to somebody that want's to start with a stable community-supported version to build the RHQ_3_0_0_GA release himself and start with this one in a production environment
2) branches release-3.0.0-patch1 and release-3.0.0-patch2 do not make much sense so far from a community point of view 2a) they are considered SNAPSHOT revisions that should be merged later into the release-3.0.0 branch
3) the *_EmbJopr* tags are used for some JBoss AppSrv Console where DB updates do not matter (as such they do NOT provide "clean" update paths and should not be used for "production" releases)
Regards Andreas :-)
On 10/14/2010 04:28 PM, John Mazzitelli wrote:
As for your other questions, I know Heiko has been deeply involved in building the latest RHQ releases so he might be able to answer your questions more definitively - I'll let him answer them if he can.
Or, if anyone else is out there that knows how to describe what the different branches and tags are, please chime in.
On 10/14/2010 10:11 AM, Andreas Dietrich wrote:
I actually worked in the release-3.0.0 branch. We are using the official Version of RHQ right now (tagged RHQ_3_0_0) and wanted to upgrade. I did not want to take some SNAPSHOT version so I took the RHQ_3_0_0_EmbJopr2 tag (which is an descendant of the last officially tagged RHQ_3_0_0_GA version).
So I cannot expect the EmbJopr releases will fit into the upgrade process? My guess was that the DB updates are in a way community-supported like this?: RHQ_3_0_0 => RHQ_3_0_0_GA => RHQ_EmbJopr => RHQ_EmbJopr2 => RHQ_3_0_1 => ...
I just retried the deployment with the RHQ_3_0_0_GA version and get the same error. Maybe the automatically downloaded JBoss installation has some errors (related to the Maven build process?).
I will retry with the RHQ_3_0_0 version and if this does not help setup a new Maven repository and start from scratch.
Another question related to this one and maybe more general is: Currently I see two branches "release-3.0.0-patch1" and "release-3.0.0-patch2" but they are not tagged. So I guess I can't consider the latest revisions in the patch branches as "community-supported to work for patches" (at least till they are untagged) right? I mean do I get in a "Beta-" state (especially related to the DB) if I would upgrade to those revisions?
If you should not know what I mean I'll explain with an example: Let's assume: Rev (ordered) | tag | branch | description rev1 rhq3 rhq3 official version rev3<none> rhq3 some untagged version not contained in rhq3.1 rev6<none> rhq3.1 some untagged patch branch revision rev9 rhq3.0.1 rhq3.1 officially tagged patch version
If I upgrade my RHQ installation based on rev1 to rev9 everything should be fine. If there are bugs found in rev9 I will wait for some official update and my DB will not be corrupted or at least be repaired later.
Is it correct that if I would upgrade based on rev1 to rev6 or even rev3 I cannot expect a later upgrade to rev9 to work at all?
Thanks Andreas :-)
-------- Original Message -------- Subject: Re: RHQ initial server startup error: NoClassDefFoundError: org/jboss/wsf/spi/deployment/UnifiedVirtualFile (RHQ_3_0_0_EmbJopr2 tag) Date: Thu, 14 Oct 2010 08:19:01 -0400 From: John Mazzitellimazz@redhat.com Reply-To: mazz@redhat.com, rhq-devel@lists.fedorahosted.org To: rhq-devel@lists.fedorahosted.org
I'm not seeing anything RHQ specific that is failing here. However, can I ask what you are trying to do? Are you trying to build an RHQ Server distribution or an Embedded Jopr distribution? If the former, I think you are using the wrong tagged version. That "EmpJopr2" tag name infers that it was needed to build the Embedded Jopr stuff - I would not use that - instead, use the "release-3.0.0" branch or something like that. See:
http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=shortlog;h=refs/heads/relea...
If you want to build/run Embedded Jopr, I'm actually not too familiar with how to build that. Hopefully Ian is around that can help or point to a wiki page that explains the Embedded Jopr build process.
On 10/14/2010 07:12 AM, Andreas Dietrich wrote:
Hi,
can somebody give me a hint why I get this error trying to startup the RHQ server (RHQ_3_0_0_EmbJopr2 tagged revision).
I built it in Eclipse Helios using an external Maven 2.2.1 install.
Thanks for any hint Andreas :-)
2010-10-12 17:30:32,960 INFO [org.jboss.resource.adapter.quartz.inflow.QuartzResourceAdapter] start quartz!!! 2010-10-12 17:30:33,008 INFO [org.quartz.simpl.SimpleThreadPool] Job execution threads will use class loader of thread: main 2010-10-12 17:30:33,043 INFO [org.quartz.core.SchedulerSignalerImpl] Initialized Scheduler Signaller of type: class org.quartz.core.SchedulerSignalerImpl 2010-10-12 17:30:33,043 INFO [org.quartz.core.QuartzScheduler] Quartz Scheduler v.1.6.5 created. 2010-10-12 17:30:33,045 INFO [org.quartz.simpl.RAMJobStore] RAMJobStore initialized. 2010-10-12 17:30:33,045 INFO [org.quartz.impl.StdSchedulerFactory] Quartz scheduler 'DefaultQuartzScheduler' initialized from default resource file in Quartz package: 'quartz.properties' 2010-10-12 17:30:33,045 INFO [org.quartz.impl.StdSchedulerFactory] Quartz scheduler version: 1.6.5 2010-10-12 17:30:33,045 INFO [org.quartz.core.QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started. 2010-10-12 17:30:33,060 ERROR [org.jboss.deployment.MainDeployer] Could not create deployment: file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/rhq-installer.war/ java.lang.NoClassDefFoundError: org/jboss/wsf/spi/deployment/UnifiedVirtualFile at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Unknown Source) at java.lang.Class.getConstructor0(Unknown Source) at java.lang.Class.newInstance0(Unknown Source) at java.lang.Class.newInstance(Unknown Source) ... at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:304) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy5.deploy(Unknown Source) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362) at org.jboss.Main.boot(Main.java:200) at org.jboss.Main$1.run(Main.java:508) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.ClassNotFoundException: No ClassLoaders found for: org.jboss.wsf.spi.deployment.UnifiedVirtualFile at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:212) at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:521) at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:415) at java.lang.ClassLoader.loadClass(Unknown Source) ... 89 more 2010-10-12 17:30:33,062 ERROR [org.jboss.deployment.scanner.URLDeploymentScanner] Incomplete Deployment listing:
--- Incompletely deployed packages --- org.jboss.deployment.DeploymentInfo@13642991 { url=file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/jboss-web.deployer/ROOT.war/ } deployer: MBeanProxyExt[jboss.web:service=WebServer] status: Deployment FAILED reason: org/jboss/wsf/spi/deployment/UnifiedVirtualFile state: FAILED watch: file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/jboss-web.deployer/ROOT.war/WEB-INF/web.xml altDD: null lastDeployed: 1286897432575 lastModified: 1286896122000 mbeans:
org.jboss.deployment.DeploymentInfo@52727534 { url=file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/client-deployer-service.xml } deployer: org.jboss.deployment.SARDeployer@419d05 status: Deployment FAILED reason: - nested throwable: (java.lang.reflect.UndeclaredThrowableException) state: FAILED watch: file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/client-deployer-service.xml altDD: null lastDeployed: 1286897430841 lastModified: 1286897430000 mbeans:
org.jboss.deployment.DeploymentInfo@39f18328 { url=file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/rhq-installer.war/ } deployer: MBeanProxyExt[jboss.web:service=WebServer] status: Deployment FAILED reason: org/jboss/wsf/spi/deployment/UnifiedVirtualFile state: FAILED watch: file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/rhq-installer.war/WEB-INF/web.xml altDD: null lastDeployed: 1286897433058 lastModified: 1286896118000 mbeans:
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
----- End forwarded message -----
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
On 10/14/2010 04:11 PM, Andreas Dietrich wrote:
I actually worked in the release-3.0.0 branch. We are using the official Version of RHQ right now (tagged RHQ_3_0_0) and wanted to upgrade. I did not want to take some SNAPSHOT version so I took the RHQ_3_0_0_EmbJopr2 tag (which is an descendant of the last officially tagged RHQ_3_0_0_GA version).
So I cannot expect the EmbJopr releases will fit into the upgrade process? My guess was that the DB updates are in a way community-supported like this?: RHQ_3_0_0 => RHQ_3_0_0_GA => RHQ_EmbJopr => RHQ_EmbJopr2 => RHQ_3_0_1 => ...
I just retried the deployment with the RHQ_3_0_0_GA version and get the same error. Maybe the automatically downloaded JBoss installation has some errors (related to the Maven build process?).
I will retry with the RHQ_3_0_0 version and if this does not help setup a new Maven repository and start from scratch.
The RHQ_3_0_0 version works! :-( So I guess it is related to my Maven build process somehow (maybe some new JBoss dependencies or something was altered). I'll try to build the GA release as described on the wiki page instead of building it in Eclipse/Maven.
Another question related to this one and maybe more general is: Currently I see two branches "release-3.0.0-patch1" and "release-3.0.0-patch2" but they are not tagged. So I guess I can't consider the latest revisions in the patch branches as "community-supported to work for patches" (at least till they are untagged) right? I mean do I get in a "Beta-" state (especially related to the DB) if I would upgrade to those revisions?
If you should not know what I mean I'll explain with an example: Let's assume: Rev (ordered) | tag | branch | description rev1 rhq3 rhq3 official version rev3<none> rhq3 some untagged version not contained in rhq3.1 rev6<none> rhq3.1 some untagged patch branch revision rev9 rhq3.0.1 rhq3.1 officially tagged patch version
If I upgrade my RHQ installation based on rev1 to rev9 everything should be fine. If there are bugs found in rev9 I will wait for some official update and my DB will not be corrupted or at least be repaired later.
Is it correct that if I would upgrade based on rev1 to rev6 or even rev3 I cannot expect a later upgrade to rev9 to work at all?
Thanks Andreas :-)
-------- Original Message -------- Subject: Re: RHQ initial server startup error: NoClassDefFoundError: org/jboss/wsf/spi/deployment/UnifiedVirtualFile (RHQ_3_0_0_EmbJopr2 tag) Date: Thu, 14 Oct 2010 08:19:01 -0400 From: John Mazzitellimazz@redhat.com Reply-To: mazz@redhat.com, rhq-devel@lists.fedorahosted.org To: rhq-devel@lists.fedorahosted.org
I'm not seeing anything RHQ specific that is failing here. However, can I ask what you are trying to do? Are you trying to build an RHQ Server distribution or an Embedded Jopr distribution? If the former, I think you are using the wrong tagged version. That "EmpJopr2" tag name infers that it was needed to build the Embedded Jopr stuff - I would not use that - instead, use the "release-3.0.0" branch or something like that. See:
http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=shortlog;h=refs/heads/relea...
If you want to build/run Embedded Jopr, I'm actually not too familiar with how to build that. Hopefully Ian is around that can help or point to a wiki page that explains the Embedded Jopr build process.
On 10/14/2010 07:12 AM, Andreas Dietrich wrote:
Hi,
can somebody give me a hint why I get this error trying to startup the RHQ server (RHQ_3_0_0_EmbJopr2 tagged revision).
I built it in Eclipse Helios using an external Maven 2.2.1 install.
Thanks for any hint Andreas :-)
2010-10-12 17:30:32,960 INFO [org.jboss.resource.adapter.quartz.inflow.QuartzResourceAdapter] start quartz!!! 2010-10-12 17:30:33,008 INFO [org.quartz.simpl.SimpleThreadPool] Job execution threads will use class loader of thread: main 2010-10-12 17:30:33,043 INFO [org.quartz.core.SchedulerSignalerImpl] Initialized Scheduler Signaller of type: class org.quartz.core.SchedulerSignalerImpl 2010-10-12 17:30:33,043 INFO [org.quartz.core.QuartzScheduler] Quartz Scheduler v.1.6.5 created. 2010-10-12 17:30:33,045 INFO [org.quartz.simpl.RAMJobStore] RAMJobStore initialized. 2010-10-12 17:30:33,045 INFO [org.quartz.impl.StdSchedulerFactory] Quartz scheduler 'DefaultQuartzScheduler' initialized from default resource file in Quartz package: 'quartz.properties' 2010-10-12 17:30:33,045 INFO [org.quartz.impl.StdSchedulerFactory] Quartz scheduler version: 1.6.5 2010-10-12 17:30:33,045 INFO [org.quartz.core.QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started. 2010-10-12 17:30:33,060 ERROR [org.jboss.deployment.MainDeployer] Could not create deployment: file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/rhq-installer.war/ java.lang.NoClassDefFoundError: org/jboss/wsf/spi/deployment/UnifiedVirtualFile at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Unknown Source) at java.lang.Class.getConstructor0(Unknown Source) at java.lang.Class.newInstance0(Unknown Source) at java.lang.Class.newInstance(Unknown Source) ... at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:304) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy5.deploy(Unknown Source) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362) at org.jboss.Main.boot(Main.java:200) at org.jboss.Main$1.run(Main.java:508) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.ClassNotFoundException: No ClassLoaders found for: org.jboss.wsf.spi.deployment.UnifiedVirtualFile at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:212) at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:521) at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:415) at java.lang.ClassLoader.loadClass(Unknown Source) ... 89 more 2010-10-12 17:30:33,062 ERROR [org.jboss.deployment.scanner.URLDeploymentScanner] Incomplete Deployment listing:
--- Incompletely deployed packages --- org.jboss.deployment.DeploymentInfo@13642991 { url=file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/jboss-web.deployer/ROOT.war/ } deployer: MBeanProxyExt[jboss.web:service=WebServer] status: Deployment FAILED reason: org/jboss/wsf/spi/deployment/UnifiedVirtualFile state: FAILED watch: file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/jboss-web.deployer/ROOT.war/WEB-INF/web.xml altDD: null lastDeployed: 1286897432575 lastModified: 1286896122000 mbeans:
org.jboss.deployment.DeploymentInfo@52727534 { url=file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/client-deployer-service.xml } deployer: org.jboss.deployment.SARDeployer@419d05 status: Deployment FAILED reason: - nested throwable: (java.lang.reflect.UndeclaredThrowableException) state: FAILED watch: file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/client-deployer-service.xml altDD: null lastDeployed: 1286897430841 lastModified: 1286897430000 mbeans:
org.jboss.deployment.DeploymentInfo@39f18328 { url=file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/rhq-installer.war/ } deployer: MBeanProxyExt[jboss.web:service=WebServer] status: Deployment FAILED reason: org/jboss/wsf/spi/deployment/UnifiedVirtualFile state: FAILED watch: file:/opt/rhq-server-3.0.0.EmbJopr2/jbossas/server/default/deploy/rhq-installer.war/WEB-INF/web.xml altDD: null lastDeployed: 1286897433058 lastModified: 1286896118000 mbeans:
Am 14.10.2010 um 17:51 schrieb Andreas Dietrich:
The RHQ_3_0_0 version works! :-( So I guess it is related to my Maven build process somehow (maybe some
You need to use the maven command line tool. I had reports from Alex Kiefer (working on Nagios support) that builds from within Eclipse failed mysteriously, while they succeeded with the command line mvn call. Perhaps you see something similar?
We have included in the source several Eclipse External Tool Configurations (aka "the little green-circle-with-an-arrow-and-red-suitcase icon with the drop down menu") that let's you launch builds directly from Eclipse (which really just launches an external mvn build - but lets you see the results in the Eclipse Console view).
See:
http://rhq-project.org/display/RHQ/Eclipse+Tips#EclipseTips-ExternalTools%2F...
On 10/15/2010 05:53 AM, Heiko W.Rupp wrote:
Am 14.10.2010 um 17:51 schrieb Andreas Dietrich:
The RHQ_3_0_0 version works! :-( So I guess it is related to my Maven build process somehow (maybe some
You need to use the maven command line tool. I had reports from Alex Kiefer (working on Nagios support) that builds from within Eclipse failed mysteriously, while they succeeded with the command line mvn call. Perhaps you see something similar?
Am 15.10.2010 um 13:51 schrieb John Mazzitelli:
We have included in the source several Eclipse External Tool Configurations (aka "the little green-circle-with-an-arrow-and-red-suitcase icon with the drop down menu") that let's you launch builds directly from Eclipse (which really just launches an external mvn build - but lets you see the results in the Eclipse Console view).
It looks like if you have M2Eclipse installed, you can also launch mvn builds from there, which seems to have different (classloader ?) semantics.
So when in doubt, use command like mvn.
Heiko
On 10/15/2010 08:00 AM, Heiko W.Rupp wrote:
It looks like if you have M2Eclipse installed, you can also launch mvn builds from there, which seems to have different (classloader ?) semantics.
So when in doubt, use command like mvn.
I would not use M2Eclipse. I've always had problems with that. I've not tried it in a while, but every time I've tried in the past, it just didn't work nicely for me. I would say if you are using that, do not expect RHQ to build successfully (or at minimum do not be surprised if it fails to build).
However, you can always use our Eclipse External Tool definitions - they will always work the same as if you launched directly from a command line console using the same arguments the external tool definitions pass in. (btw: you will get these RHQ external tool definitions in Eclipse automatically as soon as you import the RHQ project into Eclipse - you just have to set that M2 variable as described in that wiki page I linked to earlier).
Those external tool configurations will launch mvn builds externally and thus there are no issues with Eclipse messing with classloaders and things like that - using these Eclipse tools are just as if you launched them from the command line - except you can see its output in the Eclipse Console view.
Note: most of those Eclipse tool definitions pass in "-o" to maven because 90% of the time, using it in offline mode doesn't hurt and it makes the build go faster. However, if new dependencies were added to the project poms, you'll need to run a mvn build without -o so it knows to download new deps - in fact we have an Eclipse External Tool configuration that you can use to ask it to download dependencies - "RHQ Maven Build - Download Dependencies".
On Friday, October 15, 2010 14:13:38 John Mazzitelli wrote:
On 10/15/2010 08:00 AM, Heiko W.Rupp wrote:
It looks like if you have M2Eclipse installed, you can also launch mvn builds from there, which seems to have different (classloader ?) semantics.
So when in doubt, use command like mvn.
I would not use M2Eclipse. I've always had problems with that. I've not tried it in a while, but every time I've tried in the past, it just didn't work nicely for me. I would say if you are using that, do not expect RHQ to build successfully (or at minimum do not be surprised if it fails to build).
I've been using it for quite some time now mainly because I like its eclipse project per maven project approach as opposed to the everything-crammed- together eclipse project defined in our repo. It's much easier to make sense of library visibility, etc.
I can't say it's totally stable and it requires to occassionally (once in a month approx) reimport the project but otherwise it seems to be working quite well.
I don't use it for building stuff though because of the very problem that's being discussed here - and I know no other solution to it.
However, you can always use our Eclipse External Tool definitions - they will always work the same as if you launched directly from a command line console using the same arguments the external tool definitions pass in. (btw: you will get these RHQ external tool definitions in Eclipse automatically as soon as you import the RHQ project into Eclipse - you just have to set that M2 variable as described in that wiki page I linked to earlier).
Those external tool configurations will launch mvn builds externally and thus there are no issues with Eclipse messing with classloaders and things like that - using these Eclipse tools are just as if you launched them from the command line - except you can see its output in the Eclipse Console view.
Note: most of those Eclipse tool definitions pass in "-o" to maven because 90% of the time, using it in offline mode doesn't hurt and it makes the build go faster. However, if new dependencies were added to the project poms, you'll need to run a mvn build without -o so it knows to download new deps - in fact we have an Eclipse External Tool configuration that you can use to ask it to download dependencies - "RHQ Maven Build - Download Dependencies". _______________________________________________ rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
Worked like a charm :-)
Thanks very much Andreas
On 10/15/2010 01:51 PM, John Mazzitelli wrote:
We have included in the source several Eclipse External Tool Configurations (aka "the little green-circle-with-an-arrow-and-red-suitcase icon with the drop down menu") that let's you launch builds directly from Eclipse (which really just launches an external mvn build - but lets you see the results in the Eclipse Console view).
See:
http://rhq-project.org/display/RHQ/Eclipse+Tips#EclipseTips-ExternalTools%2F...
On 10/15/2010 05:53 AM, Heiko W.Rupp wrote:
Am 14.10.2010 um 17:51 schrieb Andreas Dietrich:
The RHQ_3_0_0 version works! :-( So I guess it is related to my Maven build process somehow (maybe some
You need to use the maven command line tool. I had reports from Alex Kiefer (working on Nagios support) that builds from within Eclipse failed mysteriously, while they succeeded with the command line mvn call. Perhaps you see something similar?
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel@lists.fedorahosted.org