Ow, ok, you scared me a lot =D Then, make a pom per project and use maven -pl -am and -amd options, that should help you.
VELO On Sun, Jul 3, 2011 at 7:36 PM, Richard Lee <[email protected]> wrote: > 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:flex-mojos@**googlegroups.com <[email protected]>> >> >>> > <mailto:flex-mojos@**googlegroups.com >>> > <[email protected]><mailto: >>> flex-mojos@**googlegroups.com <[email protected]>>> >>> >>> >> To unsubscribe from this group, send email to >>> >> flex-mojos+unsubscribe@**googlegroups.com<flex-mojos%[email protected]> >>> >> <mailto:flex-mojos%**[email protected]<flex-mojos%[email protected]> >> **> >> >>> > <mailto:flex-mojos%**[email protected]<flex-mojos%[email protected]> >>> >> <mailto:flex-mojos%**252Bunsubscribe@googlegroups.**com<flex-mojos%[email protected]> >> >> >> >> >> For more options, visit this group at >>> >> http://groups.google.com/**group/flex-mojos<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:flex-mojos@**googlegroups.com <[email protected]>> >> >>> > To unsubscribe from this group, send email to >>> > flex-mojos+unsubscribe@**googlegroups.com<flex-mojos%[email protected]> >>> >> <mailto:flex-mojos%**[email protected]<flex-mojos%[email protected]> >> **> >> >>> > For more options, visit this group at >>> > http://groups.google.com/**group/flex-mojos<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:flex-mojos@**googlegroups.com <[email protected]>> >> >>> To unsubscribe from this group, send email to >>> >>> flex-mojos+unsubscribe@**googlegroups.com<flex-mojos%[email protected]> >>> >> <mailto:flex-mojos%**[email protected]<flex-mojos%[email protected]> >> **> >> >>> For more options, visit this group at >>> >>> http://groups.google.com/**group/flex-mojos<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 >> flex-mojos+unsubscribe@**googlegroups.com<flex-mojos%[email protected]> >> For more options, visit this group at >> http://groups.google.com/**group/flex-mojos<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 > flex-mojos+unsubscribe@**googlegroups.com<flex-mojos%[email protected]> > For more options, visit this group at > http://groups.google.com/**group/flex-mojos<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/
