Sorry, terminology problem, I think. I was using the term 'project' loosely.

The application is not built monolithically. There are ~150 components built individually (well, about 40% of those are tests), exactly for the reason of keeping the cyclic/duplicate/tangled code problem at bay. Our build environment is GNU make based, but we have a way of auto generating Flash Builder projects (i.e. 150 of them). When pulled into a workspace for developers to work on, Eclipse falls over if it doesn't have at least 4 GB of RAM, and even then, has trouble.

I come from a C/C++ background, where million line codebases are not unheard of. Thus, I am big on modularization. Some of our developers are from the web realm, and say that we have too many modules and should build more monolithically.

I'm wondering what the best practices are out there for big Actionscript projects. Maybe we just can't have all the code available to all the engineers? Maybe they just don't get source access or debugging support for stepping in to lower level libraries when trying to figure out what's going on in their higher level code?

Thx for the comments.

Richard

On 07/03/2011 03:09 PM, Marvin Froeder wrote:
Sorry but the problem is the way the project is structured... I never
saw a java project with 3 k sources on a single project....

I worked on a project with a thousand classes on a single tree... the
build was deathly slow, when I convinced the bosses to split it found
all kind of weirdness, cyclic references and duplicated code that made
it so slow. Once I finished, building 50 pieces was faster then that old
monolithic one...

Em 03/07/2011 19:01, "Richard Lee" <[email protected]
<mailto:[email protected]>> escreveu:
 Thx for the response.

 It is logically grouped into 4 major areas, with each of those areas
 grouped into 5-20 sub areas. However, it all needs to come together to
 make the final AIR application. It is useful for the engineers to have
 access to all the source for debugging, code completion, hover asdocs,
 etc. Changes can happen at all levels, but most frequently at the upper
 levels of the code. When there are low level changes, an automated way
 of everyone picking them up would be great... perhaps if made into maven
 projects using SNAPSHOT versioning and a central repository, that would
 'just work'?

 I'm getting the feeling as we go along with this project that no one
 builds big, complex software with Actionscript, as the tools seem not up
 to the task. :-(

 Also, Maven seems really slow to compile even trivial swc/swf
 applications. Is this expected?

 Richard

 On 07/03/2011 02:43 PM, Marvin Froeder wrote:
> 2500 sources? That alone feels wrong. You should split that into
> multiple pieces. Find some logical way to group the source and go for it.
>
> Em 03/07/2011 17:59, "Richard Lee" <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> escreveu:
>> Hi there-
>>
>> I'm working on an Actionscript 3 project with approx 2500 source
>> files. How do people organize and build such projects using modern
>> IDEs without those IDEs falling over and dying due to poor memory
>> management? The code is loosely divided into 4 major parts, with many
>> subparts. It does have a highly layered and fairly clean architecture,
>> but most engineers need to have access to all of it, so segmenting it
>> into different deliverables is not helpful.
>>
>> We have a few other design goals with our build system which may or
>> may not be helpful. One is that the source repository is largely read-
>> only as far as the build is concerned. This means all build byproducs
>> must go 'elsewhere'. Most build systems I've seen, including maven,
>> seem to want to stick the build byproducts in the source repository,
>> usually as a child of the build files. Another goal is that the build
>> needs to support enforcement of architectural layering, but needs to
>> also be fast.
>>
>> Are there any good example opensource projects out there people could
>> point me at?
>>
>> Richard
>>
>> --
>> 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]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
>> To unsubscribe from this group, send email to
>> [email protected]
<mailto:flex-mojos%[email protected]>
> <mailto:flex-mojos%[email protected]
<mailto: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]
<mailto:[email protected]>
> To unsubscribe from this group, send email to
> [email protected]
<mailto: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]
<mailto:[email protected]>
 To unsubscribe from this group, send email to
 [email protected]
<mailto: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/

--
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/

Reply via email to