Hi Romain, yep, I like the way how cli was implemented in BatchEE. Sounds really good and I don't have opposition to follow the same way. When you say: Technical issues. What do see like a problem?
On Wed, May 18, 2016 at 2:49 PM, Romain Manni-Bucau <[email protected]> wrote: > 2016-05-18 19:44 GMT+02:00 Daniel Cunha <[email protected]>: > > > We (Me and Hildeberto) proposed some ideas (in Clojure), but out of the > box > > some time ago. But wasn't well accept, I guess. > > > > > Yes clojure is an issue for 2 reasons as main interface: > - its syntax is not user friendly (don't get me wrong, just means peolpe > expects a sh like syntax for a cli) > - its dependencies we should avoid IMO > > > > +1 for your idea. > > I really think that we need improve CLI. I see some tips about it on > > twitter (https://twitter.com/rdebusscher/status/718081027604873216) :) > > > > > Yep, we also can check what we did in BatchEE ( > > https://github.com/apache/incubator-batchee/tree/master/tools/cli/src/main/java/org/apache/batchee/cli > ). > It is an annotation based impl on top of [cli] but the interesting part is > not much the API but the fact it is user extensible and it also allows to > run small tasks like batches easily (start, deploy, run, shutdown). > > The potential is huge but first we need to get rid of the technical issues > I think. > > > > On Wed, May 18, 2016 at 10:04 AM, Romain Manni-Bucau < > > [email protected]> > > wrote: > > > > > Hi guys, > > > > > > Spoke with Andy and Jean-Louis and seems we could make our CLI a bit > > > better. > > > > > > So let's write down some proposal and then see 1. if we go this path, > 2. > > > how > > > > > > ## Proposal > > > > > > Make our CLI richer in term of feature and commands and more user > > friendly. > > > > > > Bonus: getting rid of commons-cli would allow us to have a better > > > dependency management than today for all shade flavors we have. > > > > > > ## Technically > > > > > > 1. We can replace [cli] by our light backbone or a shade (minimized) - > > and > > > then optimize/clean our shades (tomee embedded *) > > > 2. We move commands glue code from openejb-core to openejb-cli (or > > whatever > > > other modules) - to ensure it is reusable and easy to test > > > 3. We change the registration process to use a standard ServiceLoader? > > > (Easier for users to extend it/more natural) > > > 4. We use annotations instead of properties (same as previous) > > > 5. add alias support (typically Andy brings "cipher" vs "cypher" > handling > > > which is a common mistake) > > > 6. add matching feature: "./tomee.sh cip" is not ambiguous so we can > > match > > > cipher command (algo is: if not ambiguous execute otherwise fail) > > > > > > There are probably more doors open but that's the start I see/have in > > mind. > > > > > > ## Commands > > > > > > Currently available: > > > > > > - cipher: encode/decode a string to use with a PasswordCipher > > > - effectivetomee: list the loaded tomee.xml (actual one, not the file > > > itself) > > > - properties: dump tomee server configuration (same as effective tomee, > > > that's the internal model) > > > - setters: list field usable for a class (to use with <Resource/>) > > > - start: start the server (delegates to catalina.sh) > > > - stop: stop the server (delegates to catalina.sh) > > > - deploy: deploy an app > > > - undeploy: undeploy the app > > > > > > Note: deploy/undeploy commands are to rework a bit to be useful I guess > > > (the current "id" is the path and is not natural IMO) > > > > > > We can add: > > > > > > - add-resource (add in tomee.xml a resource and deploy it if running) > > > - modify-resource (change a property) > > > - add/remove-property > > > - jmx-attribute > > > - jmx-operation > > > - ... > > > > > > ## Next steps > > > > > > 1. Please say you think it is a good track or just an idea we can kill > > > (happens ;)). > > > 2. If we are rather positive about that I think it is a good > opportunity > > to > > > get newcomers to TomEE. Part of the code is aside tomee (cli one) and > the > > > commands themself are done or almost there for most of the ones I > listed. > > > It just needs some integration and clean up so that's a great way to > get > > > familiar with TomEE internals and model. That said I'm super happy to > > help > > > anyone or code some part if needed. > > > > > > Finally this track would allow us to: > > > > > > - own the CLI code and dependencies making us controlling our deps on > the > > > whole chain (for shades and light deployments) > > > - make our CLI more user friendly > > > - open the door to custom commands more easily > > > - rework the commands to add some missing ones > > > > > > > > > Romain Manni-Bucau > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > <http://rmannibucau.wordpress.com> | Github < > > > https://github.com/rmannibucau> | > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber > > > <http://www.tomitribe.com> | JavaEE Factory > > > <https://javaeefactory-rmannibucau.rhcloud.com> > > > > > > > > > > > -- > > Daniel Cunha > > https://twitter.com/dvlc_ > > > -- Daniel Cunha https://twitter.com/dvlc_ http://www.tomitribe.com http://www.tomitribe.io
