Re: [Jenkins] Building on Eclipse Indigo

I'm using Eclipse Indigo with m2e and building Jenkins (did it yesterday, actually). I simply ignore the messages regarding the missing m2e connectors (though you can fix that [1]). Usually I change the code in Eclipse, but with Jenkins I prefer execute mvn hudson-dev:run from command line. I g

Re: [Jenkins] Building on Eclipse Indigo

m2eclipse is bundled in Éclipse distribution since Indigo. The last version is quite stable. Is it really necessary to uninstall it to switch to another plugin ? Mat Le 6 avr. 2012 à 00:36, Jeff MAURY a écrit : > You should not use m2e but rather the maven eclipse plugin > > Jeff > > Le vend

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.

Re: glassfish repo must die

I agree though, that maven central would be much better long term. On 5 April 2012 23:47, Chris van Es wrote: > Does the comment > > "If you are exposing your source and want to make it easy for others to > build, then consider adding a repository entry to your POM, but don’t pick > a URL lightl

Re: glassfish repo must die

Does the comment "If you are exposing your source and want to make it easy for others to build, then consider adding a repository entry to your POM, but don’t pick a URL lightly, think long-term, and use a URL that will always be under your control." not agree with what the other guys have been s

Re: glassfish repo must die

It was detailled here : http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/ On Fri, Apr 6, 2012 at 12:39 AM, Chris van Es wrote: > I don't see anything wrong with specifying a repo which is under > developers control in the parent pom. It's a feature of ma

Re: glassfish repo must die

I don't see anything wrong with specifying a repo which is under developers control in the parent pom. It's a feature of maven and I use this feature regularly within my workplace to force our builds to use a repository manager for all dependencies and keep everything internal. I don't know Jenkins

Re: [Jenkins] Building on Eclipse Indigo

You should not use m2e but rather the maven eclipse plugin Jeff Le vendredi 6 avril 2012, Matthieu Vincent a écrit : > Hi, > > i've tried for 2 days to build Jenkins under Eclipse Indigo with no > success. > > I followed all informations on > https://wiki.jenkins-ci.org/display/JENKINS/Buildin

[Jenkins] Building on Eclipse Indigo

Hi, i've tried for 2 days to build Jenkins under Eclipse Indigo with no success. I followed all informations on https://wiki.jenkins-ci.org/display/JENKINS/Building+Jenkins But when i import the projects on Eclipse after running mvn -DdownloadSources=true eclipse:eclipse, I get plenty of errors

Retrieve repository URL from changesets of a Jenkins Job with multiple git repositories

Hello git, svn and repository browser developers, In Jenkins I can add multiple repositories URL for git or svn in the same Jenkins job configuration. This means I can get a big changeset for a build with changes from multiple repositories. Because I want to extend the Trac-plugin, one kind of

Re: glassfish repo must die

On 04/05/2012 06:03 AM, Stephen Connolly wrote: 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 elim

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,

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,

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)

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

Re: glassfish repo must die

> > 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

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 > On 4 April 2012 2

Re: glassfish repo must die

2012/4/5 Jesse Farinacci > Greetings, > > On Thu, Apr 5, 2012 at 4:04 AM, Arnaud Héritier 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

Re: glassfish repo must die

On 4 April 2012 23:13, Kohsuke Kawaguchi wrote: > On 04/04/2012 01:38 PM, nicolas de loof 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 avai

Re: glassfish repo must die

Greetings, On Thu, Apr 5, 2012 at 4:04 AM, Arnaud Héritier 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

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 a

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 descripti

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