On Oct 1, 2010, at 12:38 PM, Phillip Hellewell wrote: > On Fri, Oct 1, 2010 at 1:14 PM, David Jencks <[email protected]> wrote: >> >> On Oct 1, 2010, at 11:25 AM, Phillip Hellewell wrote: >>> >>> We are planning to make things consistent so that this automation will >>> be possible, e.g.: >>> 1. Each "component" will live in a specific place in SVN (e.g., >>> /components/COMPNAME). >> >> How does this relate to your release process? i.e. where are the "trunk", >> "tags", and "branches"? Is each component going to be released separately, >> or all at once? > > Each component will have its own source tree with its own trunk, tags, > and branches. They can be released separately, but a component that > is released to customers will include all its dependencies bundled > with it. > >>> 2. Each "component" will have a single pom.xml. No multi-modules. >>> 3. Before deploying, the SVN tag name will be appended to the artifact >>> version number. >> >> I think that could be tricky, but I'm not an expert on this. > > My idea is to have a script that I run before running mvn that uses > svn info to get the tag name and then puts that into the version in > the pom.xml. Or even better, I should be able to put a property in > the version number, like "1.0-${svn_tag}" in the pom.xml, and just > pass in the tag name on the command-line with mvn -D.
I don't think that will work very well. I think using the release plugin will work better. > >>> 4. The SVN base url will be defined globally in the user's settings.xml >>> >>> So I'll know exactly what to check out for that component just from >>> its name and version, which I can get from dependency:resolve. >> >> if you release each component separately, each components pom needs to have >> an accurate <scm> tag. > > Each component's pom in the Maven repository will have the SVN tag > name as part of its version number. At the moment I don't think my > plan even requires using the scm plugin at all. I recommend using the release plugin for releases. In my experience it's pretty hard to get everything right for a release without it. I think you can script the release plugin so your script will feed in the svn rev as part of the tag name. > >> Unless you have gigabytes of source code I would think you are making extra >> work for everyone here. why not just ask all your developers to check out >> all of /components from svn and build the parts they want? Disk space is >> usually cheaper and more reliable than anyones time :-) > > It's not about disk space, it's about checking out the exact code that > goes with the version of the dependency that is needed. By appending > the svn tag name to the version in the pom.xml files, we'll always > know exactly what code that component was built from, and we'll be > able to automate checking out the source code for those components. checking out a tag and providing an environment where a developer might think its ok to modify it seems pretty dangerous to me. The release plugin can be configured to produce a zip or tar.gz of the entire project source which then gets in the maven repo. Relying on this for tagged source code might be safer. > >> If you want to automatically build dependency chains of modules you can put >> a parent pom in components that lists all the individual components as >> modules and use the really great maven options described here >> >> http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-advanced-reactor-options/ >> >> I haven't tried it but I think this might work even if each component does >> not use the aggregator pom as its parent. > > I can take a look at that, but I'm not really doing multi-modules > here. I'm doing dependencies. I want each component to have a single > pom.xml, and depend on other components through <dependencies>, not > through <modules>, and I'm not really sure how mixing up these > concepts could solve anything. if you have say 100 components with a dependency graph with maybe 1000 edges you may want to find out whether a change in one module produces obvious breakage in those that depend on it, without doing a full build. If the components are arranged as modules in an aggregator project, you can do this with mvn clean install -pl :X -amd where X is the module you changed. Maven will figure out all the components that could be affected, using the dependency graph, and build all of them in order. I find doing this by hand implausible. As I said, I haven't tried this where the components don't have the aggregator pom as parent, but suspect it will still work. As long as the components don't have the aggregator pom as a parent, you can still release them individually. You might also want to look at the versions-maven-plugin which is very handy for updating dependency versions. > > I do appreciate everyone's replies so far. Based on the answers I've > gotten, I am feeling pretty confident that Maven will work for the > workflow we want to use. > good :-) david jencks > Phillip > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
