The intention of the -api projects was to split out what TIM-
implementors might need to compile against when building a TIM that
does things like class replacement or modification or programmatic
configuration. I think what we have now is basically a rough draft.
I've been through it in the past and there are some gaps.
I think we should avoid splitting things out into a series of both -
api and -jmx projects - I think that goes too far. If it makes sense
to move the jmx stuff into 1 or 2 projects then maybe that would make
sense. I have a hard time proposing an alternative solution as I
don't know the jmx classes that well.
Why is the size of the archive important in this case?
On Apr 5, 2008, at 7:17 PM, Gary Keim 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
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
