Interesting - where do the ActiveMQ-specific parts live then? I understand how the JMX-parts can be done without an activemq-specific dependency, although they could easily be used in a way that creates a dependency (e.g. coding the ObjectNames of specific MBeans).
Reading through one of the other chains of email, I understood there are activemq-specific parts in hawt.io. Using the UI, I recall seeing an "ActiveMQ" tab, which further gives the impression that must be so. BTW, not having server-side code, and being able to run against various broker versions, isn't adequate to avoid a circular dependency. Any part of the solution that breaks if the server-side changes, together with the console being pulled into ActiveMQ, making it so that ActiveMQ is now dependent on the console, creates the circular dependency. Just look at the poms; if activemq's poms have a dependency on hawt.io and hawt.io's poms have a dependency on activemq, then it's circular. A better test than the poms check is this: if a change to project A might require a simultaneous change to project B, and the same change to project B requires a simultaneous change back in project A, it's a circular dependency. I can't even figure out how one would solve the problem of releases in this case since it would not be possible to build a release (and upload to Nexus) of either project without first releasing (and uploading) the other. Of course, that dilema only arises once such a two-way change is made - meaning its entirely feasible to get into that situation well after the circular dependency has been created. This really raises an interesting question for me. Isn't Hawt.io built to integrate multiple solutions intelligently? If that's so, it's a higher-level abstraction than any one of those solutions, and therefore doesn't really belong inside any one of them. Consider, if you will, if I have 3 tools that hawt.io manages, I wouldn't want three separate instances of Hawt.io - one in each of the 3 tools; that defeats the point. Perhaps a viable approach for Hawt.io is to define a standard interaction between the UI and any tool it will manage, drive that down as a lower-level dependency (i.e. have its own project), and then use that standard to communicate with each tool. JMX fits that model already. Joolokia also fits that - unless I'm mistaken. However, JMX and Joolokia might be too low level and, therefore, not ensure the interactions Hawt.io really needs. By the way - why put hawt.io into ActiveMQ? Just the desire to stop maintaining the old console and have a nicer console? Hawt.io can be used with ActiveMQ even though it's not built-in to ActiveMQ, right? > > > On 4 February 2014 04:27, artnaseef <[email protected]> wrote: > >> By the way, on the topic of using an external console to replace the >> current >> built-in console, there's very real concern with circular dependency. >> > > > FWIW there's no circular dependency with hawtio; it contains no server > side > parts and can run against ActiveMQ 5.x, 5.8, 5.9, 5.10 et al just fine. > > -- > James > ------- > Red Hat > > Email: [email protected] > Web: http://fusesource.com > Twitter: jstrachan, fusenews > Blog: http://macstrac.blogspot.com/ > > Open Source Integration > > > > > _______________________________________________ > If you reply to this email, your message will be added to the discussion > below: > http://activemq.2283324.n4.nabble.com/ActiveMQ-Console-let-s-get-the-problem-defined-tp4677105p4677377.html > To start a new topic under ActiveMQ - Dev, email > [email protected] > To unsubscribe from ActiveMQ Console - let's get the problem defined, > visit > http://activemq.2283324.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4677105&code=YXJ0QGFydG5hc2VlZi5jb218NDY3NzEwNXwtMjA1NDcyNjY5MQ== -- View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-Console-let-s-get-the-problem-defined-tp4677105p4677394.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
