This content has been marked as final. Show 6 replies
I've had nothing but problems with that stuff. I don't think Adobe has perfected our development tools/environment yet in some senses.
My only suggestions would be either:
1) Force these people to setup their environments the same. There's no reason that they need to be different. (Get your PM to light a fire under any dissenters rears.) Could be a bad choice if there's a lot of devs, but just two or three? Keep the environments the same.
2) Don't check in your "." files (.project) and such. Scary yes, and a pain, because if it changes it'll have to be done for each dev. Good luck battling with your repository on that one (if you use CVS).
3) [third potential option I am too dumb to be aware of here ^_^]
There are only a couple developers, but I'm trying my best to make this as little effort as possible.
It's too late for option 1. We've all already set up our machines with different roots for source control. Also, even if we had the same directory structures, non-relative paths break as soon as you start using branches.
I'll probably end up with something along the lines of 2. I've been considering writing a project template, and just give that to each developer with instructions on what to set each path to.
There's another problem though. 99% of the code is shared between a couple different projects. The only real difference between the projects is the top-level Application (currently we have 3 separate apps but they'll eventually be merged into a single one). For build purposes I'd need 3 projects now, but a single one later. So, multiple projects referencing the same codebase. Now, I can add the codebase to the build path no problem. However, FlexBuilder seems to be requiring that the Application file be in the project's src directory, not elsewhere in the build path. This almost requires me to check in the projects, which I'd really rather avoid (I'd rather have the various Application MXML files in the same codebase as the rest of the code).
You know, I think I might file a bug against FlexBuilder. I can think of no good reason to not allow relative paths. In fact, given that FB is written in Java, and that Java pretty much gives you relative paths for free, it almost seems like extra work had to be done to disallow them.
Glad you have that link in your sig. :)
Yea code sharing between projects has been problematic for me when I've tried it before. I ended up abandoning it and instead compiled an swc to use. But I wasn't changing the contents of the swc library so much...
Yeah, do it, I'll vote for it.. post a link here if you want. But you should do a search for that issue, if it's already there it'll just be marked duplicate. Also, it can be hard to get enough votes to get stuff noticed.
"aherrman" <email@example.com> wrote in message
> Is there a way to add entries to FlexBuilder's build path that are
> I'm going to have multiple projects that will use a shared codebase, but
> having trouble getting them to reference that shared code. I can do it
> absolute paths, but that isn't going to work well. This code (and the
> are going into sourcecontrol, and other people on my team probably don't
> the repositories in the same place on their harddrive as I do. So, while
> paths defined may work on my machine, it won't on the other developers'
> FlexBuilder's UI wouldn't let me input a relative path. I tried modifying
> .project and .actionScriptProperties files manually to add the relative
> but then the project fails to open.
There's a lot of this kind of discussion in the yahoo flexcoders group. You
might find it useful to check the archives there.
What I ended up doing was to create the project normally, but then rename the project files to add a "-template" to the end of them. I checked those in along with a readme.txt detailing the changes that needed to be made to the template files to make them usable as project files.
So, the first time a user gets latest on that project they'll have to create the FlexBuilder project from the template, but hopefully after that they won't need to touch it.
One thing I had to be careful of was project references. Originally my project referenced another FlexBuilder project. I found it was easier to reverence the SWC itself instead of the project.