Am 09/28/16 um 19:27 schrieb Stephen Connolly: > On Wednesday 28 September 2016, Christian Schulte <[email protected]> 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] For additional commands, e-mail: [email protected]
