BTW -- moving the interfaces and enums to the base directory seems to
work just fine for me. Here's the code that did it:
@Override
protected File getOutputDir(JavaAs3Input input, GroovyTemplate
template) {
Boolean isEnumOrInterfaceTemplate = false;
isEnumOrInterfaceTemplate = (input.getJavaType().getKind() ==
JavaType.Kind.INTERFACE);
if (!isEnumOrInterfaceTemplate) {
isEnumOrInterfaceTemplate =
(input.getJavaType().getKind() ==
JavaType.Kind.ENUM);
}
if (isEnumOrInterfaceTemplate) {
return getConfig().getBaseOutputDir(input);
} else {
return (template.isBase() ?
getConfig().getBaseOutputDir(input) :
getConfig()
.getOutputDir(input));
}
}
On Oct 20, 11:39 pm, David Vree <[email protected]> wrote:
> Bryan,
>
> It strikes me as a little odd that the default behavior of generate is
> to put the automatically generated enum and interface classes in with
> the main source code and not in the "BaseOutputDirectory" where all
> the other automatically generated items are.
>
> I am trying to change this, but clearly there is no option to set, so
> I was going to put the logic into my own GroovyTransformer (as I have
> seen you do for other reasons). Specifically, I was going to change
> the "getOutputDir" method to check if it is an enum or interface
> template and, if so, use the baseOutputDirectory.
>
> Does this seem to make sense?
>
> Thanks,
> Dave
>
> On Oct 19, 2:33 pm, Bryan Turner <[email protected]> wrote:
>
> > David,
>
> > That is exactly how we have it setup, yes. Even though we actually are using
> > Granite as our data services provider, we wanted to abstract it out such
> > that we could easily replace it if necessary. To accomplish that, we wanted
> > to ensure that we had no dependencies on Granite in our code at large.
>
> > Note: I remembered after I wrote my previous e-mail, part of the logic in
> > our custom GroovyTransformer is also necessary just to get the custom
> > RemoteDestinationFactory to work. The getJavaTypeInterfaces(Class<?>) method
> > is necessary to compensate for places where GAS internally needs the
> > RemoteDestination type to be an instance of Granite's JavaInterface type
> > instead (I haven't dug through it enough to hit all the specifics on why
> > this is necessary--I just know your build will probably fail without it).
>
> > Let me know if you run into any problems,
> > Bryan Turner
>
> > On Tue, Oct 19, 2010 at 10:16 AM, David Vree <[email protected]> wrote:
> > > This is excellent stuff. If I understand correctly, you use your own
> > > "@Service" annotation in order to designate a Java class as being a
> > > service class -- that is, you do not use the "@RemoteDestination"
> > > annotation at all.
>
> > > Furthermore, your customizations to GAS3 have been done in a separate
> > > project, which you supply only as a dependency to Flexmojos and
> > > configure within the Flexmojos plugin. Thus, you do not have any
> > > Granite artifacts as a direct dependency to your Java services module.
>
> > > Did I get this right?
>
> > > And thanks for the other GSPs as well.
>
> > > @Velo -- Bryan has done all the heavy lifting here. Let me get this
> > > working on my own project and I can distill it down to a recipe.
> > > However, my recipe will be to have it all work with BlazeDS. In any
> > > event, if I understand things correctly, the recipe will have a
> > > dependency on another project which provides customizations to the
> > > GAS3 library. So there will be two projects (I think).
>
> > > On Oct 19, 11:55 am, Bryan Turner <[email protected]> wrote:
> > > > David,
>
> > > > Unfortunately, there is no way to avoid some Granite dependencies.
> > > However,
> > > > you can create a module specifically for some Granite-related code and
> > > > by
> > > > doing so you can avoid any Granite dependencies in your main codebase.
> > > For
> > > > the @RemoteDestination (GDS annotation), you need to subclass some
> > > Granite
> > > > classes to change it. In the project I'm working on, we have no Granite
> > > > dependencies in our main codebase. I have a secondary module that
> > > triggers
> > > > different behavior that uses my own annotations instead, and my Flex
> > > model
> > > > module references that dependency for my GAS configuration.
>
> > > > To save myself the grief of hitting Gmail's message size limits, I'm
> > > > attaching another Word document. Hopefully this helps. It's a bit more
> > > > effort, but it will prevent you from having dependencies on Granite in
> > > your
> > > > project at large.
>
> > > > Good luck,
> > > > Bryan Turner
>
> > > > On Tue, Oct 19, 2010 at 8:14 AM, Marvin Froeder <[email protected]>
> > > wrote:
> > > > > I meant should talk, not that :P
>
> > > > > On Tue, Oct 19, 2010 at 1:13 PM, Marvin Froeder <[email protected]>
> > > wrote:
>
> > > > >> Hey, you probably should that with granite ds folks.
>
> > > > >> VELO
>
> > > > >> On Tue, Oct 19, 2010 at 1:09 PM, David Vree <[email protected]
> > > >wrote:
>
> > > > >>> Bryan -- I've spend all morning carefully studying your document.
> > > > >>> Thanks again for such a helpful resource. I assume that the work
> > > > >>> you
> > > > >>> did was against GraniteDS instead of BlazeDS...is this correct? (I
> > > see
> > > > >>> the reference to the granite-config.xml).
>
> > > > >>> For the record, I found two very helpful postings to help us folk
> > > that
> > > > >>> use BlazeDS on the back end:
>
> > > > >>> 1)
>
> > >http://dev.c-ware.de/confluence/display/PUBLIC/Flexmojos+generated+AS...
>
> > > > >>> 2)
>
> > >http://zam0th.wordpress.com/2010/02/27/automating-externalization-bet...
>
> > > > >>> But neither of them address a question I have that perhaps you can
> > > > >>> help me with. In the process of code generation, my service
> > > > >>> classes
> > > > >>> are being treated like ordinary value objects. I have tried
> > > > >>> annotating them with the Spring "@RemotingDestination" annotation,
> > > but
> > > > >>> it didn't help. Then I read in the GAS3 documentation (http://
> > > > >>>www.graniteds.org/confluence/display/DOC/3.+Gas3+Code+Generator) that
> > > > >>> service classes are identified by the "@RemoteDestination"
> > > > >>> annotation. Notice the missing "ing" from "Remoting".
>
> > > > >>> Is this a GraniteDS annotation? I'd really like to not have to add
> > > > >>> the Granite JARs as a compile-type dependency of my project...and
> > > > >>> I'd
> > > > >>> also like to avoid having another annotation on my service classes.
> > > > >>> Is there another way to have the generate goal of flexmojos
> > > > >>> recognize
> > > > >>> my service classes and map them to the remote-object template, etc?
> > > > >>> Is this going to require me to specialize the
> > > > >>> "JavaAs3GroovyTransformer" class?
>
> > > > >>> Thanks for any help!!!
>
> > > > >>> On Oct 19, 9:07 am, David Vree <[email protected]> wrote:
> > > > >>> > Found it:
>
> > >http://groups.google.com/group/flex-mojos/browse_thread/thread/eb002b...
>
> > > > >>> > Thank you very much.
>
> > > > >>> > On Oct 19, 5:09 am, Bryan Turner <[email protected]> wrote:
>
> > > > >>> > > I attached a Word document to a previous thread with copious
> > > amounts
> > > > >>> of
> > > > >>> > > instruction on how to do all these things and more.
>
> > > > >>> > > On Tue, Oct 19, 2010 at 12:31 AM, David Vree <
> > > [email protected]>
> > > > >>> wrote:
> > > > >>> > > > I am starting out with this (very cool) capability in Flexmojo
> > > > >>> 3.7.1,
> > > > >>> > > > and am already generating value objects. But have two
> > > questions:
>
> > > > >>> > > > 1) I am getting all my "base" DTO's, but I am not seeing the
> > > AS3
> > > > >>> > > > classes that inherit from these. Do I have to do something
> > > special
> > > > >>> to
> > > > >>> > > > make these appear?
>
> > > > >>> > > > 2) But I would like to also generate service object interfaces
> > > and
> > > > >>> > > > implementations from my Java service objects. I check on the
> > > > >>> Granite
> > > > >>> > > > forum and they say this is possible since GAS3 v2.1. How do I
> > > > >>> trigger
> > > > >>> > > > this to happen as well?
>
> > > > >>> > > > Thanks,
> > > > >>> > > > Dave
>
> > > > >>> > > > --
> > > > >>> > > > You received this message because you are subscribed to the
> > > Google
> > > > >>> > > > Groups "Flex Mojos" group.
> > > > >>> > > > To post to this group, send email to
> > > [email protected]
> > > > >>> > > > To unsubscribe from this group, send email to
> > > > >>> > > > [email protected]<flex-mojos%[email protected]>
> > > <flex-mojos%[email protected]<flex-mojos%[email protected]>
>
> > > > >>> <flex-mojos%[email protected]<flex-mojos%[email protected]>
> > > <flex-mojos%[email protected]<flex-mojos%[email protected]>
>
> > > > >>> > > > For more options, visit this group at
> > > > >>> > > >http://groups.google.com/group/flex-mojos
>
> > > > >>> > > >http://flexmojos.sonatype.org/
>
> > > > >>> --
> > > > >>> You received this message because you are subscribed to the Google
> > > > >>> Groups "Flex Mojos" group.
> > > > >>> To post to this group, send email to [email protected]
> > > > >>> To unsubscribe from this group, send email to
> > > > >>> [email protected]<flex-mojos%[email protected]>
> > > <flex-mojos%[email protected]<flex-mojos%[email protected]>
>
> > > > >>> For more options, visit this group at
> > > > >>>http://groups.google.com/group/flex-mojos
>
> > > > >>>http://flexmojos.sonatype.org/
>
> > > > > --
> > > > > You received this message because you are subscribed to the Google
> > > > > Groups "Flex Mojos" group.
> > > > > To post to this group, send email to [email protected]
> > > > > To unsubscribe from this group, send email to
> > > > > [email protected]<flex-mojos%[email protected]>
> > > <flex-mojos%[email protected]<flex-mojos%[email protected]>
>
> > > > > For more options, visit this group at
> > > > >http://groups.google.com/group/flex-mojos
>
> > > > >http://flexmojos.sonatype.org/
>
> > > > Generating RemoteDestinations with GAS and FlexMojos.doc
> > > > 116KViewDownload
>
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Flex Mojos" group.
> > > To post to this group, send email to [email protected]
> > > To unsubscribe from this group, send email to
> > > [email protected]<flex-mojos%[email protected]>
> > > For more options, visit this group at
> > >http://groups.google.com/group/flex-mojos
>
> > >http://flexmojos.sonatype.org/
--
You received this message because you are subscribed to the Google
Groups "Flex Mojos" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/flex-mojos
http://flexmojos.sonatype.org/
