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. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
