Forgot to weigh in on the project structure thing ... in case it does go through.
I think that the JMX utilities should have a dedicated project, but not that the MBean interfaces of each sub-project should be thrown together inside a dedicated project. As you said, the serializable classes that are used in those should also have to be transferred to that dedicated JMX project and imho that goes too far. In many case, those classes are used by other parts of the code, and JMX is just one 'user' of them. Maintenance-wise, they should remain in their respective projects. That being said, nothing prevents a jar being built that contains exactly what's needed for JMX access, using the existing project structure. The downside is though that the maintenance of the jar will be tedious to say they least. However, I think that is a much better solution to take all MBean interfaces and what they use and stuff them in a single über-mbean project, just to make packaging easier. On Sun, Apr 6, 2008 at 2:17 AM, Gary Keim <[EMAIL PROTECTED]> wrote: > > > > > Community, > > > > We have a desire to break out everything one would need to interact with a > TC cluster via JMX into a separate archive for use by, for instance, the > upcoming VisualVM plugin or really anyone else that doesn't want to drag in > all of tc.jar just to make a JMX call to a TC process. This is basically a > refactoring exercise. > > > > Now, we currently have projects that are suffixed by –api but I'm not really > sure of their purpose because many of them contain implementations. The size > of an archive built from them is significant. We also have JMX MBean > interfaces scattered around many of the projects. Does anyone think it a > good idea to create a single project that contains all JMX-related > artifacts, including but not limited to MBean interfaces, serializable pojos > returned from those MBeans, JMX utilities like JMXConnectorProxy, etc. This > doesn't feel good because it's like cats and dogs living together. > > . > > The other alternative is to create –jmx projects along the same lines as the > –api projects. For example, dso-l1-api has about 5 artifacts that are > JMX-related and many more that are not: dso-l1-jmx? The downside to this is > project proliferation… which we sort of already have. > > > > Thoughts, opinions and suggestions are welcomed. > > > > Gary > > > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev > > -- Geert Bevin Terracotta - http://www.terracotta.org Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
