Flex Web and AIR builds in the same module

I have a module containing a huge Flex web app (browser based) to which I am now adding mobile support.  A lot of the non-UI code needs to be shared, and the module is not currently a Library type, so IntelliJ doesn't allow sharing source outside the module.  It has about 25 build configurations which output the functionality into modular swfs.

For my first mobile app, which is basically a mobile compatible UI on top of the same app, I have created a new build configuration within the same module, specifying the AIR mobile type.  

This works, but only to a point.

The breakdown occurs when I have to always be mindful of the "Active Flash build configuration" in the lower right corner, and when I always have to look at the "other half" of my source code in an error state, according to IntelliJ.  Apparently, only a subset of the Flex SDK components are visible to a given "Active Flash build configuration" - so the components invisible show up as undefined symbols in the source code editor, thus turning red and misleading me about the state of the code.

I realize I could split my app into three parts, one module for non-UI, one module for Mobile UI, and one module for Flex Web UI.  However, is this the best use of my time, and the most elegant way to solve the problem?  I guess I just like keeping my source together...  My current package structure is so elaborate, I don't want to make it twice as hard to maintain nor do I need twice as many folders to go though to find a source file during development...  Time is money!  This is more than what FlexBuilder would have mandated, because I believe you could share another Project on the classpath, even if it was not a Library.  It was up to the developer not to use a component in the wrong device context.

It seems to me that a simple solution should be to do away with the active build configuration concept for Flex / AIR, at least in terms of the code (binary or source) that is shared.  Allow a given set of libraries to be shared with a module, instead of limiting the classpath to a build configuration, and share the entire SDK with each source file in the module.

It was very tedious setting up the 25 build configurations, only to put exactly the same set of libraries on ALL of them.  It was a very duplicative effort, and I eventually resorted to editing the XML file for the project in a text editor, and reopening IntelliJ with the new settings to save all the clicking...

I think it is reasonable to impose a rule that a new module is required if a different set of libraries is desired on the Flex "classpath".  This would be similar to Eclipse project, which shared the classpath.

Is there anything that can be done to improve IntelliJ 13, so I can keep my apps organized in the same module?

6 comments
Comment actions Permalink

The most elegant solution (and the best from architectural point of view) is to split the huge app in modules. Duplicating package structure doesn't introduce any drawbacks: Go To Class and Go To File actions work the same. And if your package structure is designed well then leaf-level packages won't be repeated in different modules.
We are not going to implement your request because it would provoke developers to use bad style project structure. Huge modules with dozens of build configurations is a spaghetti-style mess. Dozen of small isolated modules would be much better.

0
Comment actions Permalink

Actually, FlashBuilder did what I'm asking for very smoothly.  Building multiple swfs within a project was a piece of cake that did not require setting up 25 build configurations.  There was one build configuration per project, the classpath was shared among the entire project, no matter how many target swfs existed, and there was no limit to the number of Applications that could exist in a project...

Currently, IntelliJ does not allow sharing Flex/AIR modules on the build path with other modules unless they are a Library type, correct?  This is why I can't use multiple modules.
Currently, IntelliJ does not allow multiple swfs per module, correct?  This is the problem that is causing me the dozens of build configurations...

My build configurations reflect specific subsets of user functionality grouped logically, but under the covers, logic and components are accessed from all across the module.  Our application is an ERP system, comprised of a series of these tightly integrated sub components which currently live in my build configurations.  None of the functionality could be truly isolated unless the code in the other modules could be shared with all modules.

Truly, I don't need architecture enforcement from the IDE.  Hopefully you'll ask a few questions about my use case before deciding it's a bad spaghetti mess, or an undesirable request.  Knives can be used to finely julienne most any food ingredient, or to carry out an assult, but knives are provided nonetheless.  It's up to the owner to decide how to use them.  I'd prefer my tool vendors concern themselves with building powerful tools, even if they could be used improperly.  The architecture and decisions on how to use the tools should be left to the developer...

0
Comment actions Permalink
IntelliJ does not allow sharing Flex/AIR modules on the build path with other modules unless they are a Library type, correct?  This is why I can't use multiple modules.

Just to fix terminology:
- Flash module can be considered as is a set of source folders
- Flash build configuration (BC) is a set of options definig how source files should be compiled/packaged
- Flash module contains one or more Flash build configurations (BCc)
- there's no module-on-module dependency, only BC-on-BC.

So the answer is Yes, to share code BC must be of Library type. This doesn't prevent you from using multiple modules.

Currently, IntelliJ does not allow multiple swfs per module, correct?   This is the problem that is causing me the dozens of build configurations...


"Multiple swfs per module" is more or less equivalent to "multiple BCs per module". So your statement looks like an oxymoron. Note that for some temporary apps that are mostly used for testing, you can skip setting up a separate BC. Instead you can configure a Flash App run configuration based on some other BC and check 'Override main class'.

It was very tedious setting up the 25 build configurations, only to put exactly the same set of libraries on ALL of them

Hint: there's 'Copy' button at the top of the Project Structure dialog. It can clone BC wil all its dependencies. I hope that 'Override main class' feature of the run configuration will decrease the amount of BCs.

Sorry if my previous answer appeared to be not polite enough. I just thought that non-spaghetti code can be splitted in modules easily and vise versa. The fact that you need to care a lot about "Active Flash build configuration" is one more signal that source base should be split in separate modules.

0
Comment actions Permalink

I want the Flex/AIR to work more like Java.  Please consider the following enhancements to a Flex/AIR Module:

