John Casey wrote:
I've been talking to various people in the Maven community about this sort of thing for ages, probably more than two years at this point. Some of the most interesting conversations come when you talk to people interested in using Maven to build C projects, where certain libraries are required to be installed on the system already, even with a specific path in some cases.100% agree - dependency metadata should be freed, otherwise a simple dependency calculator requires a full blown model builder to work, that is not sane. And dependencies should be expressed as rules, otherwise all it's not useful.It seems like what we really need is to understand the difference between the dependency information contained in a project's POM and the rest. If you have a single project that can produce X different artifacts for different environmental configurations, they will all share the same source code and build process (when you consider that different profiles can be used to introduce dependencies and plugins into the build process as needed).However, each artifact produced from this project will serve different needs, and may require different dependencies of its own. In the case of assemblies that roll in their dependencies, for instance, dependency metadata should have all versions locked down to a single-version range and all included dependencies should be marked 'provided'. In the case of JDK 1.5 source that's been retrowoven (?) it'll have some additional dependencies.As others on this thread have even pointed out, the exact same artifact when consumed under a certain JDK/environment may need additional dependencies (like jaxb, etc.) that are provided in more recent JDK versions.To me, all of this points to a dire need to separate dependency metadata from the POM that all of these derivative artifacts shares. Each artifact should have its own dependency metadata, and this metadata needs to act more like a set of rules that will evaluate the environment detected or supplied to the current build, and return the set of transitive dependencies needed IN THAT CASE.
Even with the files and dumb https servers we can index resolution metadata on the client - I can try to POC that in Mercury. With Nexus - there are no limitations - all data could be indexed and available in microseconds. Add SAT resolver on top, which can vet thousands and thousands of candidates very effectively and I bet this is not a show stopper any more.The problem is, this could require cycling through many, many candidate artifacts' metadata in order to find a match. In the traditional way we store metadata - files - this means a lot of network I/O required to resolve dependencies, relative to what we have now. This has always been a show-stopper in my mind, at least up to now.
Index could reside on the client and provide a maven user's view of the world. Say - indexed dependency information for local repo releases. With tools to maintain it, of cause.We now have the tooling, and precedent, to provide more complex index files for groups of candidate artifacts that could be downloaded and queried. Additionally, we might even be able to delegate this candidate-auditioning process to a component in the artifact-handling code, such that we could provide alternative implementations that would work directly with a repository manager for queries, instead of going the index-file route (which would be the default, of course). I don't think such an index should be maintained for a whole repository, but for a groupId, which is a natural domain of control for a given project...which allows simpler aggregating of multiple repository fragments without merging files.
Thanks, Oleg
Just some thoughts. -john Jason van Zyl wrote:That's really not fundamentally different then just using a different artifact id. I think where I'm going is that classifiers are not suitable for the bits that make up the build path and classpath. Those are really for secondary artifacts like javadoc jars and source jars.On 31-Jul-08, at 8:48 AM, Stephen Connolly wrote:My solution is to allow pom's with classifiers! That way the -jdk14 jar has a -jdk14 pom to specify it's dependencies. If the pom is not there then you assume the pom for without theclassifier.... thus not requiring a DOM change... i.e. could be made workfor 2.0.11. And plus it will only affect new artifactsNow as to generating these pom's... I presume we could have a simple pluginthat outputs to target a copy of the pom with the dependencies for a specified profile and attaches that pom to the build... In fact such a plugin would be of use more generally... for exampleinternally we have one pom that lists all the developers... however if wepublish the artifact we don't want customers contacting the developersdirectly... so we'd prefer to deploy a transformed pom to the repo, not theone that we use for development. -Stephen On Thu, Jul 31, 2008 at 3:43 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:I just started dialog with the BC guys to look at Mercury so I will seewhat there thoughts are.If it is the case where it is common that for a given GAV the classified artifact requires different dependencies then I think we have some flaws in the system. It means we just ran out of runway because we can't actuallyexpress what an artifact needs correctly. It does not seem unlikely that a different JDK or a different platformmight require something different. If this is prevalent then our definitionof a classifier is in correct. It works for non-runtime artifacts likejavadocs and sources as those are obviously don't require any dependencychanges.Oleg and I were talking about this yesterday in fact where an artifact that may potentially be in the classpath should have it's own POM. We also have the case today where artifacts with classifiers are not reflected in the metadata explicitly. We can scan a repository with Nexus and find out what artifacts have sources and javadocs, but you can't tell normally withoutmaking a query and have it succeed or fail.That said, if people know of many cases where a classified artifact doesindeed require changes in the dependency set I don't think we can use classifiers. The asymmetry in the requirements for an artifact with aclassifier look problematic in this case. For an artifact that participates in a build or runtime, it needs a POM of its own if the system is going tobe deterministic. Maybe we extend the definition of a classifier to explicitly refer tothings like sources and javadocs which have no impact on the dependency requirements. GWT for the MAC is really a different artifact then GWT forLinux and maybe we should just start treating them as such. On 31-Jul-08, at 4:49 AM, Mark Hobson wrote: 2008/7/23 Brett Porter <[EMAIL PROTECTED]>:On 23/07/2008, at 1:34 AM, Jason van Zyl wrote:Ok,I have a package for the new 140 version as that's what I'm using butwhatthey have in central currently doesn't use classifiers which is probablynot so good. http://repo1.maven.org/maven2/org/bouncycastle/ So we can either: 1) Follow what they have their which is incorrect technically2) Deploy using classifiers as it probably should. Leave the old version130 there as it but also redeploy it using classifiers If we can decide I'll push version 140 into central.I think part of the problem is that there will be only one POM, but youneedto express dependencies, and all those have classifiers. This is probablywhy I put them in in the form I did some time back. I'd prefer classifiers myself if there's some way we can think to work around that?Was any consensus reached regarding uploading bouncycastle 140 to central? I was about to submit an upload request and then recalled this discussion. Whilst we're doing this, shall we fix the following?: - use org.bouncycastle group id rather than bouncycastle - add dependencies, e.g. bcmail should depend on bcprov - supply source and javadoc jars - [contentious] change version to 1.40 instead of 140, as detailed in the release notes And as discussed above: - [impossible?] use classifiers for jdk Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven jason at sonatype dot com ---------------------------------------------------------- happiness is like a butterfly: the more you chase it, the more it willelude you, but if you turn your attention to other things, it will comeand sit softly on your shoulder ... -- Thoreau --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven jason at sonatype dot com ---------------------------------------------------------- believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha --------------------------------------------------------------------- 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]
