Lets got back to the basics of development... you need to develop something to that is delivered to be run....
So by my way of thinking I want an acurate description of whats delivered and run such that I can reproduce it. Have the convention that versions are in the jar names and the pom and its properties end up in the jar facilitates this. But I also need to have a flexible develoment environment with low overheads. If I use best guess or open ranges I have no power to control things because i need to tweak poms all over the place. So my approach is a design and build by contract when i use the major version to indicate a contract... and all my ranges restrict a dependency to a single major version. e.g. a.b.c-1.5 depends on a.b.d with [1,2) This is arbitrarily simple see a more complex example attached Now what this means is that when you break your project down into its component pieces you can by convention relate them to other things stably. Not reproducibly but thats ok because its determinable. If you try to build your deliverable and there is a range conflict you get an error on build... you can't build a dodgy deliverable. With open version ranges or best guess deps you can end up with any released dependency! and even if you have a process to know when you got it wrong but its very difficult other than adding dependencies to the deliverable project to get it right. Now your developers need to make a call when they release - usually after discussion - is my change breaking - you can test this with CI - and if so should I increment the major version. If you get broken because they make a mistake you have options... roll back deps... release a new rolled back version... The funny thing I avoided most of the gotches due to my approach... Now the gotchas... 1) don't use modules 2) don't use snapshot parents or relative paths 3) inherit by function which means have parents that configure particular plugins and keep them simple and try to have a little as possible in children poms. i have a 2 deep hierarhcy with one root and 9 sub parents The convention i use to break projects down is by function that means I have api, model aka domain, strategy, composition, configuration, webapp, abstract webapp, webservice, repository. It means a proliferation of artifacts but at the same time a proliferation of reuse... 4) use a 2 point version major.release and always start at X.1 never at X.0 otherwise ranges don't work... its not a bug just an ideosyncracy... consider [1,2) this does not match 1.0-SNAPSHOT and matches 2.0-SNAPSHOT which seems odd... if you never make 1.0-SNAPSHOT or 2.0-SNAPSHOT then range boundaries work determinably. range calculations break down if have more that 3 points so you need to leave wiggle room. 5) save the third point for patches which are releases off branches 6) don't use dependency management it encourages bad inheritance, you can just use transitive dependencies and they are more flexible 7) wrap 3rd party dependencies with local projects that just enforce consistent resolution - they don't use ranges so you need to manage it theres a taste i probably missed something as this is just off the top of my head, gotta do some work now On Thu, 09 Oct 2008 12:47:13 Ian Robertson wrote: > On Sun, 2008-10-05 at 04:48 -0600, Michael McCallum wrote: > > On Sat, 04 Oct 2008 14:16:57 Keith Branton wrote: > > > 1. Can anyone please tell me of a way to achieve this with 2.0.9 today? > > > > With the appropriate use of ranges you can do this and it resolves as > > described. There are about 11 gotchas to doing it though, all worked > > around by appropriate conventions. > > Can you elaborate on what these 11 gotchas are, or point to a place > which does? > > One of the biggest issues I see with ranges is that maven chooses the > most recent version in the repository which matches a given range. > Consequently, if a pom specifies a version range for a dependency like > [1.5,), the exact same code can create different builds on different > days if a new release of the dependency is made. > > I'm actually curious if anyone knows the reason for this; it seams that > a far better choice would be to choose the *lowest* version which > matches all range requirements, so that builds could be temporally > stable. > > - Ian > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED]
[INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'dependency'. WAGON_VERSION: 1.0-beta-2 [INFO] ------------------------------------------------------------------------ [INFO] Building Jis Products [INFO] task-segment: [dependency:tree] [INFO] ------------------------------------------------------------------------ [INFO] [dependency:tree] [INFO] net.artifactoring:net.artifactoring.jis.product.jcd:jar:2.54-SNAPSHOT [INFO] +- net.artifactoring.composite:net.artifactoring.composite.unittest:jar:4.5:test [INFO] | +- org.easymock:easymock:jar:2.4:test [INFO] | +- org.testng:testng:jar:jdk15:5.7:test [INFO] | | \- junit:junit:jar:3.8.1:test [INFO] | \- net.artifactoring.composite:net.artifactoring.composite.logging.logback:jar:1.1:test [INFO] | +- org.slf4j:log4j-over-slf4j:jar:1.5.3:test [INFO] | \- ch.qos.logback:logback-classic:jar:0.9.9:test [INFO] | \- ch.qos.logback:logback-core:jar:0.9.9:test [INFO] +- net.artifactoring.framework:net.artifactoring.jis.product.framework:jar:2.3.1:compile [INFO] | +- net.artifactoring.framework:net.artifactoring.jis.framework:jar:2.2:compile [INFO] | | +- net.artifactoring.composite:net.artifactoring.composite.seebeyond:jar:1.0:compile [INFO] | | | +- javax.jms:jms:jar:1.1:compile [INFO] | | | +- com.stc.seebeyond:stc-codegen-logger-api:jar:5.05:compile [INFO] | | | +- com.stc.seebeyond:stc-codegen-alerterapi:jar:5.05:compile [INFO] | | | +- com.stc.seebeyond:stc-email-adapter-app-conn:jar:5.05:compile [INFO] | | | +- com.stc.seebeyond:stc-app-conn-api:jar:5.05:compile [INFO] | | | +- com.stc.seebeyond:stc-eway-persistence:jar:5.05:compile [INFO] | | | +- com.stc.seebeyond:stc-jms-otd-api:jar:5.05:compile [INFO] | | | +- com.stc.seebeyond:stc-xsd-otd-impl:jar:5.05:compile [INFO] | | | +- com.stc.seebeyond:stc-otd-frameworkapi:jar:5.05:compile [INFO] | | | +- com.sybase:sybase-15adapter:jar:5.05:compile [INFO] | | | +- com.stc.seebeyond:stc-codegen-utilapi:jar:5.05:compile [INFO] | | | +- com.stc.seebeyond:stc-batchadapterwebservice:jar:5.05:compile [INFO] | | | +- com.stc.seebeyond:stc-batchext:jar:5.05:compile [INFO] | | | +- com.stc.seebeyond:stcschedulerotdappconn:jar:5.05:compile [INFO] | | | \- com.stc.seebeyond:com.stc.einsightintegrationapi:jar:5.05:compile [INFO] | | +- net.artifactoring.composite:net.artifactoring.composite.spring:jar:5.1:compile [INFO] | | | +- net.artifactoring.composite:net.artifactoring.composite.logging:jar:4.1:compile [INFO] | | | | +- org.slf4j:slf4j-api:jar:1.5.3:compile [INFO] | | | | \- org.slf4j:jcl-over-slf4j:jar:1.5.3:compile [INFO] | | | +- xerces:xercesImpl:jar:2.8.1:compile [INFO] | | | +- xml-apis:xml-apis:jar:1.3.04:compile [INFO] | | | +- cglib:cglib:jar:2.1_3:compile [INFO] | | | | \- asm:asm:jar:1.5.3:compile [INFO] | | | +- aspectj:aspectjweaver:jar:1.5.3:compile [INFO] | | | +- org.springframework:spring-aop:jar:2.0.7:compile [INFO] | | | | +- aopalliance:aopalliance:jar:1.0:compile [INFO] | | | | +- org.springframework:spring-beans:jar:2.0.7:compile [INFO] | | | | \- org.springframework:spring-core:jar:2.0.7:compile [INFO] | | | \- org.springframework:spring-context:jar:2.0.7:compile [INFO] | | \- net.artifactoring.audit:net.artifactoring.jis.audit:jar:4.3:compile [INFO] | | +- net.artifactoring.audit:net.artifactoring.audit.factory:jar:2.2:compile [INFO] | | | +- net.artifactoring.composite:net.artifactoring.composite.apache.commons:jar:4.0:compile [INFO] | | | | +- commons-collections:commons-collections:jar:3.2:compile [INFO] | | | | +- commons-lang:commons-lang:jar:2.3:compile [INFO] | | | | \- commons-beanutils:commons-beanutils:jar:1.7.0:compile [INFO] | | | +- net.artifactoring:net.artifactoring.audit.api:jar:3.0:compile [INFO] | | | +- net.artifactoring:net.artifactoring.configuration.api:jar:1.1:compile [INFO] | | | \- net.artifactoring.audit:net.artifactoring.audit.marker:jar:2.2:compile [INFO] | | +- net.artifactoring:net.artifactoring.configuration:jar:3.1:compile [INFO] | | | \- au.com.bytecode:au.com.bytecode.opencsv:jar:2.2:compile [INFO] | | \- net.artifactoring.composite:net.artifactoring.composite.core:jar:1.2:compile [INFO] | | +- net.artifactoring:net.artifactoring.exception:jar:1.5:compile [INFO] | | +- net.artifactoring:net.artifactoring.codec:jar:1.2:compile [INFO] | | \- joda-time:joda-time:jar:1.4:compile [INFO] | +- net.artifactoring.jis.otds:cmf-products-otd:jar:200701181645220984:compile [INFO] | \- net.artifactoring.jis.otds:cmf-filejob-otd:jar:200610091736560443:compile [INFO] +- net.artifactoring:net.artifactoring.deploy.jis.dispatcher:jar:2.1:test [INFO] +- org.htmlparser:htmlparser:jar:1.6:compile [INFO] | \- com.sun:tools:jar:1.5.0:system [INFO] \- org.htmlparser:htmllexer:jar:1.6:compile [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 6 seconds [INFO] Finished at: Thu Oct 09 21:56:09 NZDT 2008 [INFO] Final Memory: 24M/196M [INFO] ------------------------------------------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
