Yeah, typically something like this you have to balance out local ease of startup against the maintenance cost when you want to sync with the vendor. I could go ahead and check stuff in, if you like, and have everyone point to it. You can always do an svn merge (or wahtever your local equivalent is) to determine the differences and update your checked-in flex config.
My personal view is to fix the local copy, however, since we're relying on the flex command-line compiler and this is merely configuring that. On oru projects we regularly ask people to include a few key items in their settings.xml for maven, around proxies, extra repositories, etc. This leaves each client to be able to take a common project and use it in their own environment, even if their own config is different. As long as it's valid, everyone's good. As far as flexlib, the flexlibproperties dont' work in the mxmlc compiler, do they? I thought it was only compc that used that - or am I misunderstanding. Christian. On May 10, 2007, at 3:02 PM, Sterling, Brian wrote: > You guys are awesome! > > > > I feel little tears of joy coming to my eyes when I think about > this beautiful collaboration! > > > > But seriously, I am looking forward to using the output and helping > out any way I can. Once you two decide how to proceed, please let > the rest of us know how to get involved. > > > > In the mean time, I have a little question for Christian: > > > > I had the font problem you mentioned at > > > > http://www.israfil.net/projects/mojo/maven-flex2-plugin/usage.html > > > > and modified my flex-config.xml to make it work. Now I want other > teammates to be able to build as well, but don't like the idea of > asking them to modify their flex-config.xml files. I know there is > a way to specify a different location of flex-config.xml, so I > could just check in a modified one, but it seems that in that case > it will use only the specified file and not read the global one at > all anymore, so we wouldn't get any changes as this file is > modified with future Flex versions. > > > > I found something in this article that sounds related to this > problem (search for ".ser"): > > > > http://mxdj.sys-con.com/read/310378.htm > > > > Maybe we just have to pass the flexlib parameter to mxmlc? > > > > Any other suggestions? > > > > Thanks, > > Brian > > ________________________________ > > From: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of Christian Gruber > Sent: Thursday, May 10, 2007 10:11 AM > To: [email protected] > Subject: Re: Re : [flexcoders] Re: Building flex apps with Maven 2? > > > > Hey Jeff, > > This is really funny - we have developed quite similar plugins. > > On May 10, 2007, at 12:31 PM, Jean-François Mathiot wrote: > >> Ok. Actually, I were not able to find a way to specifiy the target >> path for the dependency inclusion with Maven 2 WAR Plugin >> (something like the mvn-1 war.target.path property). All I found >> was this defect : http://jira.codehaus.org/browse/MWAR-18 <http:// >> jira.codehaus.org/browse/MWAR-18> >> ... > > Ok. That's partly why I went with using the dependency plugin to > push .swfs into the temporary locations, then using the war's native > "web resources" facility to get them in. > >> Our plugin also use the SDK, that can be set with a FLEX_HOME >> environment variable or a flexSdkHome configuration property. >> Concerning compilation, we do not use the SWCs included inside the >> SDK, this we can manage the way they are compiled into the target >> artifact bytecode. The users have to install the swc files onto >> their repositories, that's annoying but MPL should quicly fix this >> problem. The swc-mojo handles all dependencies as external library >> paths, the swf-mojo only includes the dependencies with scope >> compile (provided, like "playerglobal" or test like "flexunit" are >> ignored). Resources bundles are also considered as dependencies. > > Right. That makes sense. The maven-flex2-plugin includes an option > to ignore the flex-sdk lib contents and use deployed artifacts, > precisely because of what you are saying. But we were having some > problems with my client deploying things into their internal maven > repo, so this avoided that problem practically, while allowing for a > more mature use as you have implemented. > > Anyway, we should collaborate to merge the two, I think, and make > sure we're including the best of all possible requirements, but you > seem to have done a great job so far. There might even be no added > value in mine, except insofar as I have already arranged for > replication to the repo1.maven.org, but that's organizational. We'll > figure it out. > > Cheers, > Christian > > christian gruber + [EMAIL PROTECTED] <mailto:cgruber% > 40israfil.net> + bus 905.640.1119 + mob > 416.998.6023 > process coach and architect + ISRÁFÍL CONSULTING SERVICES > > > christian gruber + [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023 process coach and architect + ISRÁFÍL CONSULTING SERVICES