1. Move Dependencies tab to the Project-->Module level (just like Java Module)
2. use Module level Dependencies for source code level highlighting and code completion (just like Java Module), NOT the BC.
3. Take Flash build configuration off the IDE window.  Use BC only for swc/swf packaging during Make / Package.

The tooling needs to treat binary swf/swc build separately from source edit/compile.  Currently they are improperly joined in the tooling, because my source looks like an error when it is actually perfect during build, just because the wrong BC is chosen.  I believe this is to be an incorrect implementation.  I think Actionscript source should be treated just like Java source code...

BC should be limited to targeting a runtime environment i.e. the packaging format, and switches sent to the object linker / packager.  AIR Desktop, Flash Web, iOS and Android can be targeted from a very similar codebase that even shares certain UI components, but this is not reflected in the tooling just yet...

0
Comment actions Permalink

Huge modules with dozens of build configurations is a spaghetti-style mess. Dozen of small isolated modules would be much better.


Let me ask you a question.  How many BCs would there be, if I split my huge module into 25 Flex Modules?
Answer: The same number that I have now, 25 BCs, only with 24 more Modules to deal with, each with one BC...  Has anything been gained?  What is the value-add of a BC, if there should be a One-To-One relationship between Flex Module and Build Configuration (because multiple BC is discouraged)?  Might as well just put the BC properties on the Module itself...
I hope that 'Override main class' feature of the run configuration will decrease the amount of BCs.


I don't think this will help me produce multiple SWF files for deployment (HTML wrapped Flex Applications).
"Multiple swfs per module" is more or less equivalent to "multiple BCs per module". So your statement looks like an oxymoron.

No, multiple SWFs per module with ONE BC and one classpath would be the equivalent.  You were telling me that multiple BC and being concerned about BC and Active BC was bad, but I'm trying to communicate why the by-design limitations of a Flex Module mandate multiple BCs.
Instead you can configure a Flash App run configuration based on some other BC and check 'Override main class'.

Again, I don't think this will produce multiple SWF files for deployment (HTML wrapped Flex Applications).
Sorry if my previous answer appeared to be not polite enough.


Not at all, but a bit more curiosity, and confidence in your customers point of view might be okay.  No harm done, and thank you.  Let's continue to discuss until we understand each other.  I want to abandon both Eclipse and Flex Builder, and I think IntelliJ has the potential.

I just tried another approach to consolidate my Flex dependencies, by creating a Global Library and adding the swc files from my build directory (out).  This way, one new swc can be added in one location, to affect all my BCs which include the library.  However, the tool warns me:

Build configuration xxx (module xxx) dependency on the file xxx.swc detected which is the output of the build configuration xxx (module xxx).  A more typical case is when one build configuration depends on another rather than on its output.


Yes, but you won't let me add a build configuration to a Global Library!

I build a lot of component libraries for different purposes, and support several open source Flex components, so these are all separate modules that end up as dependencies.  I hate duplicative work, so I look for ways to focus my efforts and leverage tools to do more work in less time...

0
Comment actions Permalink

Flex/ActionScript project structure was pretty much similar to Java since IntelliJ IDEA 8 up to 11.0. There were dependencies at project level. But according to users feedback we have completely redesigned Flash project structure in IntelliJ IDEA 11.1. Feedback on current project setup is mostly positive, people find that the new concept based on BC is easier to understand and to maintain.

Flash has too many differences from Java. In Java there's no such thing as output type. Java compiler translates each *.java file to *.class file. Flash compiler translates ALL source files into a single SWC/SWF. In Java main class is the option of the Run Configuration. In Flash it is the compiler option.

Typical project structure is:
- one or more Flash modules each having one BC producing SWC lib.
- Flash module with one or more BCs producing apps. For example 3 BCs different only in target platform: Web, Desktop, Mobile. Each BC depends on required library BCs.

If you need to produce 25 SWFs then indeed you will have at 25 app BCs and several lib BCs for common code. All approaches are acceptable: either configure one module with 25 BCs or 25 modules each having 1 BC, or (probably the best one) configure 5-10 modules each having 1-5 BCs grouped according to the project architecture. Which way to choose depends on the difference of each app BC confguration. Similar BCs with the same code base can be kept in one module. You said that you need to care a lot about Active BC, that's why I thought that your BCs configuration is very much different and that's why I suggested you to split the module.

As I said it is a common workflow when you build both Flash Player and AIR-targeted swfs from the same sources. And this is a great feature that when you edit web-only related sources (and select corresponding active BC) then you see AIR-only stuff as a red code.  ActionScript source can't be treated like Java source code. Flach Builder doesn't have live error highlighting, no smart refactorings/inspections and intention actions. It only reports errors found by the compiler. That's why it doesn't have problems with 'extra' red code.

I see you have got used to Flash builder concepts. Indeed IntelliJ IDEA is different and probably not everybody finds it more convenient. Accoding to the feedback that we get a lot of people switch to IntelliJ and finally find it better. May be those who switch back to FB just do not tell us about that because I don't remember such kind of feedback.

but you won't let me add a build configuration to a Global Library!

You don't need to do that. Probably you understand Global Library concept incorrectly. Library of any level (module, project or global) is a set of SWC files, optionally sources for these SWCs and documentation htmls or URL. Project and global level are only for convenience: Project level libs can be reused in several modules/BCs; global lib can be reused in different projects. I.e. in case of project or global lib (together named 'shared' lib) you only save time for swc selection on the disk. For your in-project dependencies configure BC-on-BC dependency.
0

Please sign in to leave a comment.