For those of you looking for alternatives, it appears that the main diffuculty I had with Israfil’s maven-flex2-plugin, that is how to specify the contextRoot compiler argument, is not really a difficulty after all. I don’t know if it works with BlazeDS, but the guys behind Igenko apparently made it work with GraniteDS. I have to thank Tim O’Brien for pointing that out.
Their solution to the configuration file duplication is at least as ugly as mine, but if you’re looking for the right configuration for israfil, you can try that:
<plugin>
<groupId>net.israfil.mojo</groupId>
<artifactId>maven-flex2-plugin</artifactId>
<version>1.3</version>
<extensions>true</extensions>
<configuration>
<flexHome>${flex.home}</flexHome>
<dataServicesConfig>../igenko-backoffice-server/src/main/webapp/WEB-INF/flex/services-config.xml</dataServicesConfig>
<main>Index.mxml</main>
<useNetwork>true</useNetwork>
<debug>true</debug>
<extraParameters>
<parameter>
<name>compiler.context-root</name>
<values><value>igenko-bo</value></values>
</parameter>
</extraParameters>
</configuration>
</plugin>
Maybe I’ll give it a shot after I finish my series. But anyways, Adobe if you can hear me, it becomes urgent for you to propose an official and well-documented Maven support for Flex 3.
2 responses to “Maven, Flex and GraniteDS: another full stack!”
hi sebastien, i liked your article it’s really well crafted.
do you have any work around for graniteDS with jetty..i am trying to use it with jetty but no luck!!
I’ve had a look at GraniteDS but from what I’ve seen, the biggest feature in it is lazy loading. And even though I do expose my entities directly in my presentation layer in my articles about BlazeDS for the sake of simplicity, I don’t think it’s a good practice. So I prefer sticking with BlazeDS for now. As for jetty, I really don’t know.