Bug 535543 (RHQ-2227)
Summary: | Mavenize EMS | ||
---|---|---|---|
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> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 1.2 | CC: | ccrouch, cwelton, jshaughn |
Target Milestone: | --- | Keywords: | FutureFeature, Task |
Target Release: | --- | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://jira.rhq-project.org/browse/RHQ-2227 | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-05-06 20:33:12 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Ian Springer
2009-07-10 17:15:00 UTC
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2227 mass move off the qa triage list. These are tasks for dev. 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? 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. 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. |