> > Proposed Solutions > ------------------ > > Having worked it through, I see this comes down to inheritance, and > really is just the same issue we've looked at before of how to easily > version a parent. > > I want to strictly version the inheritance of my dependencies. I always > want the latest of the project information (but I want it locked in to > that version when deployed). For build information, I also want the > latest, locked in to that version when deployed. > > Here's how I think we can address each of the problems: > > 1) I don't want to change a version when the metadata changes > > A: add <metadataRevision> to <parent> and <dependency> > > This solves a bunch of issues including some of the stuff about > reproducibility when metadata is changed in the repository because it is > "bad". So like everything else, when omitted you get the latest. The > frequency of checks for updates is driven a combination of the > configuration of the repository, and the status of the metadata you have > (if it is verified in some way then it does not need to look for > updates, though the release process might prompt to check). When > deployed, the version gets locked in. Instead of doing svn commits of > changes to poms, a new version of the metadata can be deployed (this > would entail doing a pom-only deploy and would usually be managed by the > repository manager). I would suggest a filename of > artifactId-version.r1.pom, artifactId-version.r2.pom, etc. where no .rX > is r0, the original.
Isn't this kinda similar to the functionality behind -SNAPSHOT only adding in the ability to strictly reference a particular snapshot as a dependency? well, and not deploying the actual artifact again..kind of forking snapshotting to be a snapshot of the while artifact and then generating snapshots of the pom within a particular official version. I certainly see the need for a good automagic mechanism of fixing bad poms that doesn't involve smoking things from your local repository, but the way I am thinking about it I get a bit hung up on the usage, doesn't it seem a bit too much for someone to add in a dependency locked to a specific version of a pom file...when all versions of that pom file actually only represent one artifact? What is the goal of having something reproducible and being able to pin it to a specific version of a pom file for a given artifact? for debugging purposes? I suppose I don't see the need yet for that...is it getting into murky territory for me to be able to reference the one version of a pom for a particular version of an artifact so that I have a certain pluging configuration entry for that particular point in time? This of course is just the <metadataRevision> bit, no harm I guess in providing it anyway, in terms of filenames, I would almost go with a timestamp a la snapshots instead of the arbitrary r1,r2,r3 thing...just my preference, maybe I just like lots of numbers, but it is exact for when the new version of that pom went there, will always be higher and doesn't require a polling of the existing repository to locate the next version number to deploy 2) inheritance parent versioning - having to select a version > > A: automatic versionining of the parent, and always use latest from > children > > I think there are 2 types of inheritance: > - generic POM inheritance (plugin parent, mojo parent, company wide > parent, etc) > - multi module build where version is shared > > I don't think (1) above applies to the multi module build, as once its > released, its released, and you always want everything from it (see (3) > below). Children should reference the parent version and rely on tools > to do any updating. > > In generic POM inheritence, I think that it needs to be versioned, but > you don't need to specify it - just get the latest always. In that case, > it would be best to automatically number the parent - ie no version is > given in the POM, and the technique from (1) is used. Children do not > specify a parent version. > > The parent POM may not even exist anywhere in source control - instead > being in a database or visually edited and winding up in the repository. I love this idea, children shouldn't have to peg themselves to a particular parent version...it should just be the latest parent version *cheer* 3) Separating inheritance of versioned and transient info > > A: Deprecate dependency inheritance (bare with me :) > > The problem of separation only seems to appear in generic pom > inheritance, and then it is only the dependencies used that are of issue. > > For starters, in that case, we can just say its is best practice not to > inherit the dependency, then the parent becomes completely project/build > info which we are happy to have the auto versioning for. But that raises the question - is dependency inheritance worthwhile at > all any more? > - you can achieve the same thing with a transitive dependency, and in > fact can get "multiple inheritance" that way by selecting "dependency > packs" of related pieces when you use them all. > - this will be more likely with specification dependencies, again > removing the need. this is a great point...something I noticed in this build system I setup. It almost seems like dependency inheritence through a parent-child pom relationship is dangerous and promotes dependency polution. Having everything in dependencyManagement and then specifically bringing in the dependencies you need works well for me. Only area I would like to see expanded here is the ability to abstract that out a bit so I could reference a bundle of dependencies (which is the only thing I would consider using the existing dependency inheritence mechanism for, but would still be a pain in the arse). Basically if I have 9 oracle dependencies I would like to be able to in the child project reference one dependency for that entire grouping, and then be able to apply a scope to all the dependencies in that group at once. Kind of a dependencyGroup with an id and dependencyManagement....and perhaps that is what you meant by 'dependency packs' The issue I see here is the dependencyManagement, but that too I'd like > to de-emphasise in favour of better conflict resolution (ie, you should > be getting the same version anyway, so do you really need to have the > top level element?) boy I am not sure what you mean here...there needs to be a place in the top lvl build to hard code things like version of a particular dependency...and putting that in every dependency tag is a royal pita..so not sure what you mean by better conflict resolution on this note....maybe it is just late :P Possibly a separate discussion, but I'd like to hear thoughts. > > 4) Size of POM in JAR > > A: This is easily fixed by just including relevant information (exclude > all the build, reporting, profiles, etc). I remember one guy on irc talking about deploying into an embedded environment where he really watched every byte that was being taken up...kinda a niche case but something to consider, I think jdcasey was looking into that with the guy 5) What gets deployed to the repository > > A: I think its fine to push up the whole pom profiles and all as is now. > I'm concerned a bit about the size when you only need a subset of the > information - however long term I'd like to look into grouping the > metadata downloads and maybe using the index anyway so that probably > isn't relevant. keeping in mind I haven't read much code on this area...is the index idea that you have a single file at the toplvl of a particular dependency that is checksummed and if it is different get that new file and then mine through it checking individual checksums in that file to find the new artifacts/poms to download? cheers, jesse -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
