Current api/"spi like" is not friendly and cli dep is often an issue for
not standalone case.
Le 18 mai 2016 23:12, "Daniel Cunha" <daniels...@gmail.com> a écrit :

> 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 <rmannibu...@gmail.com
> >
> wrote:
>
> > 2016-05-18 19:44 GMT+02:00 Daniel Cunha <daniels...@gmail.com>:
> >
> > > 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 <
> > > rmannibu...@gmail.com>
> > > 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
>

Reply via email to