Or we say that repositories must be self-consistent and include a "sources" metadata at the root.
If I resolve A from central and B from corp-proxy... B may list central' ID as an aggregated source, in which case it doesn't matter if the artifact is in both A and B, we can just take the artifact from B. If A and B do not have an aggregating relationship then we have some issues to resolve. But we should be knowing where the artifacts (and PDTs) come from (local storage needs a refactor to split out per remote repo) I believe we can solve this problem by shunting to the consumer when resolving their aggregate PDT from their immediate dependencies... and thus avoid baking repositoryId into the PDT.., rather we tag the model *in code* with details of whence it came ;-) On Wednesday 28 September 2016, Christian Schulte <[email protected]> wrote: > Am 09/28/16 um 19:27 schrieb Stephen Connolly: > > On Wednesday 28 September 2016, Christian Schulte <[email protected] > <javascript:;>> wrote: > > > >> Am 09/28/16 um 08:25 schrieb Stephen Connolly: > >>> So if we provide a way to decentralise. > >> > >> We do already. > >> > >>> > >>> So now junit hosts their own artifacts, not central > >> > >> Or some company hosts it at the same coordinates and I happen to need to > >> add that repository to a project of mine. > >> > >>> Now the absolute worst happens, they lose the artifacts, and the gpg > >>> signing key > >> > >> Same can happen at central. > >> > >>> > >>> But they still have source code. > >>> > >>> So they rebuild from source and sign with new key. > >>> > >>> What happens all the old projects which claim definitive junit 4.12 is > >> the > >>> old key? > >> > >> Maybe it's not about signing the content. Here is what I would like to > >> enforce in a way a situation like the following isn't possible > >> technically any more. > >> > >> Company A forks commons-lang with patches applied and deploys that using > >> a different -target level than in central to it's own public repository > >> A using the same coordinates as in central. > >> > >> Company B forks commons-lang with different patches applied and deploys > >> that using a different -target level than in central and in repository A > >> to it's own public repository B using the same coordinates as in > central. > >> > >> I need artifacts hosted in both repositories and will need to add them > >> to either the POM, the settings or I need to setup a repository manager > >> in front of all of that. Which commons-lang should I be using? The > >> artifacts in repository A depend on the patches only available in > >> repository A and the artifacts in repository B depend on the patches > >> only available in repository B. No one cared to provide those patches > >> upstream. Maybe the patches are conflicting with each other. So I'd like > >> to make it impossible for someone not the authority for the commons-lang > >> group id to deploy artifacts there. With Maven 4.0.0, they should at > >> least change the group id to something they are the authority for and > >> add a '<provides commons-lang>' so that such conflicts can be detected > >> automatically. Althouth this example appears kind of far-fetched (is > >> that the correct term?) I have been running into situations like these > >> in the past and kept my fingers crossed that the commons-lang from > >> central still can be used. This is a maintenance nightmare for sure. > >> Currently I simply stopped using different repositories and only use > >> central personally. That's not always possible. > > > > > > Well we know the tree of artifacts that we resolved from A and the trees > of > > artifacts that we resolved from B. > > > > If both trees reference commons-lang then we will have to address the > tree > > conflict somehow. > > > > If that means the commons-lang from an A tree wins, we should resolve > from > > A... if a B tree wins, resolve from B... > > > > If we cannot resolve the conflict, we may just check the checksums and > say > > idempotent if the hashes match or fail the build if they differ. > > > > That's one tack anyway > > > > Looks like the repository really needs to be part of the coordinates. So > that "origin" or "repository" attribute would do. Can be optional. If > not set, defaults to "central". > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] <javascript:;> > For additional commands, e-mail: [email protected] <javascript:;> > > -- Sent from my phone
