Red Hat Bugzilla – Full Text Bug Listing
|Product:||[Other] RHQ Project||Reporter:||Ian Springer <ian.springer>|
|Component:||Build System||Assignee:||RHQ Project Maintainer <rhq-maint>|
|Status:||CLOSED WONTFIX||QA Contact:||Mike Foley <mfoley>|
|Version:||1.2||CC:||ccrouch, cwelton, jshaughn|
|Target Milestone:||---||Keywords:||FutureFeature, Task|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-05-06 16:33:12 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Ian Springer 2009-07-10 13:15:00 EDT
This will make it easier to use EMS in our Maven ecosystem. It will easier to publish new versions (including snapshot jars), and we'll be able to use a snapshot dep on EMS in between releases. It will also allow us to more easily build and publish sources and javadoc jars to the Maven repo.
Comment 1 Red Hat Bugzilla 2009-11-10 16:00:22 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2227
Comment 2 wes hayutin 2010-02-16 10:44:56 EST
mass move off the qa triage list. These are tasks for dev.
Comment 3 Joseph Marques 2010-11-17 12:48:19 EST
Ian, now that we have Mazz's fancy new isolating/hiding classloader within the agent, what do you think of removing our dependency on EMS altogether?
Comment 4 Ian Springer 2010-11-24 11:51:11 EST
I like the idea, because it would remove the external dependency and leverage our existing classloading framework. However, I'm guessing it would be 8-15 days of work (which would include lost of regression testing of the as4 and as5 plugins to make sure all the JMX-based availability checks, metrics, and operations still work), so it's hard to justify the effort for something that won't introduce any new functionality. As for the original issue, I think Mavenizing EMS would take about 2-4 hours.
Comment 5 Joseph Marques 2010-11-24 16:00:25 EST
To be clear, this shouldn't be a comparison between the amount of time it takes to mavenize some framework versus the time it takes to do something with or without that framework. ----- Although it wouldn't introduce any new functionality, it would lower the maintenance burden (one less library that can have errors in it) while lowering heap and perm gen footprint. As such, I think it's something that should eventually be the target we push towards. As a proof of concept, we could create a feature branch and do the migration only for the JMX and JBossAS plugins, to see what effect that has on memory and performance profiles.