Behavioral Change: dev environment impact due to agent preferences handling
by Jay Shaughnessy
I just pushed changes for
https://bugzilla.redhat.com/show_bug.cgi?id=824010. With this change
the agent no longer uses the native implementation of Java Preferences.
Instead, it uses our custom implementation (FilePreferences.java). Now
the agent configuration will be stored in a configurable file, as
opposed to the default file location on Linux and the registry on windows.
By default, and there shouldn't be a lot of need to change from the
default, the agent config will be placed in
RHQ_AGENT_HOME/conf/agent-prefs.properties.
For new agents there shouldn't be any discernible difference in
behavior, other than the new file being generated. For existing agents
the preferences will be migrated from the native storage to our file
storage during the agent auto update procedure.
BUT, for your dev environments, where you likely don't go through an
autoupdate, you have a few options. Start by:
1) bring down your agent.
2) rebuild the agent: mvn -Pagent
Option 1 (easiest, new agent):
3) delete your registered agent, either via the new Delete button
under Administration->Topology->Agents or by just doing a dbsetup.
4) start your new agent and enter the setup info as usual
Option 2 (recommended, autoupdate):
3) rebuild the appserver/autoupdate module
4) copy the autoupdate jar to your agent home dir
5) > java -jar rhq-enterprise-agentupdate-4.7.0-SNAPSHOT.jar -u
6)your updated agent should now be running and using the migrated prefs
Note, option 1 will leave your old prefs in the native prefs store.
Option 2 will clean them up as part of the migration. If you have time
try option 2, it will test the code better and do the cleanup.
Jay
11 years, 1 month
A Maven plugin for RHQ agent plugin development
by Thomas Segismont
Hi all,
If you ever wrote an RHQ agent plugin as a Maven project you probably
had to use different Maven plugins (dependency plugin, assembly plugin,
ant plugin) to get this done.
I have started a prototype for an RHQ agent plugin custom packaging and
wrote about this in the project wiki [1].
The goal is to get shorter and easier to read/write POM files. Anything
that makes plugin development simpler will encourage plugin development
I hope.
Please do not hesitate to give your feedback.
Thanks and regards,
Thomas
[1]
https://docs.jboss.org/author/display/RHQ/Maven+plugin+for+RHQ+agent+plugin
11 years, 1 month
troubles building RHQ
by Ian
Hello ex-colleagues,
I hope everyone is doing well.
I wanted to take a peek at the latest RHQ and dev that I am, I thought I
would build it from source. I ended up hitting a number of issues and
eventually gave up. Here they are in case the dev team wants to look into
any of them. I think it would be ideal if people could check out the source
from git and simply run "mvn install" to build it. Being able to run it
right away without having to setup Postgres would be even better (make H2
or JavaDB the default out of box perhaps?).
Cheers,
Ian
---
Here's the list of stuff I encountered:
1)
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
(default-compile) on project rest-docs-generator: Compilation failure
[ERROR]
/Users/ips/Code/rhq/modules/helpers/rest-docs-generator/src/main/java/org/rhq/helpers/rest_docs_generator/ClassLevelProcessor.java:[61,37]
cannot find symbol
[ERROR] symbol : variable RELEASE_7
[ERROR] location: class javax.lang.model.SourceVersion
Solution: Set JAVA_HOME environment var to JDK7 install dir. Note: The
build aborts when the above error occurs, so there may be other JDK7 deps
further along.
2)
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-antrun-plugin:1.7:run
(test-db-schema-version) on project rhq-core-dbutils: An Ant BuildException
has occured: The following error occurred while executing this line:
[ERROR]
/Users/ips/Code/rhq/modules/core/dbutils/src/main/scripts/dbsetup-build.xml:339:
org.postgresql.util.PSQLException: Connection refused. Check that the
hostname and port are correct and that the postmaster is accepting TCP/IP
connections.
[ERROR] around Ant part ...<ant
antfile="/Users/ips/Code/rhq/modules/core/dbutils/src/main/scripts/dbsetup-build.xml"
target="dbsetup-check-schema">... @ 14:124 in
/Users/ips/Code/rhq/modules/core/dbutils/target/antrun/build-main.xml
Solution: Pass -Ddbsetup-do-not-check-schema option to mvn.
3)
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
(default-compile) on project rhq-enterprise-server-xml-schemas: Compilation
failure
[ERROR] Failure executing javac, but could not parse the error:
[ERROR]
[ERROR]
[ERROR] The system is out of resources.
[ERROR] Consult the following stack trace for details.
[ERROR] java.lang.OutOfMemoryError: PermGen space
[ERROR] at
com.sun.tools.javac.main.JavaCompiler.<init>(JavaCompiler.java:355)
[ERROR] at
com.sun.tools.javac.main.JavaCompiler.instance(JavaCompiler.java:88)
[ERROR] at com.sun.tools.javac.main.Main.compile(Main.java:424)
[ERROR] at com.sun.tools.javac.main.Main.compile(Main.java:353)
[ERROR] at com.sun.tools.javac.main.Main.compile(Main.java:342)
[ERROR] at com.sun.tools.javac.main.Main.compile(Main.java:333)
[ERROR] at com.sun.tools.javac.Main.compile(Main.java:94)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[ERROR] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at java.lang.reflect.Method.invoke(Method.java:601)
[ERROR] at
org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacCompiler.java:554)
[ERROR] at
org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java:161)
[ERROR] at
org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:605)
[ERROR] at
org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
[ERROR] at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
[ERROR] at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
[ERROR] at java.util.concurrent.FutureTask.run(FutureTask.java:166)
[ERROR] at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
[ERROR] at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
[ERROR] at java.util.concurrent.FutureTask.run(FutureTask.java:166)
[ERROR] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
[ERROR] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
[ERROR] at java.lang.Thread.run(Thread.java:722)
Solution:
Interesting Side Note: Permgen will no longer exist in Java 8 (
http://javaeesupportpatterns.blogspot.com/2011/10/java-7-features-permgen...
)
4)
[ERROR] Failed to execute goal
org.bsc.maven:maven-processor-plugin:2.0.6-redhat:process-test
(create-rest-api-report) on project rest-docs-generator: Error executing:
error during compilation -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.bsc.maven:maven-processor-plugin:2.0.6-redhat:process-test
(create-rest-api-report) on project rest-docs-generator: Error executing
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
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:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error executing
at
org.bsc.maven.plugin.processor.AbstractAnnotationProcessorMojo.execute(AbstractAnnotationProcessorMojo.java:223)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 13 more
Caused by: java.lang.Exception: error during compilation
at
org.bsc.maven.plugin.processor.AbstractAnnotationProcessorMojo.executeWithExceptionsHandled(AbstractAnnotationProcessorMojo.java:384)
at
org.bsc.maven.plugin.processor.AbstractAnnotationProcessorMojo.execute(AbstractAnnotationProcessorMojo.java:216)
... 15 more
Solution: Stop passing "--threads 1C" option from mvn (see
http://code.google.com/p/maven-annotation-plugin/issues/detail?id=32)
5)
[INFO] Compiling module org.rhq.enterprise.gui.coregui.CoreGUI
[INFO] [ERROR] An internal compiler exception occurred
[INFO] com.google.gwt.dev.jjs.InternalCompilerException: Unexpected error
during visit.
[INFO] at
com.google.gwt.dev.jjs.ast.JVisitor.translateException(JVisitor.java:109)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:276)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:116)
[INFO] at com.google.gwt.dev.jjs.ast.JFieldRef.traverse(JFieldRef.java:111)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:116)
[INFO] at
com.google.gwt.dev.jjs.ast.JMethodCall.visitChildren(JMethodCall.java:248)
[INFO] at
com.google.gwt.dev.jjs.ast.JMethodCall.traverse(JMethodCall.java:241)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor$ListContext.traverse(JModVisitor.java:88)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.acceptWithInsertRemove(JModVisitor.java:331)
[INFO] at
com.google.gwt.dev.jjs.ast.js.JMultiExpression.traverse(JMultiExpression.java:60)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:116)
[INFO] at
com.google.gwt.dev.jjs.impl.MethodInliner$InliningVisitor.tryInlineExpression(MethodInliner.java:381)
[INFO] at
com.google.gwt.dev.jjs.impl.MethodInliner$InliningVisitor.endVisit(MethodInliner.java:122)
[INFO] at
com.google.gwt.dev.jjs.ast.JMethodCall.traverse(JMethodCall.java:243)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:116)
[INFO] at
com.google.gwt.dev.jjs.ast.JBinaryOperation.traverse(JBinaryOperation.java:81)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:116)
[INFO] at
com.google.gwt.dev.jjs.ast.JExpressionStatement.traverse(JExpressionStatement.java:41)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor$ListContextImmutable.traverse(JModVisitor.java:170)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.acceptWithInsertRemoveImmutable(JModVisitor.java:336)
[INFO] at com.google.gwt.dev.jjs.ast.JBlock.traverse(JBlock.java:83)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:137)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:133)
[INFO] at
com.google.gwt.dev.jjs.ast.JMethodBody.traverse(JMethodBody.java:82)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265)
[INFO] at
com.google.gwt.dev.jjs.ast.JMethod.visitChildren(JMethod.java:426)
[INFO] at
com.google.gwt.dev.jjs.ast.JConstructor.traverse(JConstructor.java:124)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor$ListContextImmutable.traverse(JModVisitor.java:170)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.acceptWithInsertRemoveImmutable(JModVisitor.java:336)
[INFO] at
com.google.gwt.dev.jjs.ast.JClassType.traverse(JClassType.java:98)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:287)
[INFO] at com.google.gwt.dev.jjs.ast.JProgram.traverse(JProgram.java:1032)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265)
[INFO] at
com.google.gwt.dev.jjs.impl.MethodInliner.execImpl(MethodInliner.java:521)
[INFO] at
com.google.gwt.dev.jjs.impl.MethodInliner.exec(MethodInliner.java:504)
[INFO] at
com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.optimizeLoop(JavaToJavaScriptCompiler.java:870)
[INFO] at
com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.optimize(JavaToJavaScriptCompiler.java:762)
[INFO] at
com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.precompile(JavaToJavaScriptCompiler.java:698)
[INFO] at
com.google.gwt.dev.jjs.JavaScriptCompiler.precompile(JavaScriptCompiler.java:33)
[INFO] at com.google.gwt.dev.Precompile.precompile(Precompile.java:278)
[INFO] at com.google.gwt.dev.Precompile.precompile(Precompile.java:229)
[INFO] at com.google.gwt.dev.Precompile.precompile(Precompile.java:141)
[INFO] at com.google.gwt.dev.Compiler.run(Compiler.java:232)
[INFO] at com.google.gwt.dev.Compiler.run(Compiler.java:198)
[INFO] at com.google.gwt.dev.Compiler$1.run(Compiler.java:170)
[INFO] at
com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:88)
[INFO] at
com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:82)
[INFO] at com.google.gwt.dev.Compiler.main(Compiler.java:177)
[INFO] Caused by: java.lang.AssertionError
[INFO] at
com.google.gwt.dev.jjs.ast.JNonNullType.<init>(JNonNullType.java:28)
[INFO] at
com.google.gwt.dev.jjs.ast.JReferenceType.getNonNull(JReferenceType.java:58)
[INFO] at
com.google.gwt.dev.jjs.impl.MethodInliner.merge(MethodInliner.java:559)
[INFO] at
com.google.gwt.dev.jjs.impl.MethodInliner.maybeCast(MethodInliner.java:543)
[INFO] at
com.google.gwt.dev.jjs.impl.MethodInliner.access$300(MethodInliner.java:57)
[INFO] at
com.google.gwt.dev.jjs.impl.MethodInliner$ParameterReplacer.endVisit(MethodInliner.java:468)
[INFO] at
com.google.gwt.dev.jjs.ast.JParameterRef.traverse(JParameterRef.java:47)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)
[INFO] at
com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273)
[INFO] ... 66 more
[INFO] [ERROR] at GroupOperationHistory.java(120): this$static
[INFO] com.google.gwt.dev.jjs.ast.JParameterRef
[INFO] [ERROR] at GroupOperationHistory.java(120):
this$static.resourceOperationHistories
[INFO] com.google.gwt.dev.jjs.ast.JFieldRef
[INFO] [ERROR] at GroupOperationHistory.java(120):
this$static.resourceOperationHistories.add(history)
[INFO] com.google.gwt.dev.jjs.ast.JMethodCall
[INFO] [ERROR] at GroupOperationHistory.java(119):
(this$static.resourceOperationHistories.add(history))
[INFO] com.google.gwt.dev.jjs.ast.js.JMultiExpression
[INFO] [ERROR] at ResourceOperationHistory.java(168):
GroupOperationHistory.$addResourceOperationHistory(groupHistory, this)
[INFO] com.google.gwt.dev.jjs.ast.JMethodCall
[INFO] [ERROR] at ResourceOperationHistory.java(167):
this.groupOperationHistory != null &&
GroupOperationHistory.$addResourceOperationHistory(groupHistory, this)
[INFO] com.google.gwt.dev.jjs.ast.JBinaryOperation
[INFO] [ERROR] at ResourceOperationHistory.java(167):
this.groupOperationHistory != null &&
GroupOperationHistory.$addResourceOperationHistory(groupHistory, this)
[INFO] com.google.gwt.dev.jjs.ast.JExpressionStatement
[INFO] [ERROR] at ResourceOperationHistory.java(129): {
[INFO] super(jobName, jobGroup, subjectName, operationDefinition,
parameters);
[INFO] this.resource = resource;
[INFO] this.groupOperationHistory = groupHistory;
[INFO] this.groupOperationHistory != null &&
GroupOperationHistory.$addResourceOperationHistory(groupHistory, this);
[INFO] }
[INFO] com.google.gwt.dev.jjs.ast.JBlock
[INFO] [ERROR] at ResourceOperationHistory.java(129): {
[INFO] super(jobName, jobGroup, subjectName, operationDefinition,
parameters);
[INFO] this.resource = resource;
[INFO] this.groupOperationHistory = groupHistory;
[INFO] this.groupOperationHistory != null &&
GroupOperationHistory.$addResourceOperationHistory(groupHistory, this);
[INFO] }
[INFO] com.google.gwt.dev.jjs.ast.JMethodBody
[INFO] [ERROR] at ResourceOperationHistory.java(129): public
ResourceOperationHistory(null jobName, null jobGroup, String subjectName,
OperationDefinition operationDefinition, Configuration parameters, Resource
resource, null groupHistory);
[INFO]
[INFO] com.google.gwt.dev.jjs.ast.JConstructor
[INFO] [ERROR] at ResourceOperationHistory.java(98): final class
ResourceOperationHistory extends OperationHistory
[INFO] com.google.gwt.dev.jjs.ast.JClassType
[INFO] [ERROR] at Unknown(0): <JProgram>
[INFO] com.google.gwt.dev.jjs.ast.JProgram
At this point, I gave up. Perhaps
http://code.google.com/p/google-web-toolkit/issues/detail?id=6508 is
related.
11 years, 1 month
error in itests-2
by John Mazzitelli
Here's the latest enterprise/server/itest-2 failures I see:
Caused by: java.lang.NullPointerException
at org.rhq.enterprise.server.resource.ResourceFactoryManagerBean.deleteResource(ResourceFactoryManagerBean.java:688)
did something change in the ResourceFactoryManagerBean?
the test failure was at
org.rhq.enterprise.server.resource.test.ResourceFactoryManagerBeanTest.deleteHistory(ResourceFactoryManagerBeanTest.java:440)
Getting several test failures like this.
11 years, 1 month
itests-2 failure
by John Mazzitelli
I can't get itests-2 tests to run - i get an immediately failure:
Caused by: java.lang.IllegalArgumentException: Scope type import,provided is not supported.
Failed tests: arquillianBeforeSuite(org.rhq.enterprise.server.content.test.ProductVersionManagerBeanTest): Could not create new instance of class org.jboss.arquillian.test.impl.EventTestRunnerAdaptor
I am suspicious this might be due to the changes in the poms - this is a line pointed to in the stack trace:
dependencies.addAll(Arrays.asList(resolver.loadPomFromFile("pom.xml").resolve(thirdPartyDeps).withTransitivity().as(JavaArchive.class)));
Loading deps from pom.xml - and poms were recently changed.
Can anyone run the itests-2 tests? Trying to determine if it is just me.
11 years, 1 month
Fwd: [confluence] RHQ > Prerequisites
by John Mazzitelli
> From: "Changchun Hu (Confluence)" <docs-author(a)jboss.org>
> Sent: Thursday, March 21, 2013 9:17:00 PM
> Subject: [confluence] RHQ > Prerequisites
Changchun,
Don't edit the User Documentation for this MySQL stuff yet. Its not even in master - so it should not go in User Docs. People are going to see this and think MySQL is a supported backend and it is not yet.
This work goes in Design documentation location under Community since it is a work in progress and not yet in the released product.
Someplace under Community>Design Documentation would be the appropriate place for your wiki docs. Once the MySQL stuff actually gets committed into master would we then document it in the user documentation space.
John
11 years, 1 month
Dependency Versions - Makeover
by Stefan Negrea
Hello Everybody,
There is very little consistency in RHQ on where maven plugins and dependencies versions are located. Today we have every single possible variation allowed by maven. With a project of our size this is big problem because of possible conflicts between dependencies. Having versions all over the place leads to duplication and sometimes use of the same dependency but with different version in submodules. This is hard to manage to say the least...
This is how versions are declared/used today:
1) Everything in the room pom:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
</plugin>
2) In the root pom but the versions as a property:
the property:
<jboss-jmx.version>4.2.3.GA</jboss-jmx.version>
and then the dependency:
<dependency>
<groupId>jboss</groupId>
<artifactId>jboss-jmx</artifactId>
<version>${jboss-jmx.version}</version>
</dependency>
3) In a submodule (eg. modules/enterprise/server/ear) but use the property from root pom:
property in project root pom:
<quartz.version>1.6.5</quartz.version>
and then sub-module pom:
<dependency>
<groupId>org.opensymphony.quartz</groupId>
<artifactId>quartz</artifactId>
<version>${quartz.version}</version>
</dependency>
4) Everything in a submodule (eg. modules/enterprise/server/ear):
<dependency>
<groupId>org.yaml</groupId>
<artifactId>snakeyaml</artifactId>
<version>1.8</version>
<scope>provided</scope>
</dependency>
5) No version at all, inherited from parent poms (eg. modules/enterprise/server/jar):
<dependency>
<groupId>antlr</groupId>
<artifactId>antlr</artifactId>
<scope>provided</scope>
</dependency>
For some dependencies/plugins all 5 variations are used at the same time!!!
My proposal is to use just two patterns for declaring versions going forward:
1) Property in room pom:
<quartz.version>1.6.5</quartz.version>
and then use the property everywhere else:
<dependency>
<groupId>org.opensymphony.quartz</groupId>
<artifactId>quartz</artifactId>
<version>${quartz.version}</version>
</dependency>
2) Where applicable, no version at all in submodule pom but inherit from parent poms:
<dependency>
<groupId>antlr</groupId>
<artifactId>antlr</artifactId>
<scope>provided</scope>
</dependency>
I really like option 2 but it might not be applicable everywhere since a sub-module might be the only one using/requiring that dependency.
I would like to updated all the poms before the github migration due to the repository split (core, plugins, helpers). It will be easier to make the changes now and we will start on github with something consistent across all three projects.
Any thoughts? Any other ideas on how to solve this?
Thank you,
Stefan Negrea
Software Engineer
11 years, 1 month
github, restructuring and versioning
by Jay Shaughnessy
Starting a new thread to consolidate some thoughts in the other two
threads...
After reading through the github migration threads and wiki, I see it
actually involves a few different things:
- The actual migration.
- Proposed pull-request workflows.
- The split to multiple repositories.
- Versioning schemes.
The actual migration plan is detailed and Heiko looks to have done a
good job of mapping out the details of how it will happen, including a
dry-run.
The new workflows look promising, especially from a code-review
perspective. I think we'll need that written up more formally for
ourselves and contributors. And maybe have a good demo for the team so
people (like me) get a good grasp of what we'll be doing. These
processes are also something we can modify as we go.
I'm OK with the idea of breaking RHQ into 3 pieces, core, plugins, and
helpers. I think it will be helpful to plugin developers to potentially
work with a smaller codebase, and a clearly identified helper project.
I also think the decision to avoid further granularity is a good one.
We will need to add some Jenkins jobs, but I don't think it will be an
unmanageable number (it's not 3 times the number we have today). And we
will likely need to update our release processes, again. Keeping the
platform plugin in core makes sense so that core can actually run on its
own, and also for anyone that plans to use only custom plugins.
It's the proposed dependency versioning that I'm questioning.
I'm not convinced there is real benefit to plugin writers or
contributors by having rhq-plugins/master depend on a released version
of rhq-core. In short, what's wrong with instead asking the developer to
git checkout rhq-plugins/release-X rather than rhq-plugins/master?
A plugin developer does not need to build rhq-plugins/master to develop
a new plugin. On the other hand, rhq-helpers/master, plugin-gen in
particular, would benefit from depending on released artifacts. In that
case the plugin dev could build the generator easily, against deps
published in central, and run a real server/agent of the same version,
installed from product dists.
As for working on an existing plugin; an enhancement or bug fix could be
built against rhq-plugins/release-X. Rhq-plugins/release-X is easily
built against central. The feature or fix would be compatible with the
published version of core.
Using 4.6 as an example, if we had an rhq-plugins/release-4.6 branch, a
developer could opt to build this branch against the published
artifacts, and make a fix or enhancement to the 4.6 plugin. Work
committed here could be cherry-picked to master as needed. If in fact
the developer or contributor elected to work with master they certainly
could, in the same manner as today, by building rhq-core/master and
working with the snapshot version.
As a further example, let's say someone finds a bug in the 4.6 AS7
plugin. It could be fixed against rhq-plugins/release-4.6 by anyone,
without having to build core. It could also be fixed in
rhq-plugins/master with a full dev environment, and cherry-picked back.
And rhq-plugins-4.6.1 could be released without a need to release a new
core/server.
The current proposal on the wiki is to have rhq-plugins/master depend on
rhq-core's current release version, and not on rhq-core/master's
snapshot version. This will certainly make development more difficult.
One immediate example will be the new provisioning implementation. This
feature development will involve new facets, change to the plugin
descriptor, and introduce other dependencies between plugin code and the
[core] container. A strategy that forces the plugin code to conform to
rhq-core's release version will make this very hard.
Let's talk a bit about plugin/core compatibility. As it stands today (I
believe) an agent plugin can be dropped into an RHQ server, and we don't
really validate it, we assume that it is compatible. Assuming the plugin
descriptor parses, and metadata updates succeed, we're good on the
server and the agent is free to pull it down. It's pretty loose. That
doesn't really have to change. Plugin release cadence is not really
dependent on rhq-server version. It simply has to be compatible.
Developing against a release version will give you that and (unless
using deprecated features that are going away) will give you
compatibility with the next release. But, to ensure timely release of a
plugin leveraging new features of core, it must be easily developed
against core's snapshot version. To prevent this will make things
difficult, likely force unnecessary core releases, and create lag times
between core and plugin releases.
The benefit of being able to check out and build rhq-plugins/master
without needing to also build rhq-core/master, does not seem to be
enough to merit the downside to plugin development and release.
11 years, 1 month
Virtual platforms / synthetic agents
by Heiko W.Rupp
Hi,
the REST-api allows to create platforms programmatically - removing resources on that platform or the platform itself ends up in
a (harmless) stack trace in the server log. I've created a patch, but obviously, as mazz indicated, the issue is a larger one.
I've stated (yet another) wiki page to capture this and some thoughts around it
https://docs.jboss.org/author/display/RHQ/Virtual+platforms+and+synthetic...
Heiko
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera
11 years, 1 month