This would need to be implemented in AEsh project. I'm not sure if
I'll have time for this. I've created issue here:
2014-06-28 14:33 GMT-07:00 Antonio Goncalves <antonio.mailing(a)gmail.com>:
Yes, that looks nice. With TAB completion it will even make it easier
:
java-new-method --body <PRESS TAB> (and the completion will show
""")
2014-06-28 6:33 GMT+02:00 Robert Balent <robert(a)balent.cz>:
> It definitely looks better without escaping but question is how do
> distinguish between char and String literal of size 1? Other
> possibility which comes to my mind is to add to the forge some
> special sequence which will disable parsing for the part of the text
> so we could have for example special sequence like this """ and the
> command would look like this:
>
> java-new-method --return String.class --parameters "String s, boolean
> b, List<Integer> numbers" --body """String msg; if
> (s.equals("withinSimpleQuote") { msg="singleQuote"; return msg;
})"""
>
> Robert
>
>
> 2014-06-27 14:47 GMT-07:00 Antonio Goncalves <antonio.mailing(a)gmail.com>:
> > Hum.... escaping doesn't look nice. And what about using simple quote ?
> > What
> > about :
> >
> > java-add-annotation --annotation "TestAnnotation(param1 = 'str1',
> > 'str2'},
> > param2 = 'hello', param3 = {String.class, Main.class}, param4 =
> > ENUM_VAL,
> > param5
> > {ENUM_VAL_1,ENUM_VAL_2,ENUM_VAL_3})"
> >
> > Would that be bad ? Any gotchas ? I hope one day we will be able to add
> > method bodies in Forge, and escaping will not help in readabilty.
> > Something
> > like :
> >
> > java-new-method --return String.class --parameters "String s, boolean b,
> > List<Integer> numbers" --body "String msg; if
> > (s.equals('withinSimpleQuote')
> > { msg='singleQuote'; return msg; })"
> >
> > If escaping is used, then we will have :
> >
> > java-new-method --return String.class --parameters "String s, boolean b,
> > List<Integer> numbers" --body "String msg; if
> > (s.equals(\"withinSimpleQuote\") { msg=\"singleQuote\";
return msg; })"
> >
> > It just doesn't look nice... But I suppose it's clearer for Java
> > developpers
> > who are used to it.... hum.... dilema....
> >
> > Antonio
> >
> >
> >
> > 2014-06-27 9:45 GMT+02:00 Robert Balent <robert(a)balent.cz>:
> >
> >> Hi,
> >>
> >> I've added test and code for handling exceptions. Parameters should be
> >> working now. For example this works OK:
> >>
> >> java-add-annotation --annotation "TestAnnotation(param1 =
> >> {\"str1\", \"str2\"}, param2 = \"hello\",
param3 = {String.class,
> >> Main.class}, param4 = ENUM_VAL, param5 =
> >> {ENUM_VAL_1,ENUM_VAL_2,ENUM_VAL_3})"
> >>
> >> Code doesn't look that good, it will probably need a little
> >> refactoring. I'll be happy if you comment about what could be
> >> improved.
> >>
> >> Best,
> >> Robert
> >>
> >>
> >> 2014-06-26 20:54 GMT-07:00 Robert Balent <robert(a)balent.cz>:
> >> > I'm using "Roaster.parse" method for parsing so if
it's not parsed
> >> > correctly, it will throw exception. I'll add exception handling
and
> >> > tests today.
> >> >
> >> > 2014-06-26 12:10 GMT-07:00 Lincoln Baxter, III
> >> > <lincolnbaxter(a)gmail.com>:
> >> >> Hey Robert, this is excellent! Do you think you could add a test
for
> >> >> this
> >> >> advanced "escaped/complex" parsing?
> >> >>
> >> >> Thanks!
> >> >>
> >> >>
> >> >> On Thu, Jun 26, 2014 at 3:18 AM, Robert Balent
<robert(a)balent.cz>
> >> >> wrote:
> >> >>>
> >> >>> Parse input as java code is good idea. However parentheses have
to
> >> >>> be
> >> >>> escaped in Forge shell.
> >> >>>
> >> >>> Have look at pull request 474 [1]. I've tried to implement
this and
> >> >>> if
> >> >>> the input is correctly escaped, it should be working.
> >> >>>
> >> >>> Example:
> >> >>>
> >> >>> java-add-annotation --annotation
javax.inject.Named(\"beanName\")
> >> >>>
> >> >>>
> >> >>> Also more complicated examples like this are working:
> >> >>>
> >> >>> java-add-annotation --annotation "TestAnnotation(param1 =
> >> >>> {\"str1\",
> >> >>> \"str2\"}, param2 = \"hello\", param3 =
{String.class, Main.class},
> >> >>> param4 = ENUM_VAL)"
> >> >>>
> >> >>>
> >> >>> Cheers,
> >> >>>
> >> >>> Robert
> >> >>>
> >> >>>
> >> >>> [1]
https://github.com/forge/core/pull/474
> >> >>>
> >> >>>
> >> >>>
> >> >>> 2014-06-24 22:40 GMT-07:00 Lincoln Baxter, III
> >> >>> <lincolnbaxter(a)gmail.com>:
> >> >>> > I think maybe we need to separate the parameters out in
this
> >> >>> > case:
> >> >>> >
> >> >>> > ejb-new-bean --beanName foo --typeName FooBar
> >> >>> >
> >> >>> > We should decide what these parameters need to be called.
> >> >>> >
> >> >>> > In addition, I'm fine with the java-add-anotation
command as well
> >> >>> > :)
> >> >>> > It
> >> >>> > could probably even accept full java code:
> >> >>> >
> >> >>> > java-add-annotation
javax.inject.Named("beanName") --target .....
> >> >>> >
> >> >>> >
> >> >>> > On Sun, Jun 15, 2014 at 4:41 PM, Antonio Goncalves
> >> >>> > <antonio.mailing(a)gmail.com> wrote:
> >> >>> >>
> >> >>> >> Here is the JIRA :
https://issues.jboss.org/browse/FORGE-1880
> >> >>> >> (Being
> >> >>> >> able
> >> >>> >> to add @Named to an EJBs... or any annotation
anywhere)
> >> >>> >>
> >> >>> >> I've linked it to
https://issues.jboss.org/browse/FORGE-1838
> >> >>> >> (Being
> >> >>> >> able
> >> >>> >> to generate methods) because at the end of the day,
the idea
> >> >>> >> behind
> >> >>> >> both
> >> >>> >> JIRAs is being able to add Java artifacts
(attributes,
> >> >>> >> annotations,
> >> >>> >> methods...) to any kind of component (entity, backing
bean, rest
> >> >>> >> endpoint...)
> >> >>> >>
> >> >>> >>
> >> >>> >> 2014-06-13 16:00 GMT+02:00 George Gastaldi
> >> >>> >> <ggastald(a)redhat.com>:
> >> >>> >>
> >> >>> >>> +1, is there a JIRA already for this?
> >> >>> >>>
> >> >>> >>> Em 13/06/2014, às 10:51, "Ivan St.
Ivanov"
> >> >>> >>> <ivan.st.ivanov(a)gmail.com>
> >> >>> >>> escreveu:
> >> >>> >>>
> >> >>> >>> Hi folks!
> >> >>> >>>
> >> >>> >>> I think that java-add-annotation is a good command
that we
> >> >>> >>> should
> >> >>> >>> have.
> >> >>> >>> But still it would be better to have also
something more
> >> >>> >>> explicit
> >> >>> >>> for
> >> >>> >>> creating named beans and setting stereotypes. So,
I think that
> >> >>> >>> the
> >> >>> >>> three
> >> >>> >>> levels of abstraction that Antonio described may
be
> >> >>> >>> implemented.
> >> >>> >>> Well,
> >> >>> >>> at
> >> >>> >>> the end they will reuse one and the same code for
adding
> >> >>> >>> annotation,
> >> >>> >>> so no
> >> >>> >>> repeating ourselves will occur.
> >> >>> >>>
> >> >>> >>> Cheers,
> >> >>> >>> Ivan
> >> >>> >>>
> >> >>> >>>
> >> >>> >>> On Fri, Jun 13, 2014 at 4:39 PM, George Gastaldi
> >> >>> >>> <ggastald(a)redhat.com>
> >> >>> >>> wrote:
> >> >>> >>>>
> >> >>> >>>> I am leaning towards the java-add-annotation
approach as it
> >> >>> >>>> seems
> >> >>> >>>> more
> >> >>> >>>> intuitive and could solve other use cases that
may arise.
> >> >>> >>>>
> >> >>> >>>> Em 13/06/2014, às 04:19, Antonio Goncalves
> >> >>> >>>> <antonio.mailing(a)gmail.com>
> >> >>> >>>> escreveu:
> >> >>> >>>>
> >> >>> >>>> When I create an EJB with Forge with the
following command :
> >> >>> >>>>
> >> >>> >>>> ejb-new-bean --named MyService
> >> >>> >>>>
> >> >>> >>>> I get the following :
> >> >>> >>>>
> >> >>> >>>> @Stateless
> >> >>> >>>> @LocalBean
> >> >>> >>>> public class MyService implements
Serializable
> >> >>> >>>>
> >> >>> >>>> In some cases, I would need to add an extra
@Named annotation.
> >> >>> >>>> Several
> >> >>> >>>> ways to do it. On the EJB command itself, we
could add a
> >> >>> >>>> parameter :
> >> >>> >>>>
> >> >>> >>>> ejb-new-bean --named MyService --addNamed
> >> >>> >>>>
> >> >>> >>>> But I think it would be good to have something
more generic
> >> >>> >>>> that
> >> >>> >>>> could
> >> >>> >>>> be used anywhere. We could use the same logic
as
> >> >>> >>>> constraint-add
> >> >>> >>>> (that
> >> >>> >>>> adds
> >> >>> >>>> any kind of constraint on any Entity) and have
something like
> >> >>> >>>>
> >> >>> >>>> cdi-add-qualifier --qualifier Named --target
> >> >>> >>>> org.app.service.MyService
> >> >>> >>>> // or on a property, which could be useful
> >> >>> >>>> cdi-add-qualifier --qualifier Named
--onProperty myProp
> >> >>> >>>> cdi-add-qualifier --qualifier Named --onMethod
myMethod
> >> >>> >>>>
> >> >>> >>>> Or something even more generic would be to use
the Java
> >> >>> >>>> command
> >> >>> >>>>
> >> >>> >>>> java-add-annotation --annotation
javax.inject.Named --target
> >> >>> >>>> org.app.service.MyService
> >> >>> >>>> java-add-annotation --annotation
javax.inject.Named --target
> >> >>> >>>> org.app.service.MyService --onProperty myProp
> >> >>> >>>> java-add-annotation --annotation
javax.inject.Named --target
> >> >>> >>>> org.app.service.MyService --onMethod myMethod
> >> >>> >>>> java-add-annotation --annotation
javax.inject.Named
> >> >>> >>>> --onProperty
> >> >>> >>>> myProp
> >> >>> >>>> java-add-annotation --annotation
javax.inject.Named --onMethod
> >> >>> >>>> myMethod
> >> >>> >>>>
> >> >>> >>>> Any thoughts ?
> >> >>> >>>>
> >> >>> >>>> Antonio
> >> >>> >>>>
> >> >>> >>>>
_______________________________________________
> >> >>> >>>> forge-dev mailing list
> >> >>> >>>> forge-dev(a)lists.jboss.org
> >> >>> >>>>
https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >>> >>>>
> >> >>> >>>>
> >> >>> >>>>
_______________________________________________
> >> >>> >>>> forge-dev mailing list
> >> >>> >>>> forge-dev(a)lists.jboss.org
> >> >>> >>>>
https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >>> >>>
> >> >>> >>>
> >> >>> >>> _______________________________________________
> >> >>> >>> forge-dev mailing list
> >> >>> >>> forge-dev(a)lists.jboss.org
> >> >>> >>>
https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >>> >>>
> >> >>> >>>
> >> >>> >>> _______________________________________________
> >> >>> >>> forge-dev mailing list
> >> >>> >>> forge-dev(a)lists.jboss.org
> >> >>> >>>
https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> --
> >> >>> >> Antonio Goncalves
> >> >>> >> Software architect and Java Champion
> >> >>> >>
> >> >>> >> Web site | Twitter | LinkedIn | Paris JUG | Devoxx
France
> >> >>> >>
> >> >>> >> _______________________________________________
> >> >>> >> forge-dev mailing list
> >> >>> >> forge-dev(a)lists.jboss.org
> >> >>> >>
https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > --
> >> >>> > Lincoln Baxter, III
> >> >>> >
http://ocpsoft.org
> >> >>> > "Simpler is better."
> >> >>> >
> >> >>> > _______________________________________________
> >> >>> > forge-dev mailing list
> >> >>> > forge-dev(a)lists.jboss.org
> >> >>> >
https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >>>
> >> >>> _______________________________________________
> >> >>> forge-dev mailing list
> >> >>> forge-dev(a)lists.jboss.org
> >> >>>
https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Lincoln Baxter, III
> >> >>
http://ocpsoft.org
> >> >> "Simpler is better."
> >> >>
> >> >> _______________________________________________
> >> >> forge-dev mailing list
> >> >> forge-dev(a)lists.jboss.org
> >> >>
https://lists.jboss.org/mailman/listinfo/forge-dev
> >>
> >> _______________________________________________
> >> forge-dev mailing list
> >> forge-dev(a)lists.jboss.org
> >>
https://lists.jboss.org/mailman/listinfo/forge-dev
> >
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect and Java Champion
> >
> > Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
> >
> > _______________________________________________
> > forge-dev mailing list
> > forge-dev(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/forge-dev
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Antonio Goncalves
Software architect and Java Champion
Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev