Re: libraries and m2 artifact :
Brett Porter wrote: On 5/17/05, Dominique Devienne [EMAIL PROTECTED] wrote: I've used a more lenient model for my transitive dependency. The exact version used to build something is recorded, but which version of a given dependency to use is left up to the client. This is pretty much what is in Maven (and the artifact tasks) at the moment. It uses the nearest definition for conflict resolution. So declaring in the POM of the current project can ensure a particular version, otherwise you'll get one at depth 1, etc. A colleage proposed an interesting idea of using predicates to state compatibility between components the different version of a component. One thing we all have to remember is that versioning is something neither the CS or software engineering community have solved. Upgrades can cause problems. But on the plus side, given the absence of strict CS notions of compatibility, we can build things that only work sometimes and get away with it :) 1. there is no way to guarantee consistent behaviour across versions. Languages with more declarative pre- and post- conditions can do more internal validation; java could use asserts more if Java1.4 was the minimum. 2. it is not enough to have the right set of components, the system configuration must match what is required. 3. in a distributed system, it is the state of the entire network that defines the effective behaviour of a remote component. 4. what can you do then? Test, that is all. A key issue w/ transitive dependencies is that I may not want a library, just because it was used in a library I want. Certainly I need the right to override versions. This is why dependency declarations in JAR file manifests is so broken; the builder of the jar is telling the deployer what files they MUST use, not what files they SHOULD use. One thing I've felt might be good in dependency declarations (or in the POM) would be for something to declare what well-known-APIs they implement. So that if one version of JAX-RPC is declared, you don't need another. What we have is pretty basic, and we're definitely looking to improve it with some other types of resolution, such as what you've described. Ideally, a project would declare the minimum version it needs to work (and if applicable, maximum - or perhaps even known incompatible versions in between). The final project should use the most recent version allowed by all of the definitions (on the assumption that the most recent is backwards compatible and has less bugs than earlier versions :) That's one assumption, but I take the view is that If I explicitly ask for an older version, I should get that (albeit maybe with a warning). Maybe the version policy could be pluggable policy=none //no transitiveness newest-wins //newest matters nearest-wins //closest declaration matters fail //fail on conflict though I think I'm mixing policy of transitive on/off with conflict resolution here. hmm. Again, local definition of an explicit version will ensure you get what you ask for. This also has important consequences for making builds reproducible in the future, too - obviously if the version remains flexible at the point it is published then it might not be the same later on. There needs to be a point during QA where you can lock it down to a version. if you'd like to track the feature, http://jira.codehaus.org/browse/MNG-303 I've just subscribed to maven dev; I will discuss it there. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: libraries and m2 artifact :
On 5/16/05, Steve Loughran [EMAIL PROTECTED] wrote: I think what is happening is that the maven dependency model does work if you live only in maven-land (that is, provide your own poms, only set up classpaths via the dependency declarations). In this world, dependency logic should be a lot better than the classic whatever-is-in-the-filesys classpath setup we know and use. But trying to merge the two hurts. There is some mention in the docs of a scope switch, which seems to control some of this, but doesn't have a no-transitive-fetching option, which is what we need. Without that, it is unusable in ant itself, which does not bode well for other projects. Indeed, I cant seem to use it any of the three I've tried as eventually this transitiveness hits a brick wall somewhere in the dependency chain of the various XML tools. I've used a more lenient model for my transitive dependency. The exact version used to build something is recorded, but which version of a given dependency to use is left up to the client. By default, we assume backward compatibility and take the latest of the dependency, but it can be customized by dependency by the client itself. (we actually break up the version in two: a CVS branch tag, and a build number. We usually say use the latest build of a given branch). How does Maven resolve conflicting dependency? A depends on B and C, both depending on D, but B depends on D v1, when C depends on D v2? A colleage proposed an interesting idea of using predicates to state compatibility between components the different version of a component. The predicates are embedded in the 'POM' of a released component. So D v2 states being BC with D v1, and thus when getting the dependencies for A, you get D v2. I need to implement his idea eventually. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: libraries and m2 artifact :
On 5/16/05, Steve Loughran [EMAIL PROTECTED] wrote: Example: fetching commons-logging 1.04 Hi Steve, I'm going to work through the issues you filed here. We have planned for the next release some filtering. Ideally, it shouldn't be needed, but some projects will always build one bundle for you and let you guess which bits need which dependencies, so the user needs full control. There are definitely problems with some of the metadata - particularly in commons, and unfortunately I didn't get a whole lot of interest from commons developers at the time, so I'm fixing things myself. Aside from that, for commons-logging, I think you actually want commons-logging-api which has no dependencies, right? Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: libraries and m2 artifact :
Brett Porter wrote: On 5/16/05, Steve Loughran [EMAIL PROTECTED] wrote: Example: fetching commons-logging 1.04 Hi Steve, I'm going to work through the issues you filed here. Brett, I appreciate your help, but it's unfair to only rely on your kindness and on you being on this list :-) I have a couple more things to ask. Where should the discussion on the Maven Ant tasks take place IYO? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: libraries and m2 artifact :
I have a couple more things to ask. Where should the discussion on the Maven Ant tasks take place IYO? Probably users@maven.apache.org (dev@ is fine too if you are more comfortable there). Thanks. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: libraries and m2 artifact :
Stefan Bodewig wrote: On Thu, 05 May 2005, Steve Loughran [EMAIL PROTECTED] wrote: I am thinking of stopping all work on libraries, embracing the maven2 stuff instead. Sounds reasonable if you can make it do everything you intended to do with libraries. I am having mixed fun here. With a new copypath task I can extract the path and copy it into any directory (with flattening). But what is hurting me here is the tasks' belief that I need the dependencies that jars were built against. Example: fetching commons-logging 1.04 [artifact:dependencies] Downloading: commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.pom [artifact:dependencies] Transferring 7K [artifact:dependencies] Downloading: commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.pom.md5 [artifact:dependencies] Transferring 0K [artifact:dependencies] Downloading: avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3.pom [artifact:dependencies] Transferring 0K [artifact:dependencies] Downloading: avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3.pom.md5 [artifact:dependencies] Transferring 0K [artifact:dependencies] Downloading: junit/junit/3.7/junit-3.7.pom [artifact:dependencies] Transferring 0K [artifact:dependencies] Downloading: junit/junit/3.7/junit-3.7.pom.md5 [artifact:dependencies] Transferring 0K [artifact:dependencies] Downloading: log4j/log4j/1.2.6/log4j-1.2.6.pom [artifact:dependencies] Transferring 0K [artifact:dependencies] Downloading: log4j/log4j/1.2.6/log4j-1.2.6.pom.md5 [artifact:dependencies] Transferring 0K [artifact:dependencies] Downloading: logkit/logkit/1.0.1/logkit-1.0.1.pom [artifact:dependencies] Transferring 0K [artifact:dependencies] Downloading: logkit/logkit/1.0.1/logkit-1.0.1.pom.md5 [artifact:dependencies] Transferring 0K [artifact:dependencies] Downloading: logkit/logkit/1.0.1/logkit-1.0.1.jar [artifact:dependencies] Transferring 70K [artifact:dependencies] Downloading: logkit/logkit/1.0.1/logkit-1.0.1.jar.md5 [artifact:dependencies] Transferring 0K [artifact:dependencies] Downloading: log4j/log4j/1.2.6/log4j-1.2.6.jar [artifact:dependencies] Transferring 342K [artifact:dependencies] Downloading: log4j/log4j/1.2.6/log4j-1.2.6.jar.md5 [artifact:dependencies] Transferring 0K [artifact:dependencies] Downloading: junit/junit/3.7/junit-3.7.jar [artifact:dependencies] Transferring 114K [artifact:dependencies] Downloading: junit/junit/3.7/junit-3.7.jar.md5 [artifact:dependencies] Transferring 0K [artifact:dependencies] Downloading: avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3.jar [artifact:dependencies] Transferring 62K [artifact:dependencies] Downloading: avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3.jar.md5 [artifact:dependencies] Transferring 0K At the end of this, I end up with log41.2.6 and junit.3.7. Which, when I copy into ant_home/lib, (as they are on the path), means that older versions of all the libraries come in. This is not what I want, and will lead to much more pain. I think what is happening is that the maven dependency model does work if you live only in maven-land (that is, provide your own poms, only set up classpaths via the dependency declarations). In this world, dependency logic should be a lot better than the classic whatever-is-in-the-filesys classpath setup we know and use. But trying to merge the two hurts. There is some mention in the docs of a scope switch, which seems to control some of this, but doesn't have a no-transitive-fetching option, which is what we need. Without that, it is unusable in ant itself, which does not bode well for other projects. Indeed, I cant seem to use it any of the three I've tried as eventually this transitiveness hits a brick wall somewhere in the dependency chain of the various XML tools. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
