Description of problem: While investigating another BZ it was found that the maven build dependencies for enterprise-server.jar included a circular dependency, which has been there for quite some time. As this was found in the middle of an RC interation we worked around the problem but this needs to be fixed later. See below for more details. Feb 08 14:52:10 <ips> so client-api depends on server-jar, which depends on client-api Feb 08 14:52:14 <spinder> so does that mean that we're stuck with the enterprise-server jar in the lib? Feb 08 14:52:18 <ips> sounds like a circular dep to me Feb 08 14:52:53 <ips> spinder: i don't think so. i don't think server-jar should even depend on client-api at all Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce/IRC convo details: <ips> and client-api is pulled in by server-jar Feb 08 14:52:10 <ips> so client-api depends on server-jar, which depends on client-api Feb 08 14:52:14 <spinder> so does that mean that we're stuck with the enterprise-server jar in the lib? Feb 08 14:52:18 <ips> sounds like a circular dep to me Feb 08 14:52:53 <ips> spinder: i don't think so. i don't think server-jar should even depend on client-api at all Feb 08 14:53:08 <ips> client-api is meant to be used by the CLI or by custom java clients Feb 08 14:53:28 <spinder> ah .. taking a step back that makes sense. Feb 08 14:53:36 <ips> i'd look at the git log for server/jar/pom.xml and see if that dep was recently added Feb 08 14:54:01 <pilhuhn> we had such an inconsistency for quite some time. Feb 08 14:54:17 <jshaughn> neither of those poms changed since RC2 was cut Feb 08 14:54:22 <pilhuhn> If you did an enterprise build, the one version of server-jar was pulled in (and I think core-domain too) Feb 08 14:54:47 <jshaughn> I think Feb 08 14:54:52 <pilhuhn> if you did a -Pdev build in server/jar, the result ended directly in rhq.ear and not rhq.ear/lib (or vice versa) Feb 08 14:55:07 <pilhuhn> I think I even reported that some time ago Feb 08 14:58:19 <spinder> server/jar/pom.xml added a new dependency on rhq-container-lib .. but it's the changes to the client-api/pom.xml that are causing these two new copies to show up in rhq.ear/lib Feb 08 14:59:57 * shaines is now known as shaines-mtg Feb 08 15:00:51 * spagop (~spagop.redhat.com) has joined #jboss-on Feb 08 15:02:14 <spinder> since that circular dep has been there for awhile now I could break quite a few things. Hmm. Now that I understand why the extra dependencies showed up I may just modify the server.jar to finish the release then tackle circular dependency resolution at a later date. Feb 08 15:02:49 <jshaughn> why did they not show up in RC2? Feb 08 15:03:58 <spinder> this showed up because with the recent JNDI changes caused the extra copy of server.jar in the ear .. Feb 08 15:04:29 <spinder> which put an old copy of ProductInfo.properties in the classpath ahead of the ones we intended to load. Feb 08 15:04:52 <spinder> so fixes that went in to RC3 changed the landscape a little and it bit us. Feb 08 15:05:50 <spinder> the dependency hierarchy has been there for a while. But the extra .props file has not. Feb 08 15:08:15 <ips> spinder: if you want to workaround it for now rather than fixing the circular dep Feb 08 15:09:02 <ips> then i think you can just add exclusions for those 2 jars to the server jar dep in the ear pom Feb 08 15:09:36 <ips> but we really should fix this properly in master Actual results: N/A Expected results: No circular dependency. Additional info:
FWIW, server jar, I think, has to depend on client-api. client-api defines all of the server services, which are implemented in server jar classes. I'm not sure you'll be able to fix this any better than what's already been done for bug 789039.
"client-api defines all of the server services, which are implemented in server jar classes." Then it sounds like client-api should not be depending on server.jar. But then as Jay says, we may just have to fix this like bug 789039.
how can client-api depend on server/jar? client-api is for inclusion both in the server AND THE AGENT. The agent can't have server/jar in its classpath.
wait - which client-api are we talking about? there is core/client-api (which is the one I'm familiar with - this is the API between server and agent) and there is enterprise/remoting/client-api (which is one I am not familiar with - looks CLI related) I assume, reading the rest of the comments, we are talking about this latter one (the remoting/CLI one)
i think its due to this in the client-api pom.xml <dependency> <groupId>${project.groupId}</groupId> <artifactId>rhq-script-bindings</artifactId> <version>${project.version}</version> </dependency> which, in turn, depends on rhq-enterprise-server
I think this was introduced by this commit: 8e0df522a432a66392d428aeb8e86a71c6d1061e whose commit message says "Starting to rip out common ScriptEngine bindings out of the CLI code into a reusable component that could be used on the serverside without a standard input attached." So obviously, this was done on purpose - this stuff is supposed to be in the CLI and the server. Therefore, I doubt it will be trivial to actually REMOVE this circular dependency, since its obviously done on purpose that this client-api is meant to be in the CLI and server.
Here is the original BZ that was being worked that led to the creation of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=788603 Here's the commit where this was fixed in the release branch: 4e86eace4a3f0511afee26db461720d2988 It should be noted that this issue showed up because we were doing special product branding steps for a JON release. I am not certain if this fix needs to be applied for an RHQ community release build.
looks like this was already fixed in master by jay on 2/9/2012 - see commit 34d9cc0624bc871b6092acc27a734751c7823566 When I say fixed, I mean the same maven exclusions were added to the ear pom as was done in the release branch. the circular dependency still exists, which on the face of it seems correct - since both need each other.
this was fixed and verified earlier.
Bulk closing of old issues in VERIFIED state.