Bug 789124 - circular dependency in the server/jar/pom.xml
circular dependency in the server/jar/pom.xml
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Build System (Show other bugs)
4.3
Unspecified Unspecified
high Severity low (vote)
: ---
: JON 3.1.0
Assigned To: John Mazzitelli
Mike Foley
:
Depends On:
Blocks: jon310-sprint11/rhq44-sprint11
  Show dependency treegraph
 
Reported: 2012-02-09 16:13 EST by Simeon Pinder
Modified: 2013-09-03 11:01 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-03 11:01:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Simeon Pinder 2012-02-09 16:13:24 EST
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@vpn1-6-65.ams2.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:
Comment 1 Jay Shaughnessy 2012-03-15 16:54:33 EDT
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.
Comment 2 Charles Crouch 2012-03-23 10:22:37 EDT
"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.
Comment 3 John Mazzitelli 2012-03-28 11:25:49 EDT
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.
Comment 4 John Mazzitelli 2012-03-28 11:30:06 EDT
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)
Comment 5 John Mazzitelli 2012-03-28 15:39:05 EDT
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
Comment 6 John Mazzitelli 2012-03-28 15:52:01 EDT
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.
Comment 7 Simeon Pinder 2012-03-28 16:40:00 EDT
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.
Comment 8 John Mazzitelli 2012-03-29 08:27:18 EDT
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.
Comment 9 Mike Foley 2012-04-20 14:27:12 EDT
this was fixed and verified earlier.
Comment 10 Heiko W. Rupp 2013-09-03 11:01:57 EDT
Bulk closing of old issues in VERIFIED state.

Note You need to log in before you can comment on or make changes to this bug.