Responses inline... On 9/15/05, John Paul Ashenfelter <[EMAIL PROTECTED]> wrote: > On 9/15/05, Barney Boisvert <[EMAIL PROTECTED]> wrote: > > > That's a surprise -- though it of course depends on what you're doing. > > > I don't have many CF projects that don't have at least *some* java in > > > them (usually the credit card API) so using Ant seems pretty natural. > > > > Credit cards? Ick. That stuff sucks. ;) No unhappiness from me that > > I have touched CC processing in like 4 years. But anyway. We build > > the Java pieces separately. So Java piece X gets built into a JAR, > > and then that JAR is included in the CF apps as needed. Keeps the > > dependancies flowing downward, and isolates the CF apps from any > > changes to the Java apps until they're ready to deal with them. > > I'd actually like to hear a little more about how you do that -- if I > had to rewrite the JAR for credit card processing for you, it sounds > like I'd do that in a branch, approve it, and merge it back into the > trunk. Then everyone just pulls down the JAR into their working > directory? > > \yourapp\trunk\java > \yourapp\trunk\cfcode > > or similar in the repository? I'm actually curious :)
The java is part of the main project, but the app installations don't use the code in the project, then use JARs that are stored in a designated directory. Some are externally created, some are from the in-project java source, but all are treated as the same. In other words, the runtime application has no idea that java exists other than JAR files it has in it's posession. When a JAR is updated (whether from an internal or external source, makes no difference), then every working directory needs to be updated and CF restarted to pull in the new classes. So the internal java pieces are really separate projects that the CF app depends on, rather than part of the same app. And yes, for developing and testing the dependancies, we have ant scripts that'll compile, package, and install a JAR file into the app. But that's part of development, not building the app. At build time, it's the repository that dicates what JARs we have, not the source code. > > > I do a lot with using filter expansion to properly configure > > > differences between deployments (e.g. changing the fusebox <mode> > > > parameter from development to production as appropriate on the > > > specific server). > > > > We don't use FB4 either. And we maintain our different config stuff > > in-code, rather than in external ant properties files, so the app > > itself takes care of pulling the right config stuff out based on where > > it's at. Most of the reason is so that we can go right from staging > > to production with a minimum of steps. More steps == more room for > > error, especially if you're CHANGING THE CODE!!!. ;) If we did use > > FB4, we'd switch the mode the same way, in-code. <cfset > > application.fusebox.mode = "production" /> is just as effective as > > changing the XML file, as long as it happens while no request is > > actively executing the loader. > > I don't understand how that's fewer steps. If you're developing (in FB > for this example) and you have <cfset application.fusebox.mode = > "production" /> somewhere in your code, you have developers pull that > down and change it to "development" while they're working. Someone > inadvertently checks that back in with other changes and it rolls > out... Or you have to add a step to verify the setting is correct. > What am I missing? You missed the "we maintain our different config stuff in-code ... the app itself takes care of pulling the right config stuff out based on where it's at" part. Probably wasn't too clear, but like how with ant you can specify a specific properties file to read based on where you generate the code from (dev.properties, production.properties, etc.), we do the same thing, but it's all in-code. So the app intelligently switches the config parameters it needs based on where it's installed, rather than having to ensure that the install location matches the build location. In particular, this lets us sync from staging to production, rather than having to use some (potentially troubling) build process, and then upload code into production that has NEVER BEEN TESTED. Theoretically, the only thing that will be different from the staging code is whatever properties, but it's still different code. By making config selection changes (rather than rewriting) I have a lot more confidence that the code is identical. Stupid distinction, and I've never had ant do anything untoward as part of it's filtering process, but you remove the potential problem spots wherever you can. cheers, barneyb -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:218449 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
