Bug 844700

Summary: RFE: Disallow deploying plugins incompatible with server or plugin API
Product: [Other] RHQ Project Reporter: Libor Zoubek <lzoubek>
Component: Agent, Core ServerAssignee: RHQ Project Maintainer <rhq-maint>
Status: NEW --- QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.4CC: hrupp, kejohnso, theute
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Libor Zoubek 2012-07-31 08:32:06 EDT
Description of problem:

Recently, I've caught this on IRC:

<nsaad> hello folks
<nsaad> i have a quick question, onsite with a consultant at an unhappy client
<nsaad> trying to get some jon issues resolved
<nsaad> when the agent starts (jon 3.0.1 installed), after it starts up, it throws an error
<nsaad> NoClassDefFoundError: org/rhq/core/pluginapi/util/JavaCommandLine

After some search in git history, I've found out, that JavaCommandLine class has beed introduced in JON 3.1. This means that customer probably successfully  deployed 3.1 plugin (that depends on 3.1 plugin API) to JON 3.0.1.

I've also verified, that I can deploy JON 3.1 plugins to JON 3.0 and I am having same error (and much more) in agent.log as nsaad.

We should prevent users doing so.

We should start versioning our plugin API and force our plugins to include something like <require "1.2.3" /> in rhq-plugin.xml. With this information we could fail deploying plugins that require higher plugin API that is avaiable on server. User would quickly figure out what's wrong.

Version-Release number of selected component (if applicable):
RHQ 4.5.0 master