Re: glassfish repo must die
as long as it is in our control and and the only allowed repo configured in a pom... +1 domi On 04.04.2012, at 20:58, nicolas de loof 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 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
Re: glassfish repo must die
* Yes it is the bad practice to put repos in POMs * Yes it many more developers/contributors friendly to add repo in POMs (as far as we don't add not controlled repos and our artifacts aren't supposed to be reused) * Yes it was a bad idea and more generally all this part of projects infra description, users/groups settings As I said to Nicolas KK at the last hackergarten in Paris I drived a contribution for such mass change : https://gist.github.com/2305867 (by @jeanhelou) Nicolas might probably starts from it. Arnaud On Wed, Apr 4, 2012 at 10:44 PM, Jeff MAURY jeffma...@jeffmaury.com wrote: I think this is a bad Maven design to put repo definition in POM: this is an infrastructure item, it has nothing to do in POM and lead to people building repositories in bad places such a github, googlecode, ... My 0,5cent Jeff On Wed, Apr 4, 2012 at 10:38 PM, nicolas de loof nicolas.del...@gmail.com wrote: 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 2012/4/4 Jeff MAURY 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 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 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 -- 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 -- - Arnaud Héritier 06-89-76-64-24 http://aheritier.net Mail/GTalk: aherit...@gmail.com Twitter/Skype : aheritier
Re: Expose Maven POM values to Job environment
You're right. We need to have a dedicated tool to extract variables (such as version) in Maven pom. The tool must be Maven aware (to get as you noticed Maven version in the parent pom). And the tool must be self-contained (without to require an external Maven installation). On Wed, Mar 28, 2012 at 9:58 PM, Kirill Evstigneev k.evstign...@gmail.comwrote: On Tuesday, March 27, 2012 12:59:28 AM UTC+4, gboissinot wrote: On Mon, Mar 26, 2012 at 6:18 PM, Baron wrote: - What is the best way for me to access to parsed contents of the POM? Just parse it wit a XPath expression Unfortunately it won't work in many cases. E.g. when the version number is inherited from the parent POM. Workaround is possible but it's like re-implementing Maven.
Re: glassfish repo must die
Greetings,
On Thu, Apr 5, 2012 at 4:04 AM, Arnaud Héritier aherit...@gmail.com wrote:
* Yes it is the bad practice to put repos in POMs
* Yes it many more developers/contributors friendly to add repo in POMs
(as far as we don't add not controlled repos and our artifacts aren't
supposed to be reused)
* Yes it was a bad idea and more generally all this part of projects infra
description, users/groups settings
It's only bad because the location might change. Since it is really just a
CNAME record, I don't think the root cause of why specifying
{r,pluginR}epositories applies.
+1 to coding our own {r,pluginR}epositories section for our CNAME record
+1 to coding a m-enforcer-p rule which fails builds for
additional {r,pluginR}epositories
As I said to Nicolas KK at the last hackergarten in Paris I drived a
contribution for such mass change : https://gist.github.com/2305867 (by
@jeanhelou)
Nicolas might probably starts from it.
Please remember that there are close to 200 plugins which are in SVN still.
They would need to be migrated to GitHub before applying this kind of broad
and automatic conversion.
https://wiki.jenkins-ci.org/display/JENKINS/Moving+from+Subversion+%28svn%29+to+Github
-Jesse
--
There are 10 types of people in this world, those
that can read binary and those that can not.
Re: glassfish repo must die
On 4 April 2012 23:13, Kohsuke Kawaguchi kkawagu...@cloudbees.com wrote: On 04/04/2012 01:38 PM, nicolas de loof wrote: 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 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:jeffmaury@jeffmaury.**com 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.deloof@gmail.**comnicolas.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/**publichttp://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://riadiscuss.jeffmaury.com http://www.twitter.com/**jeffmaury http://www.twitter.com/jeffmaury -- Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ Try Nectar, our professional version of Jenkins
Re: glassfish repo must die
2012/4/5 Jesse Farinacci jie...@gmail.com
Greetings,
On Thu, Apr 5, 2012 at 4:04 AM, Arnaud Héritier aherit...@gmail.comwrote:
* Yes it is the bad practice to put repos in POMs
* Yes it many more developers/contributors friendly to add repo in POMs
(as far as we don't add not controlled repos and our artifacts aren't
supposed to be reused)
* Yes it was a bad idea and more generally all this part of projects
infra description, users/groups settings
It's only bad because the location might change. Since it is really just a
CNAME record, I don't think the root cause of why specifying
{r,pluginR}epositories applies.
+1 to coding our own {r,pluginR}epositories section for our CNAME record
+1 to coding a m-enforcer-p rule which fails builds for
additional {r,pluginR}epositories
As I said to Nicolas KK at the last hackergarten in Paris I drived a
contribution for such mass change : https://gist.github.com/2305867 (by
@jeanhelou)
Nicolas might probably starts from it.
Please remember that there are close to 200 plugins which are in SVN
still. They would need to be migrated to GitHub before applying this kind
of broad and automatic conversion.
Indeed, committing such a pom change to github will automatically stop the
svn - github sync, without plugin author to be involved, and this is bad.
I'll have to check on pom.xml for scm and commit at the right place
https://wiki.jenkins-ci.org/display/JENKINS/Moving+from+Subversion+%28svn%29+to+Github
-Jesse
--
There are 10 types of people in this world, those
that can read binary and those that can not.
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 On 4 April 2012 23:13, Kohsuke Kawaguchi kkawagu...@cloudbees.com wrote: On 04/04/2012 01:38 PM, nicolas de loof wrote: 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 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:jeffmaury@jeffmaury.**com 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.deloof@gmail.**comnicolas.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/**publichttp://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://riadiscuss.jeffmaury.com http://www.twitter.com/**jeffmaury http://www.twitter.com/jeffmaury -- Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ Try Nectar, our professional version of Jenkins
RE: glassfish repo must die
This increases the barrier to entry. Some plugins although they are still based of the same parent are internal to companies. Although the best practices is to use a repo manager - for some companies you may not have the ability to get extra artifacts added (as its for production software only) - or may not even be using a repo manager yet. /James From: jenkinsci-dev@googlegroups.com [mailto:jenkinsci-dev@googlegroups.com] On Behalf Of domi Sent: 05 April 2012 14:35 To: jenkinsci-dev@googlegroups.com Subject: Re: glassfish repo must die we should really add an enforcer rule which stops people from doing this /Domi On 05.04.2012, at 15:27, Arnaud Héritier wrote: Please remember that there are close to 200 plugins which are in SVN still. They would need to be migrated to GitHub before applying this kind of broad and automatic conversion. https://wiki.jenkins-ci.org/display/JENKINS/Moving+from+Subversion+%28svn%29+to+Github Seriously ? And they aren't dead ? Couldn't we migrate all of them in Git(Hub) ? ** 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 **
Re: glassfish repo must die
James, your right, that really does make sense! But I think we should make sure this is not true for OSS-plugins hosted in our repo and published to us… btw. central is not enforcing this rule: http://maven.apache.org/guides/mini/guide-central-repository-upload.html FAQ's /Domi On 05.04.2012, at 16:55, Nord, James wrote: This increases the barrier to entry. Some plugins although they are still based of the same parent are internal to companies. Although the best practices is to use a repo manager – for some companies you may not have the ability to get extra artifacts added (as its for production software only) – or may not even be using a repo manager yet. /James From: jenkinsci-dev@googlegroups.com [mailto:jenkinsci-dev@googlegroups.com]On Behalf Of domi Sent: 05 April 2012 14:35 To: jenkinsci-dev@googlegroups.com Subject: Re: glassfish repo must die we should really add an enforcer rule which stops people from doing this /Domi On 05.04.2012, at 15:27, Arnaud Héritier wrote: Please remember that there are close to 200 plugins which are in SVN still. They would need to be migrated to GitHub before applying this kind of broad and automatic conversion. https://wiki.jenkins-ci.org/display/JENKINS/Moving+from+Subversion+%28svn%29+to+Github Seriously ? And they aren't dead ? Couldn't we migrate all of them in Git(Hub) ? ** 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 **
Re: glassfish repo must die
From Git repository, if 'master' and 'svn' points to the same commit
you will know that it's still synced from Subversion. So I think it's
relatively easy to skip those.
Another way to do it is to make your script idempotent, and apply them
in Subversion first, and after it gets all synced, apply them all in
Git. Your idempotent script will not modify what's already updated, so
it'll work out.
On 04/05/2012 06:18 AM, nicolas de loof wrote:
2012/4/5 Jesse Farinacci jie...@gmail.com mailto:jie...@gmail.com
Greetings,
On Thu, Apr 5, 2012 at 4:04 AM, Arnaud Héritier aherit...@gmail.com
mailto:aherit...@gmail.com wrote:
* Yes it is the bad practice to put repos in POMs
* Yes it many more developers/contributors friendly to add repo
in POMs (as far as we don't add not controlled repos and our
artifacts aren't supposed to be reused)
* Yes it was a bad idea and more generally all this part of
projects infra description, users/groups settings
It's only bad because the location might change. Since it is really
just a CNAME record, I don't think the root cause of why specifying
{r,pluginR}epositories applies.
+1 to coding our own {r,pluginR}epositories section for our CNAME
record
+1 to coding a m-enforcer-p rule which fails builds for additional
{r,pluginR}epositories
As I said to Nicolas KK at the last hackergarten in Paris I
drived a contribution for such mass change :
https://gist.github.com/2305867 (by @jeanhelou)
Nicolas might probably starts from it.
Please remember that there are close to 200 plugins which are in SVN
still. They would need to be migrated to GitHub before applying this
kind of broad and automatic conversion.
Indeed, committing such a pom change to github will automatically stop
the svn - github sync, without plugin author to be involved, and this
is bad.
I'll have to check on pom.xml for scm and commit at the right place
https://wiki.jenkins-ci.org/display/JENKINS/Moving+from+Subversion+%28svn%29+to+Github
-Jesse
--
There are 10 types of people in this world, those
that can read binary and those that can not.
--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Nectar, our professional version of Jenkins
Re: How to save user's configurations in a plugin
See UserProperty. On 04/04/2012 02:52 PM, Jason Zhang wrote: Hi guys, I'm working on my first customized Jenkins plugin. I'd like this plugin to keep the configuration for each user, ie in a similar way as My Views. It's appreciated if anyone could point me to related documents or source code. Thanks in advance for your help. Jason -- Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ Try Nectar, our professional version of Jenkins
