> -----Original Message----- > From: Steve Loughran [mailto:[EMAIL PROTECTED] > Sent: lundi 24 octobre 2005 14:24 > To: Maven Developers List > Subject: Re: [M2][Proposal] J2EE builds best practices and conventions
[snip] > >>>I think at least at this point configuration management is out of scope > >>>for Maven. We could use archetypes or similar to generate appropriate > >>>config files, but in general I've found the differences go beyond > >>>templating and its best to have a general versioning and deployment > >>>mechanism for your server setup. > >> > >> > >>I have to agree. > >> > >>I actually work full time on complex system deployment, of which the > >>core runtime. SmartFrog, is LGPL-licensed and sourceforge hosted > >>(http://smartfrog.org/). If you want to know more, the latest slides are > >> > >>http://people.apache.org/~stevel/slides/oscon.pdf BTW, I have found this sentence in your OSCon PDF: "Systems are composed of applications that are composed of components". That's very cool as it matches almost exactly the directory structure I had in mind. I called components modules but we could them components :-) > > Cool. I'll be reading this and checking out the smartfrog project. More > > specifically I need to find out if the open source part of smartfrog is > > enough to satisfy the needs for deploying a J2EE system or if it > requires > > people to buy additional things. > > to be honest, right now, there is no direct support in our code for > jboss or geronimo. I tried to persuade the geronimo people last week > that they need to think about it. But there is > -JMX control > -war deploy to jetty+tomcat > -a jboss component from Brazil to do > > Ear support is on my todo list, Jboss being the obvious target. The goal > is to decouple configuring the app from the server, so you can switch > from app server provider just by changing an option in a deployment > descriptor and redeploying -or better yet, creating a new descriptor > that extends a base one for use on a different cluster. That todo list > is budy with core work related stuff, which is primarily dull Ws-* and > grid related things. Cool. I wonder if there could be synergies with Cargo... It seems there is potentially some overlap. Cargo could even possibly be used internally by Smartfrog to start/stop/deploy to containers as it already supports a big number of containers... The opposite could be true so that Cargo could have an EL for generating container configurations (ATM we have either a default config for which users can configure important parameters such as ports, log levels, security, etc) or a config provided by the user). > NB, there is no business model of paid-for-premium things. We are part > of a research lab. Once you have automated deployment to the extent that > you need 10 boxes + the option of 500 more for peak loads, then you have > the option of talking to the bit of HP that sells CPU time on demand. > But that is merely an option. :-) > Incidentally, on the subject of testing, Vmware are now giving away free > vmware runtimes. This lets you test more deployments on a single host, > so even the developers can have multi-server deployments on their > laptops. slick. Sounds great. I went to the vmware website and couldn't see any offer. Would you have more detail? > > > > That said, it seems to me that there are maybe different levels: > > > > - the poor man's solution which could be implemented using Maven. Again > this > > is what I've done at several places and I know several others who have > done > > the same successfully. I'm not saying this is the best, I'm just saying > that > > it can work in some circumstances. > > > Oh I agree, it works just like shell scripts and ant or custom RPMs. The > problem is that you cannot easily transfer all the configuraton work > into a production system, so the only thing that gets carried over from > dev to staging to live systems is experience in debugging configuration > problems. Sure. On some projects I had worked on we had retroactive loops where configuration and tuning from production teams get reinjected into our SCM so that next time we deliver a new version it's closer to the required production config. But honestly the production teams I have seen we really not at the level of doing something like what smartfrog does... Files were edited and modified by hand, no version control, no recording of what was done, etc... > Even small projects have repeated and different deployments. It just > doesnt hurt as much doing it by hand as it does on large scale 100+node > systems, where manual intervention is clearly impossible. I'd be curious to understand more about how to use smartfrom with a build system such as Ant or Maven. Where do you store smartfrog config files (in the SCM? In some external repos? In a Maven remote repo? :-)). Is there a sample application that I could check out from somewhere and run on my machine to check how it all works? Thanks -Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
