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