I went ahead and opened ARIES-798 and committed some changes to blueprint that implement the profile idea.
By default the build is against released versions. If you want to build against snapshots run mvn clean install -Pdev For some reason it doesn't seem to be possible to put the stable versions in a profile (each project seems to work but a project that is a dependency doesn't seem to have defined version properties). Therefore in the dev profile any transitive dependencies will be the stable versions, not snapshots. We could make all the dependencies provided so you have to specify the versions in each project, but I don't think that would gain us much. This is in rev 1210363 so we can revert it pretty easily if there are problems I didn't see. Does anyone know how to set up jenkins to build twice, once plain and once with -Pdev? thanks david jencks On Dec 2, 2011, at 2:59 PM, David Jencks wrote: > > On Dec 2, 2011, at 2:26 PM, Daniel Kulp wrote: > >> On Friday, December 02, 2011 10:15:22 AM David Jencks wrote: >>> On Dec 2, 2011, at 2:39 AM, Jeremy Hughes wrote: >>>> On 2 December 2011 03:49, David Jencks <[email protected]> wrote: >>>>> released - contains version properties for dependencies at the oldest >>>>> released version we expect the project bundle to work against> >>>> would we have to do this using a set of maintained properties files? >>>> Where would this go - in the parent pom, the top level module pom or >>>> the bundle pom. There's a file her >>>> http://svn.apache.org/repos/asf/aries/trunk/aries_release_versions.txt >>>> which is supposed to reflect the latest versions - although I think a >>>> maven plugin could be written and teased into figuring out the latest. >>> >>> I think the versions need to be maintained in each (leaf) pom for artifacts >>> we release. Otherwise there's no good way to release single artifacts. >>> >>> There's the versions-maven-plugin >>> http://mojo.codehaus.org/versions-maven-plugin/ that helps with updating >>> versions but I don't know if it is smart enough to work with version >>> properties in a profile. If the plugin doesn't work, if we use a >>> consistent version naming scheme its easy enough to use an IDE's >>> search-and-replace to update properties. >> >> We could also try an import scoped dependency of some sort. >> >> Basically, have a pom someplace that defines an dependencyManagement thing >> that lists ALL the Aries jars and their current SNAPSHOT version and another >> one that lists ALL of the latest releases (which means it would need to be >> part of each release). A profile could selectively depend on the one that >> is needed. Pretty much would remove all the version numbers from >> everywhere. >> > I don't think something like that would work here. The idea is to make each > bundle independently releasable. Furthermore we don't really know what the > next snapshot version is going to be for a while, I think the current idea is > to on release update from e.g. 0.4.1-SNAPSHOT to 0.4.1-next-SNAPSHOT until we > know what digit should get incremented. And we may not be sure that all > users of a bundle want to use the same released version as "earliest > compatibility". So the "last release" might not be what we want and would > have to be released for every bundle release. While it's a pain I think > keeping the versions in each leaf pom is the way to go for aries. > > thanks > david jencks >> >> -- >> Daniel Kulp >> [email protected] - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >
