Thanks; I will take a look at the release and versions plugin to see if they can help.
Phillip On Fri, Oct 1, 2010 at 4:57 PM, David Jencks <[email protected]> wrote: > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
