My bad - I took an action a long time ago to investigate this and I did but never really got back to anyone or progressed it to its conclusion.
Getting an artifact that is not under our control whose project has no interest in pushing it isn't a problem. What's more of a stumbling block - and what I have just asked the maven list is what we do with all the patched jars we have (svnkit/winstone) /James From: jenkinsci-dev@googlegroups.com [mailto:jenkinsci-dev@googlegroups.com] On Behalf Of nicolas de loof Sent: 05 April 2012 14:22 To: Stephen Connolly Cc: jenkinsci-dev@googlegroups.com Subject: Re: glassfish repo must die synch to central will fix dependency to jenkins artifacts (so most of plugins) but we still have some plugins to depend to artifacts that aren't available on central, -> guice-2.0.1, or de.regnis.q.sequence:sequence-library (for svn-stuff) for sample 2012/4/5 Stephen Connolly <stephen.alan.conno...@gmail.com<mailto:stephen.alan.conno...@gmail.com>> On 4 April 2012 23:13, Kohsuke Kawaguchi <kkawagu...@cloudbees.com<mailto:kkawagu...@cloudbees.com>> wrote: On 04/04/2012 01:38 PM, nicolas de loof wrote: jenkins-ci.org<http://jenkins-ci.org> <http://jenkins-ci.org> is under our control so we can point it to whatever we like also, plugin can't build without a repo declaration as jenkins artifacts aren't available on central I don't thing this to be a bad practice. Would you expect all developers to configure settings with adequate repo to build your project ? This *only* is a requirement for deployment on central just my 2 cents :P Yes, the goal here is to make it easier for people to check out plugins and build them, so that they can apply patches. Many of them are Maven newbies. Then let's sync to central. Every added step (like ~/.m2/settings.xml tweaking) is a hurdle. We should have <repository> definition in POM to avoid this. Nope... we should just sync to central As Nicolas wrote, repo.jenkins-ci.org<http://repo.jenkins-ci.org> is our domain that we control, so the same thing won't happen again. (There is a separate effort to make more of our artifacts available in central, which would eliminate this problem in a long run, but we shouldn't wait for that.) Why not just hurry that effort along ;-) 2012/4/4 Jeff MAURY <jeffma...@jeffmaury.com<mailto:jeffma...@jeffmaury.com> <mailto:jeffma...@jeffmaury.com<mailto:jeffma...@jeffmaury.com>>> You should rather delete this repo definition as it is not a good Maven practice and may lead to the same problem in the future. Jeff On Wed, Apr 4, 2012 at 8:58 PM, nicolas de loof <nicolas.del...@gmail.com<mailto:nicolas.del...@gmail.com> <mailto:nicolas.del...@gmail.com<mailto:nicolas.del...@gmail.com>>> wrote: Hi folks, as you know, glassfish maven repo (aka m.g.o-public) is definitively off, but we depend on it for many plugins dependencies, and this is hardcoded in plugin parent pom (so, to get it fixed, plugin would need to upgrade to a recent jenkins-core dependency). some of you may already encounter dependency resolution issues trying to build a plugin form scratch I volunteer to migrate the 400+ plugins to replace <repository> pointing to m.g.o-public and replace/add repo.jenkins-ci.org/public<http://repo.jenkins-ci.org/public> <http://repo.jenkins-ci.org/public> where missing, so that each plugin explicitly defines repository to our infra (I plan to write a tool for that). We discussed this on governance meeting, but I wan't to ensure everybody agree here, so please let me know if you see any drawback or have another suggestion. Nicolas -- Jeff MAURY "Legacy code" often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury -- Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ Try Nectar, our professional version of Jenkins ________________________________ ************************************************************************************** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmas...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00 **************************************************************************************
