views:

41

answers:

2

I'm currently looking at structuring my teams projects into a consistent manner that properly utilises packages and is easily version-controlled (via SVN).

I'm interested in any 'best practise' with regards to project structuring and how to use consistent packaging without lumping everything into a gigantic com.domainname.projects folder structure whilst maintaining that package structure. I'm also keen to use the src/bin/lib folder structure within each project.

I guess I'm asking 'how do you do it?' and 'why?'. Sorry if this is a bit abstract for Stack Overflow but you guys give the best answers I've found.

A: 

You might need to provide more information for a "complete" answer, like your shop size, number of active projects, how you build them, and how you reuse code.

Here are some insights anyway... hope I understood the direction of you question :)

If your projects are coupled and you release new versions of each reusable artifact frequently, a single svn repo keeping a folder for each should do it. Tag/branches should remain at the project level.

Having separate repos for code that is linked may become a maintainability headache.

Sebastian
The team I work in is 8 developers - we make educational resources in Flash (not Flex) for use on interactive whiteboards in the classroom. Most projects are handled by a single dev but sometimes bigger projects will have several devs working on them. Most of the time, we probably have at most 4 projects each active at any one time.The development process of each member varies, which is something we're trying to standardise and modernise a bit. Without going into too much detail, I'm trying to help people move away from frame-scripting and into a more OOP approach....
dr_tchock
...This move includes some standardisation of assets, most notably a resource template that handles all common functionality (page navigation, whiteboard tools, etc.) - this will be built with various components and all the dependencies stored in our repo. At the start of a new project, the latest version is checked out and any changes (esp. bug-fixes) might need to be merged back in.
dr_tchock
Sebastian
A: 
Package1
    src\com\domainname\Package1
        source files
Package2
    src\com\domainname\Package2
        source files
Package3
    src\com\domainname\Package3
        source files
Lib
    All packages export swcs into this folder

Problem with re-usability is going backwards -- sometimes changing something in the corelib will break all sorts of stuff going backwards, so I suggest doing running builds against it to create one large swc with all the packages in it.

I don't know why you're keen to use the bin\lib folder -- it makes more sense to have them point at things explicity rather than having parent projects export into children ...

Daniel Hai
Yeah that's something like the approach I have at the moment, but I check out the latest version of the core library for each new project into my /lib/ folder and publish to a /bin/ folder. We don't use SWCs though, what is the advantage of the approach you describe?
dr_tchock
@dr_tchock: using SWCs generally results in faster compilation and also keeps developers from trying to hack what they consider good right into your core libraries, enforcing the open/close principle (http://en.wikipedia.org/wiki/Open/closed_principle). That's the advantage. The disadvantage is, this approach only really makes sense with libraries, that have high quality.
back2dos