EHC ❯ Create 2 kits for Brisbane
-
New Feature
-
Status: Closed
-
0 Showstopper
-
Resolution: Fixed
-
ehcache
-
-
hhuynh
-
Reporter: hhuynh
-
November 02, 2009
-
0
-
Watchers: 0
-
November 16, 2009
-
November 08, 2009
Description
For Brisbane we will actually need TWO kits.
The first kit is just the monitoring bits. This is designed to be used by developers who already have ehcache. It is closed source, but available ‘free’ - behind a sign up form. Free means that they can use it in development (this will be spelled out in the license) with whatever enforced restrictions we place on it (timebomb etc).
The second is the actual “Ehcache DX” kit - the enterprise kit for paying (and trial) customers. This should be an enterprise kit that includes both Ehcache itself and the monitoring bits. Customers will get this kit and a license. If they escalate bugs on this kit we will deliver patches to it (as we do with the Terracotta EE kit).
For the beta we only need the first kit.
Comments
Alex Miller 2009-11-02
Alex Miller 2009-11-04
Re jsvc:
What is expected is: 1) We should supply basic start/ stop *nix and Windows scripts as usual. These don’t depend on jsvc or do anything unusual. 2) The monitor project should depend on commons-daemon (primarily for the Daemon interface) 3) The monitor server main class should implement the org.apache.commons.daemon.Daemon interface (basically a few control methods like start(), stop(), destroy(), etc.) See net.sf.ehcache.server.standalone.Server as an example (in the ehcache standalone-server project) - that’s doing embedded Glassfish but we should be doing the moral equivalent with Jetty. If it makes sense we might even wrap the normal main class with a jsvc-specific class - I’ll leave that to the implementation but I don’t want the mess of an additional Maven project so don’t go that far. 4) In the monitoring kits we should provide the equivalent of what you see in the standalone-server/src/assemble directory. I would recommend treating jsvc as an independent part of the kit (to be ignored if you don’t care):
/bin unix/win start/stop scripts - not jsvc /bin/daemon RUNNING.txt - copy from standalone-server (the jsvc parts at least) daemon_start.sh daemon_stop.sh jsvc.tar.gz - the jsvc impl - to use you will need to untar / make / configure etc init.d - example script someone could use with jsvc
Kalai Kannaiyan 2009-11-16
Verified that the ehcache-monitor-1.0.0-beta and ehcache-dx-1.7.1-SNAPSHOT are created successfully.
Steps:
- svn co https://svn.terracotta.org/repo/internal/ehcache-enterprise/ehcache-dx/trunk
- mvn clean install -DskipTests from root
- Navigate to /monitor-kit and execute mvn clean assembly:assembly
Actual: ehcache-monitor-1.0.0-beta-distribution.tar.gz monitor kit is created under /moniotr-kit/target which contains monitor and probe jars
- Navigate to dx-kit
- execute mvn clean assembly:assembly
Actual: ehcache-dx-1.7.1-SNAPSHOT-distribution.tar.gz ehcache-dx kit is created under dx-kit/target which contains monitor, probe and ehcache-ccore-1.7.1-SNAPSHOT jars
Hey Mike, sorry I missed reading this more closely but I caught it when it hit jira. On the second kit, isn’t this rather just adding more stuff to our existing ehcache kits? Wouldn’t it be easier to just stuff the new probe/server into the existing kits and just ship people a DX license? I guess the reason would be as that is an “enterprise” product?
We have these kits now:
And you are looking for new additional kits:
Maybe a separate wrinkle is that there is no ehcache-terracotta kit for active-active users (I guess that’s FX, not DX). We do have a Terracotta FX kit with a licensed enterprise version of the ehcache/terracotta integration but that’s only in the Terracotta FX kit). Presumably we need to add the monitoring stuff in there too?
Currently the monitoring stuff is in a private svn repo (since it’s not open source). To create the new kits, I guess we would need new assembly processes in the private repo that could pull from both public and private?