The Blog of Maxim Porges

Archive for September, 2007

  • Maven 2 Property References

    I finally figured out how Maven 2 property references work today. I’m sure this is covered in the documentation somewhere, but since I just sort of jumped in head first I’ve been discovering a lot about Maven through trial and error (and looking at other people’s build scripts).

    For the Flex build script I’ve been working on, I’m using the maven-antrun-plugin to run an Ant task that will run FlexUnit during the test phase of the build. I’m building the SWF in to the standard build area for Maven (the “target” directory) and wanted to reference this in the embedded Ant build. Here’s the POM file that I’m using so far for reference.

    <?xml version="1.0" encoding="UTF-8"?><project> <modelVersion>4.0.0</modelVersion> <groupId>net.israfil.examples</groupId> <artifactId>israfil-swf-example</artifactId> <version>1.0-SNAPSHOT</version> <packaging>swf</packaging> <properties>  <flex.home>/opt/flex_sdk_2</flex.home> </properties> <build>  <finalName>UserManager</finalName>  <plugins>   <plugin>    <groupId>net.israfil.mojo</groupId>    <artifactId>maven-flex2-plugin</artifactId>    <version>1.2-SNAPSHOT</version>    <extensions>true</extensions>    <configuration>     <flexHome>${flex.home}</flexHome>     <useNetwork>true</useNetwork>     <strict>true</strict>     <warning>true</warning>     <main>Test.mxml</main>    </configuration>   </plugin>   <plugin>    <artifactId>maven-antrun-plugin</artifactId>    <executions>     <execution>      <phase>test</phase>      <configuration>       <tasks>        <taskdef         resource="com/adobe/ac/ant/tasks/"         classpathref="maven.compile.classpath" />        <echo message="${}" />        <echo message="${}" />        <flexunit timeout="0"         swf="${}/UserManager.swf"         toDir="${}/reports" haltonfailure="true" />       </tasks>      </configuration>      <goals>       <goal>run</goal>      </goals>     </execution>    </executions>   </plugin>  </plugins> </build> <dependencies>  <!-- Add other SWC dependencies for JUnit-style test with output -->  <dependency>   <groupId>actionscript3.flexunit</groupId>   <artifactId>flexunit</artifactId>   <version>0.85</version>   <type>swc</type>  </dependency>  <dependency>   <groupId></groupId>   <artifactId>flexunitant</artifactId>   <version>1.0</version>  </dependency>  <!-- Required by the FlexUnit Ant Task -->  <dependency>   <groupId>org.dom4j</groupId>   <artifactId>dom4j</artifactId>   <version>1.6.1</version>  </dependency>  <dependency>   <groupId>org.jaxen</groupId>   <artifactId>jaxen</artifactId>   <version>1.1-beta-6</version>  </dependency> </dependencies></project>

    I couldn’t figure out how to reference the Maven property for the project build directory, and searching the web for “maven properties” just came up with the properties from the Maven 1 implementation which didn’t help.

    Then, it hit me: the properties are just dot-notation references for the path to the items in the POM. Taking a look at the Super POM, you can see that the tags wrapping the project build directory (target) are accessible through descendant dot notation.

    So, the following XML snippet from the Super POM:

    <project>  ...  <build>    <directory>target</directory>    <outputDirectory>target/classes</outputDirectory>    <finalName>${pom.artifactId}-${pom.version}</finalName>  ...  </build>  ...</project>

    … would enable you to reference the build directory as ${} (”target”), ${} (”target/classes”), and ${} (holding the output of the referenced values “${pom.artifactId}-${pom.version}”).

    I’m sure this is something stupid that anybody familiar with Maven would know, but since it took me a while to figure it out I thought I’d share with the world.

    2007.09.29 / 5 responses / Category: Uncategorized

  • Making the Most (or Too Much?) of Flex Components

    One of the first things that you learn to do as a Flex developer is create custom components by extending those that come with the core MXML library. Usually you’ll bundle a few items together, create a custom event or two, and maybe override some functionality.

    However, we’ve been experimenting with what else you can do with components without crossing the line in to bad practice. Frankly, we’re not sure where the line is yet, but hopefully somebody with some more professional Flex experience will stumble upon my blog and set us straight if we’re venturing beyond the realm of nice-smelling code.

    One of the things I’d really like to do is loosely pair the services that will support our business domains with a set of reusable components that can utilize them. The goal would be that as a developer, you could drop a component tag on a page and have both data and functionality appear immediately.

    This probably makes more sense for us than the average Flex development shop because we don’t build a lot of one-off Flex apps. Instead, we’re building custom software to support specific lines of business within CFI, many of whom consume similar information and perform common functionality in differing business process flows.

    Let me explain.

    We have a lot of software user interfaces that essentially do the same thing, but slighty differently for different business units. So, for example, our sales floor might search hotel availability when making a sale of a vacation, while our customer service department might search hotel availability to add extra nights to an existing vacation. The business rules for what sort of availability should be searched might be different for each business unit.

    Another thing our business really likes to do is the same thing, slightly differently, a lot. So, we might start a sales program that six sales agents test market, where we offer a limited set of hotel availability or adjust the pricing of the hotels somehow to match a test marketing program.

    So, we have a few options to make this work in Flex.

    1) Write a custom component set, and hook it up to one or more services that handle the variances in business rules. Do this using a framework, writing essentially the same glue code over and over again for each separate application.

    2) Write a custom component set, and design it so that each component can invoke its own data service directly (i.e. embed the calls to the remote service directly in the component). Make the bound services implement an interface of some kind so that the component can be wired up with different services.

    So, what we’d like to explore is #2. For each application, we’d skip the repetitive glue code, and instead would write a base component and extend/compose it in to a custom component for each front end application. The extension/composition would simply pair the component with the implementation of the service interface containing the custom business logic.

    As varying events happen in the component, they can be emitted for handling in the full UI implementation, which would use a standard Flex framework to process the results as necessary. So, for example, a hotel search might take place entirely inside the component with a direct call to the service backing the component, and then when the user double clicks the hotel they want to book, a hotelSelected event is announced that can be trapped by the UI and processed accordingly with the flow of the particular business process for that business unit.

    If we go this direction, we’ll essentially end up with a set of base components backed by directly called services, with both services and components closely related to a particular problem domain (such as seaching hotel availability, charging credit cards, etc.). For each specific UI implementation, the base service could be used (or a custom service implementation associated appropriately), and bound to the business process through handling of events dispatched by the service-backed components.

    We’ve already prototyped out some components along these lines, and so far we can’t see anything we’re scared of from a practice or maintainability standpoint. Of course, it’s early days, and we have plenty of time left to see this crash and burn in practice.

    If you have any thoughts on this approach, please share them. Are we setting ourselves up for total disaster, or is this something that might actually make a lick of sense?

    2007.09.28 / no responses / Category: Uncategorized

  • Maven Test Problem with Surefire

    I’ve started porting a few apps at work in to Maven to do the final test run. One of the first systems I am importing is our credit card processing system.

    Everything went fine until I tried to run the mvn package command to bundle up the web app. I got the following error:

    org.apache.maven.surefire.testset.TestSetFailedException: Unable to instantiate POJO \'class'

    Obviously, the surefire test plugin couldn’t instantiate the class, but I couldn’t understand why this would be a problem since the class was on the test classpath. I looked on Google and didn’t find anything interesting.

    Then, I remembered something about the surefire plugin running every class named “**/Test*.java”, “**/*”, or “**/*”. What was happening was that the plugin was trying to instantiate this class as a test case, when in fact it’s just a convenience class we use to provide test data. Unfortunately, this was one of our early Java projects, and we didn’t follow all the proper naming conventions for our test classes and their support classes.

    Not a problem, though – there is a way to configure inclusion and exclusion of tests in the surefire plugin. I’m going to leave this until next week, though, since it’s FRIDAY!

    2007.09.28 / no responses / Category: Uncategorized

  • Flex 3

    Man, Flex 3 is looking cool as balls. I’m definitely going to hold off buying my Flex Builder for Mac license until this thing goes gold.

    And when’s AIR coming out of beta? We want our Windows Taskbar/Mac Dock integration for our new Flex sales app, damn it. :)

    Either way, I’m psyched about the direction and growing maturity of the platform. It looked like it had potential two years ago when we bought it, and it’s nice to see Adobe coming through for us.

    2007.09.27 / 2 responses / Category: Uncategorized

  • cf.objective() 2008

    I’ve been invited to speak again at cf.objective() 2008 in the “Architecture & Design in Software/-Integration/EAI/SOA/–Java” track.

    Last year’s conference was awesome, so I can’t wait to get back there again and blather on about something or other. Topic submissions are going to be requested soon, so I’ll let you know what I decide to pitch when the time comes.

    2007.09.26 / 1 response / Category: Uncategorized

  • How To Change A Corporate IT Department (a.k.a. Beating Your Head Against A Wall, But Not In Vain)

    We have a large and incredibly significant Flex project taking place at CFI right now: we’re rewriting the front end of one of our core applications, which handles sales for the front end of our business in the call center environment. If you’d told me five years ago that this is what we’d be doing in Q3 of 2007, I would have called you crazy.

    I can safely say that this project is the culmination of the beginning of everything I have been trying to do with our IT department since I joined it as a lowly junior developer in application support. This application, upon successful delivery, will be the fledgling model around which the next several years of software development at CFI will be based.

    In total, getting us to this point took the following:

    1) Three years for me to fly in the face of all of our departmental practices, building our web development team to the point where the processes and technologies we were using showed some significant benefits over our traditional methods,

    2) another year to convince our Director and CIO that we needed to change direction for the rest of the department,

    3) two years of repeating myself to the business and negotiating ad nauseum to focus our efforts on re-engineering our core systems to bring them in line with their needs,

    4) the last nine months or so getting all of our software development teams moving toward the new direction (some faster than others), and

    5) the tireless work of countless people who have engaged in, supported, and led the transition.

    Total Underestimation
    Paul, who was our Director when we decided to make the switch, had always been wary of such a large transition in process and technology. He certainly wasn’t scared of it, but I think he had a much better sense of just how much work it was going to be and how long it would take (maybe that’s why he left right when it started? :) ). Having sat firmly in the driver’s seat for all of 2007, I must say that I had absolutely no idea what I was getting myself in to.

    Not that I regret it. I do regret the fact that I don’t get to mess around with all the cool technologies we’re now using as much as the developers do (lucky bastards).

    However, I’m somewhat obligated to make the change happen, since I ended up in a unique positon to do so. That’s not a statement born of conceit, but the state of affairs due to my 11 year tenure with the organization and my career path through it. The unique blend of positions and experiences I’ve had at CFI have given me a solid understanding of our business challenges, and my delivery record and the specific mix of relationships that I maintain from prior positions allow me to say and do things that are (usually) diametrically opposed to our prior IT model. People have always joked that I could get away with anything at CFI, and while I think that’s a gross exaggeration, I’ve certainly been able to facilitate some radical changes in direction that nobody else wanted (or were obtuse enough :) ) to champion.

    Changing Culture
    Prior to this experience, I had no expertise of any sort with changing an organizational culture. My first management role put me in the enviable position of being handed a small department (three people, myself included) and being given cart blanche to build it up from scratch. The fact that we had nothing mission-critical to support at the time made my job all the easier.

    Honestly, our first project failed miserably, after which we spent about six months to a year just figuring out what we wanted to do differently to prevent that from happening again. We changed our SDLC, implemented Fusebox and the FLiP process, bought some development tools, and had great success with our next project immediately – a trend which continued for quite some time. We certainly did a lot of things wrong and incrementally improved things over the years, but by the time I left the department we had a pretty good thing going (at least philosophically – I can’t defend most of the code we wrote :) ).

    After leaving the web team, I had the opportunity to run another development team (one of our Oracle teams), and that gave me a clear perspective on a few things.

    1) First, it was obvious that everything I had been told about the business units for our internal apps being harder to manage than the ones I dealt with for web projects was utter nonsense. For some reason, the other department managers seemed to think that the way we did things on the web team would never work with their teams, which was bunk. The same analysis techniques and communication strategies worked just as well with my newly inherited business units as they had with everybody else. As with anything work related, setting the attitude of the team appropriately defined its ability to succeed or fail at its goals.

    2) Most of the things I had suspected were challenging with our legacy internal application architecture (technology selection, coupling issues, scalability challenges, etc.) were legitimate concerns. This explained a lot about the pain some of our teams were feeling.

    By enabling the resources on my new team and making some changes to our interactions with the business, I was able to facilitate a lot of improvements, which I felt would prove the purpose behind some of the changes we were trying to make department-wide. However, I still found myself dealing with a lot of resistance in mindset and attitude to making the switch to newer technologies and more modern software development processes. The state of affairs and what needed to be done to improve them had become abundantly clear in my mind due to my successes and failures in varying development paradigms; but my audience, having only ever done things one particular way, often lacked this perspective.

    As a result, I found myself constantly repeating myself for two years straight. Literally, almost every day, I was having the same conversations with different people about our new direction, answering the same questions, countering the same arguments, so on and so forth, until finally the light would turn on and they would buy in to it. It’s been an utterly draining experience that I’ve felt like giving up on at least once every three months since I started doing it. Thankfully, I’m amazingly stubborn and a glutton for punishment, so I kept at it no matter how painful it became.

    Getting Support
    If I were to advise somebody on making a similar IT organizational culture change in the future, I would recommend a few things.

    Item #1: Fresh Perspective
    First, you have to hire people that are of a similar mindset to you. There is a great set of audio books by Jack Welch (called “Winning”), and he has some thoughts on organizational change that are 100% accurate – one of which is identifying who from the “old way” is going to make it, and who isn’t. There’s simply nothing you can do to change a person’s sense of nostalgia for the old ways, and if they can’t get on board and change to meet the new ways, they unfortunately become less useful to the organization. Often times, these people have to be let go – something we certainly didn’t want to be forced to do with anybody.

    Personally, I was completely unsuccessful at showing some of our old resources the benefits of the new practices. However, the great thing about hiring new people from outside the company is that they breathe fresh ideas and attitudes in to the organization. I stepped on a lot of feet during my progression at CFI (often due to a lack of professional maturity), and many times, I believe past grudges got in the way of people hearing (and believing) what I had to say. By putting a few new people in the organization and highlighting their results, I was able to win over some of the doubters.

    The first example I’ll use was a new project manager I hired shortly after taking over the Oracle team. Before this hire, the business analysts on this team really weren’t on board with where I was trying to take them. So, I brought somebody in who had experience with RUP and a contagiously positive attitude. I put him in the same box as the other guys, gave him a project that the team had failed to deliver on for two years, and let things happen. Within four months, the project (the first RUP project for the team) went to production. The combination of this success plus the interactions with the new hire had changed the perspectives of the other business analysts. We were also able to see improvements in the attitude of the business. They were so happy with the quick results, they asked for this new hire to lead all of their future projects.

    The second example I’ll use was a hire made on another team, in this case a development resource. Typically, when we hired a new development resource in to the old way of doing things, they would take four to six months to become useful since we had no persistent system documentation for them to refer to (we referred to this lull in productivity as “learning the system”). A lot of people fought me on the principle of creating persistent documentation, a key tenant of our new SDLC. When the new development resource was hired, he was productive on a high profile project in about three day’s time, having reviewed the system documentation we’d created as part of the project and immediately getting his bearings. This gave me yet another case to point to of the new ways working where the old ways had failed.

    A key to hiring effectively is standardizing your hiring practices. We implemented some rules in hiring that allowed us to have some more consistent metrics for bringing people in. It’s not perfect, but it’s better than the free-for-all we had beforehand.

    Item #2: Dedicated Change Management
    The second item that is critical to the success of an organizational change is a set of dedicated resources to facilitate and formalize all the changes. This was supposed to be me and my architecture team when I originally left the web team, but since I had to immediately run a troubled development team, and my architectural resources were 100% committed to a high profile project, we didn’t get much done. This year, I inherited several newly formed departments as a result of a position change, and had to direct development for our PCI compliance intiatives, so I was no more effective in promoting organizational change in my new role than I had been in my previous one.

    So, while we’ve made a lot of progress on our transition this year, it’s only been because of other people taking ownership and making things happen. I’ve directed and guided a lot of what we’ve come up with, but the real work was done by developers and project management resources getting their hands dirty. The largest benefit of this state of affairs is that the quality of the solutions has been very high, because they were born of real world challenges, and battle-tested by the internal developer and project manager communities. I always say that design by community is far better than design by committee.

    Item #3: Support from the Boss
    The third item that you absolutely have to have is support from your superior(s). My boss gave me cart blanche to make changes (this time with the entire department). While she plays devil’s advocate often enough, and we butt heads occasionally, it just makes me validate my ideas before executing on them. If I didn’t have her supporting me, I would have given up on this initiative a long time ago.

    Knowing When It’s Working
    The last twelve months have been pretty positive. We’ve hired a lot of really smart people who understand where we’re going, and have helped us get to the next level. We’ve also had a lot of people participate in a new technology/process project, and most of them have really enjoyed what they have gotten to do while adding significantly to their skill sets (some for the first time in years). There’s been a lot of challenges and tribulations, but an equal number of successes, and everybody has learned from their experiences.

    I’ve also noticed a distinct attitude shift across the department in the last two months. Pretty much all of the prior naysayers have accepted the change in direction, while others are actively promoting it in everything they do. For many, there’s the feeling that the transition can’t finish soon enough. There’s a hopeful and positive feeling to the new projects that are in progress, and a cohesion forming between our teams as they find themselves getting on the same page with their processes, technologies, and direction. This cohesion has never existed in our department in the six years I have worked there.

    Best practices are being shared regularly through natural collaboration, occuring as our expertise with each new technology and tool matures. Small groups of motivated and responsible parties have been forming automatically to solve common problems, after which they are presented to me for blessing and standardization.

    The most interesting thing to me is that this cultural attitude shift occurred over a very short period of time. We had years of staunch resistance and disinterest, and then suddenly, things have started to gel as though somebody snapped their fingers. I like to think of this as the “event horizon” of organizational change. I’m not sure if this is a common and/or legitimate perception of events of this nature, but that’s the way it has felt to me after almost five years of pushing for it to happen.

    In Closing
    I’ve been rambling on for way too long, so I’ll wrap this up. I want to make this point clear for anybody else who is trying to change the organizational mindset and culture of their corporate IT department.

    The bottom line is this: the entire period of culture shift required a near constant level of effort, during which I found that I had to maintain an unwavering vigil of positive reinforcement for our new direction and technologies. I often felt like giving up on the draining and repetitive process of convincing people to do something that they usually didn’t want to do; after all, it would have been far easier to just go and work somewhere where the organizational values I yearned for were already in place (although truth be told, I’m not sure if such a company exists on the East Coast).

    But now that the switch seems to have flipped, things have changed so drastically in terms of culture and attitude that I have to remind myself that it used to be the other way around. We’ve got really interesting work happening in exciting technologies, and the rewards gleaned from watching resources apply their new found skills to a successful project can’t be measured in words.

    Sure, we have a crapload of work left to do to get it all finished. I’m currently wrapping up the departmental development process changes our web team pioneered, while another pair of resources irons out the kinks in our SDLC and requirement/project management tools. I’m going to spend all of next year getting our QA processes straight, and pushing hard to promote the transition across the teams that are just now getting comfortable with making the jump.

    Any change in corporate IT culture is going to fail if you aren’t doing it for the benefit of the people that will live with it. My motivation for making things different stemmed entirely from the pain of failure after our first web team project crashed and burned, and the strong desire to make sure that situation never happened again. I can honestly say I’ve failed more than I’ve succeeded in my career, but having the opportunity to see things turn around at CFI and play a role in them doing so has been both tiring and thrilling in equal measure.

    2007.09.26 / no responses / Category: Uncategorized

  • Build Tools: Maven Flex Plugins

    UPDATE 2007.09.28: as Christian Gruber (the maven-flex2-plugin’s author) graciously pointed out, the net.israfil Flex 2 Maven plugin **is** available on the public Maven repo. You can get to it here: I’ve left my original post as is for posterity’s sake, but you can check the Google Group for the plugin to see why the integration build was failing (pending a reply from Christian after I posted my build file).

    So, we have a build tool shoot-out coming up next week, which means I need to get my crap together and get a CF/Flex build working in Maven.

    Naturally, the easiest thing to do would be to get a Maven 2 Flex Plugin and let that build my code for me. However, I had a few small issues getting it going, so I though I would share my experiences in case anybody else has the same problems.

    Turns out there are two Maven plugins for building Flex apps: the maven-flex2-plugin option from and another one I found today by accident on (the flex2-plugin). Besides this, the ServeBox guys seem to have all sorts of Flex goodness (including a Java/Flex framework, apparently – who knew?). Anyway, I had been planning on using the one from, so I started there.

    Installing the Plugin
    First off, I needed to install the plugin in my local Maven repository. Usually, installing Maven plugins is a snap, since they are hosted on global repositories that your local Maven installation knows how to talk to, and Maven installs them automatically just be you declaring them in your build. However, since is not a hugely popular plugin, it’s necessary to download it and install it from source.

    First step, check the code out from SVN. We can find the SVN repo on the Project Information page (the Maven site plugin generates this for your automatically if you tell it where your repo’s located in your POM).

    svn checkout \ \israfil-mojo-all-9

    If you look at what you checked out, you’ll see that you have a tiered Maven project. There is a top level project for the israfil-mojo family of projects, and beneath that is each of the sub-projects for compiling flex2 (maven-flex2-plugin), generating ASDocs (maven-asdoc-plugin), etc.

    Once you have the project code, you need to install it in to your local repository. Usually, you just invoke mvn install, but I had some issues with the build process.

    First, due to the way that the maven-invoker-plugin was declared in the build file, Maven could not locate the plugin in the global repository to download it. So, I found the plugin on the appropriate Project Information page again, and checked it out from SVN.

    svn checkout \ \maven-invoker-plugin

    Next, I ran mvn install from the root of the downloaded maven-invoker-plugin directory, and Maven performed its usual magic of downloading all the dependencies and installing the plugin for me.

    Once that was resolved, I went back to the Israfil Flex plugin. I ran mvn install from the root of the israfil-mojo-all-9 directory. Everything ran fine (compilation, tests, etc.) until Maven hit this point:

    ...[INFO] Installing /Users/.../israfil-mojo-all-9/maven-flex2-plugin/pom.xml to /Users/.../it-1.2-SNAPSHOT/maven-flex2-plugin-it-1.2-SNAPSHOT.pom[INFO] [invoker:run {execution: default}][INFO] Building: maven-flex2-actionscript1-test/pom.xml[INFO] ...FAILED[code=1]. See /Users/.../build.log for details....

    What was happening was, while running the invoker plugin, something was failing. It looked like some sort of ActionScript test was failing. I went in to the directory referenced in the error (/Users/porgesm/Desktop/israfil-mojo-all-9/maven-flex2-plugin/src/it/maven-flex2-actionscript1-test/) and found a pom.xml. Looking in the pom.xml, there was an integration test of some kind being run. Rather than trying to figure out why this was failing, I took the brute force approach and simply commented out the invoker plugin's invocation in the pom.xml under the maven-flex2-plugin directory (under the downloaded israfil-mojo-all-9 directory) as follows:

    <!--<plugin>  <artifactId>maven-invoker-plugin</artifactId>  <configuration>    <debug>true</debug>    <projectsDirectory>src/it</projectsDirectory>    <pomIncludes>      <pomInclude>*/pom.xml</pomInclude>    </pomIncludes>  </configuration>  <executions>    <execution>      <phase>integration-test</phase>      <goals><goal>run</goal></goals>    </execution>  </executions></plugin>-->

    Running mvn install again now produced the following output:

    [INFO] ----------------------------------------------[INFO] Reactor Summary:[INFO] ----------------------------------------------[INFO] Israfil Mojo: All ............................... SUCCESS [1.852s][INFO] Flex 2.0 maven plugin support classes ........... SUCCESS [2.834s][INFO] Flex 2.0 maven plugin ........................... SUCCESS [0.913s][INFO] ASDoc API documentation generator plugin ........ SUCCESS [0.604s][INFO] ----------------------------------------------[INFO] ----------------------------------------------[INFO] BUILD SUCCESSFUL[INFO] ----------------------------------------------[INFO] Total time: 6 seconds[INFO] Finished at: Tue Sep 25 22:13:27 EDT 2007[INFO] Final Memory: 11M/21M[INFO] ----------------------------------------------

    Nice - we're in business.

    Creating A Sample Flex Project
    Next, I configured a simple Maven project in Eclipse with a Main.mxml containing a button that said "Hello" when clicked. This .mxml file goes in to src/main/flex under the project, the default location the plugin expects code to be located.

    The pom.xml file for this project was really simple. I took the sample from the web site and modified it slightly for my needs:

    <?xml version="1.0" encoding="UTF-8"?><project>   <modelVersion>4.0.0</modelVersion>   <groupId>net.israfil.examples</groupId>   <artifactId>israfil-swf-example</artifactId>   <version>1.0-SNAPSHOT</version>   <packaging>swf</packaging>   <properties>      <flex.home>/opt/flex_sdk_2</flex.home>   </properties>   <build>      <!-- if you want this vs. artifactId.swf use finalName -->      <finalName>exampleApp</finalName>      <plugins>         <plugin>            <groupId>net.israfil.mojo</groupId>            <artifactId>maven-flex2-plugin</artifactId>            <version>1.2-SNAPSHOT</version>            <extensions>true</extensions>            <configuration>               <flexHome>${flex.home}</flexHome>               <useNetwork>true</useNetwork>               <strict>true</strict>               <!-- ... other options ... -->               <warning>true</warning>               <!-- if you use dataservices, make sure you overri... -->               <!--                <dataServicesConfig>                  src/main/resources/services-config.xml               </dataServicesConfig>               -->               <main>Main.mxml</main>            </configuration>         </plugin>      </plugins>   </build></project>

    Basically, I commented out the <dataServicesConfig/> element since I'm not using dataservices, and added a <properties/> element at the top of the file with the path to my Flex 2 SDK directory (containing the frameworks, player, bin directories etc. that come with the Flex 2 SDK).

    I ran mvn compile, but had another issue, this time with Flex compilation.

    ...[INFO] defaults: Error: unable to open './macFonts.ser'...

    Duh. Checking the Usage page in the plugin's project site, I see that I have to uncomment the <local-fonts-snapshot>localFonts.ser</local-fonts-snapshot> element in my flex-config.xml file. RTFM, fo' sho'.

    I ran mvn compile again, and this time (after a brief compilation pause) a file called exampleApp.swf appeared in my target directory. Sure enough, double clicking the SWF opened the Flash projector and produced a running Flex app.

    This was certainly a bit more of a pain than I had expected, but the issues with the build were not unresolvable. In a controlled development environment, you would build and deploy a lesser-known plugin like this to your corporate Maven repository to save your developers the hassle of doing so manually.

    The plugin seems to work nicely once configured, although I've only put it through simple paces so far. The other plugin I mentioned from ServeBox supposedly has FlexUnit integration, so I'll definitely need to check that out - otherwise, I'll need to invoke the FlexUnit Ant tasks from Maven in order to run the unit tests for the sample application we're building for next week's user group meeting. ServeBox also has their own public Maven repo from which Maven can retrieve the plugin, so the install process should be simpler once I add this repo location to my Maven settings file.

    Stay tuned and I'll post more info on my ongoing experiences with the plugin, as well as the one from ServeBox.

    2007.09.25 / 7 responses / Category: Uncategorized

  • MG:Flex or PureMVC?

    We’ve got a major Flex app cooking at CFI right now, the largest one we’ve done to date. We’re re-writing the front end (and some of the back end) for the sales application used by our call center agents. This app has high visibility, since it drives the sales and marketing department that produces over $200 million in annual timeshare revenue.

    When we started off with Flex 1.5 a few years ago, we naturally used Cairngorm because… well, there wasn’t really anything else. Since then PureMVC has popped up, as well as Model-Glue for Flex.

    Overall, we found Cairngorm a little heavyweight and too web-centric to fit naturally with Flex. I don’t mean to knock the framework, since it has its merits, but we’re taking the approach of treating our Flex apps as desktop apps distributed over the web, with all the stateful goodness that an app of that nature enjoys. Using a framework based on Front Controller doesn’t really jive with our philosophy.

    So, what do we want? I’d say two things: minimal configuration and framework boilerplate, and something that leverages the built-in event model and bindings that make Flex so cool.

    Overall, I think we’re equally satisfied with the job that PureMVC and MG:Flex do, but we’re nervous about MG:Flex’s alpha status. That being said, if the code Joe has cooked up so far works, and does what we need it to, then I don’t see why we wouldn’t use it.

    Anyway, we have a few POCs going for both frameworks as we try to solve a few challenges with our application. Outside of the call center sales flow, we have some enterprise-wide considerations to tackle, including role-based security and some other global application management concerns. As always, I’ll be blogging the outcome with fervour.

    2007.09.21 / 2 responses / Category: Uncategorized

  • Abandoning ColdFusion?

    Following several discussions at work recently, it looks like we might be abandoning ColdFusion.

    I’ve said it before and I’ll say it again: I think ColdFusion is a great front end complement to back end Java. However, at this point in time, I’m not convinced it’s the best complement.

    Most of the web sites we build at CFI are simple CRUD apps, or front ends to our enterprise applications with either a local database or nothing at all. For all of these scenarios, we get to design our web application databases as we see fit, and pretty much everything is based on Active Record. For something like this, ColdFusion looks seriously long in the tooth compared to frameworks like Rails or Grails.

    Besides that, CF is just plain verbose. I was critical in the early days of CFCs due to the tag-based syntax. This didn’t really bother us as much when we started writing our back ends in Java, but it has slowly worn away at our web developers to the point where they’re ready for something with a terser syntax. You just can’t justify the length of a CFC compared with a class from a scripting language.

    Wearing my business hat for a second, I’ve got the option of either upgrading our twelve CF 7 server licenses to CF 8 for around $45,000, or getting a competing platform for zip/ziltch/nada.

    So, we’ve been discussing switching to Groovy on Grails or Ruby on Rails. Since Grails is still figuring out its place in the world, and with Ruby being a pretty awesome language and JRuby being available, we’ve decided to start with JRuby. If the Rails on JRuby POC is successful, we’re not looking at it as a supplement to CF; it will be a wholesale replacement.

    On the one hand, I’ll be a little sad to see CF go. After all, I built my career on CF development, and was able to combine the language of my profession (CF) with the language of my passion (Java) until we could actually transition our technology environment over to a more Java-centric model. However, like all technologies, CF has to be constantly evaluated against its competition for its merits from a productivity and capability standpoint. Unfortunately, we’re guessing that the productivity aspect just won’t stand up to the alternatives, especially Rails.

    We’ve got some pretty critical items that the POC needs to address.

    1) Will Rails-based apps plug neatly in to our forward-looking enterprise service bus architecture?

    2) How does RJS compare to the new Ajax features in CF?

    3) Is WAR-based deployment with JRuby going to play well with our current server configuration, or require a substantial rework of our web server infrastructure?

    4) Are Ruby builds going to be as seamless with Maven as our CF builds would have been?

    5) Is there really more productivity in a Ruby-based environment over a CF-based one?

    6) Performance/scalability?

    There were a couple more items, but they are on my whiteboard at work. In any event, I’ll be blogging on the outcome, so stay posted for more.

    2007.09.21 / 9 responses / Category: Uncategorized

  • Code is the New Art

    I couldn’t have said it better myself, so I’ll link to somebody who already did and somebody else who thinks we’re both full of crap (in an amusing kind of way).

    2007.09.19 / no responses / Category: Uncategorized