I'm sure open to solutions. I don't mind bending the model to fit Maven and think that has already been done to an extent. I don't really like changing functionality or code to fit the tool, especially when other standard tools worked fine, but this does not keep me up at night.
One of my favorite parts of the old build is this part I am harping on, the web app generator. It is a little nonstandard but was in a way valuable for that reason, since it automated that last mile of effort, going from code to deployable service. That's the only bit I am truly concerned about, but that's the part that is definitely not working under Maven now. This one is vital to me since it lowers the barrier so much to experimentation. A dev playing with CF only has an hour or two of attention span and if it doesn't just work, they move on, and it is a shame. So I guess I would invite someone to help fix this part of the build, possibly explaining what I need to do differently, or else let me hang on to an Ant script for 0.1 to get by for now. Again playing the pessimist - I feel like there is a burden of proof on Maven at this point. I believe it can add value. When are we going to get there - are the costs being seen? Because right now it is causing real problems, not least of which that it seems to block a release? Is it possible that a hybrid model is OK for now? The goal is not to use one particular tool but to produce usable code and artifacts. On Mar 13, 2009 6:44 PM, "Ted Dunning" <[email protected]> wrote: I have just switched a number of or our internal systems to maven and the benefits have exceeded my expectations. Builds are much, much simpler now and we have additional capabilities that were not anticipated. I think that the mahout use of maven is pretty complex compared to what I had my guys do. For us, we have each project build and deploy an artifact, but didn't do much with fancy modules or assemblies. Where we needed an assembly of other artifacts for a combined deployment artifact, we have a simple build that has dependencies that are resolved from our repository and then it builds the required assembly. Our experience in my previous job at Veoh was a bit more mixed, but in retrospect, every problem that we had was a result of trying to force a different build model on maven rather than trying to pour old code into a maven model (which is what we did here are Deepdyve). I don't want to minimize Sean's pain because this kind of pain is really awful. I do think, however, that the right course of action is not to say "Let's replicate what we had with ant", but rather to say "What is the most similar standard Maven model?". It may also be that this ambitious multi-module build style was too ambitious and that we should back off to having several independent builds with separately published artifacts. On Fri, Mar 13, 2009 at 11:03 AM, Sean Owen <[email protected]> wrote: > I am struggling to get the... -- Ted Dunning, CTO DeepDyve
