We use Subversion at work. I'd rather use Visual Source Safe because the
lack of checkout ticks me off.
Our folder structure is conf, for config files, typically XML for Java
stuff, like Hibernate, various servletSettings that are project specific,
etc.
The lib folder houses all of those shared libraries that the Java guys need,
like the jakarta, hibernate, and OpenAMF jars.
The src folder has all the project specific java, typically model,
controller, and value objects. I don't know where the homeskillet keeps his
Delegates, but I'm not allowed to install Eclipse to find out (wife's
learning Java, fragile confidence... don't ask).
Finally, we have the flash folder. The only thing the Java guys ask is my
model classpath match up with their's. Since You have to map the classes
server-side via OpenAMF using XML, it makes it cake, because the Java guys,
with just one small meeting with us (or rather my manager, I suckered him
into doing all the model stuff... he reads this list, therefore I'll balance
that with his experience working with the backend systems already, and his
readily available ability to faciliate communication with the backend guys.
*ahem*).
The Flash get's a little more complex, but I've actually set it up just in
case we ever port to Flex (prays). The classes themsevles are already
com.companyname.model/view/controller/valueobj. Transitioning to Flex would
merely require removing the class definitions from the as files, removing
the createChildren functions (for the View's), and linking the AS files to
the MXML. Not a bad conversion when your porting an entire app. So, class
package path stays the same.
The big difference would be my main controller would be replaced by Flex's
application class since Flex allows you to have a top level application.
The only thing I'd then actually remove from the current folder structure in
the Flash directory (classes/fla/includes/jsfl/layoutxml) would be the
includes; since it's merely there for a simple top level class instantiator;
Flex does this for you.
Yes, we have code we like to re-use, but because each project has enough
modifications, base on functionality and design, anything truly proflicly
OOP-i-fied is thrown in Utilities, a top level static class. Yeah, we'll
re-use GUI widgets on other projects, maybe even some data & service base
classes (wrappers for Remoting)... doing so wouldn't be hard, but we'd
ensure each project has it's own slot in source safe, even if they were the
exact same. With front-end work, you never know what class you may want to
tweak.
What I don't know about, however, is actual deployment. Currently, Flash is
in there, and we'll make a deploy folder later for actual client-side
deployment files which will be downloaded from a website and pretty much
fulltime on the client-machine. The Java, however, will have it's own
unique server deployment (however our back-end G feels the need to do so).
Flex would be different because we'd expect SVN to allow us to see our
deployed files. My guess is, Dan (our Java head) would set up an external
test server for the client team (since I work from home most the time, and
another developer is currently in Canada or Ecuador(sp?) and he's made the
biggest firewall known to man. Even with SCP access, as a GUI guy, I'd
rather just have FlexBuilder (or Eclipse) allow me to upload in-app to the
test server, test my code, and then checkin locally my working source to
SVN, which is actually on the in-house, behind the Firewall box via SSH (I
use Tortoise since Cygwin's confusing and rtfm in a console makes me want to
play Atari).
This setup with Flash & Java currently works great for 4 main developers and
2 designers, all of which are located in various locations at different
times throughout the world. The server guy tells us how to structure our
model, my manager maintains most of the front end Model part, I've passed
off most hardcore visual View work to my partner front-end develooper, and
we all share the bitch work of coding the Controller section. Currently,
the ONLY collisions we EVER have in a team environment is the bloody, binary
FLA. Naturally, Flex doesn't have this problem; we just replace it with a
"swf" and "images" folder, and we're good to go.
We share the directory, and we all divy up the responsibility of which parts
to code; so far, MVC is working out ok. We constantly keep in commuincation
over instant messenger, quick in-office meetings, phone, etc. Fortunately
(or unfortunately), Subversion kind of forces you to do that.
----- Original Message -----
From: "temporal_illusion" <[EMAIL PROTECTED]>
To: <flexcoders@yahoogroups.com>
Sent: Tuesday, April 05, 2005 6:15 PM
Subject: [flexcoders] Development Environment Setup Q's
I've been thinking recently on how to setup a good development
environment for multiple developers on the same Flex application.
Using CVS or Subversion would be the goal. Getting a production or
test version out of CVS could be done with Ant, that seems simple
enough.
Where I run into problems is the structure of the different files on
the server side and how to get those into the module/modules in CVS
properly. In all my previous projects with CVS it's been a single
language involved, so having all the Java files in one module (or a
few if there were shared libraries) was easy.
In this case there's the actual app directory with mxml and as files.
Then there's the directory with the remote java objects files (which
is shared between apps). And the directory with shared as files (also
shared between apps). And in my case there's also going to be the
internal web services in cfc files.
Making seperate modules for each of these doesn't feel right. And
configuring the server side so each developer has their own directory
so they can rip apart what they're working on safely doesn't seem
right either. But I don't think I can install a local copy of Flex
and ColdFusion on each machine to develop from (can I?).
Any wisdom from the experienced here?
Jason
Yahoo! Groups Links
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
