Jenkins is an application that monitors executions of repeated jobs, such as building a software project or jobs run by cron. Among those things, current Jenkins focuses on the following two jobs: 1. Building/testing software projects continuously (continuous integration) 2. Monitoring executions of externally-run jobs Reproducible: Always Here you can find an ebuild for jenkins: https://code.google.com/p/godin-gentoo-repository/source/browse/trunk/repository/dev-util/jenkins-bin/
Created attachment 337128 [details] jenkins-bin-1.466.2-r1.ebuild works for me
Created attachment 337130 [details] file/conf
Created attachment 337132 [details] files/init.sh
Created attachment 356130 [details] jenkins-bin-1.527.ebuild Version bump for current release, add a USE=standalone when using tomcat as a frontend
Created attachment 356132 [details] jenkins-bin-1.509.2.ebuild Version bump for LTS release, add a USE=standalone when using tomcat as a frontend
Created attachment 356136 [details] files/jenkins.initd Rewrite of original init.d to support /run and construct init inspired from tomcat init script
Created attachment 356138 [details] files/jenkins.confd Updated files/jenkins.confd according to previous files/jenkins.initd
All this work can be followed at http://git.meleeweb.net/cgit.cgi/distros/gentoo/portage.git/log/dev-util/jenkins-bin
For Java packages we prefer them to be build from source when they can, as well as to unbundle any dependencies that may arise. For Jenkins, we will again have to work with snapshotting to do this; we can basically capture a snapshot of https://ci.jenkins-ci.org/view/Jenkins%20core/job/jenkins_main_trunk/ws/ (using zip link at the bottom) and then work on getting that compiled. A very first step would then be to run `mvn ant:ant` to obtain a build.xml file which can be placed in the files directory, then from java_prepare (not src_prepare!) that file can be copied to ${S}, after which you include java-ant-2; from there on the rest of http://www.gentoo.org/proj/en/java/java-devel.xml can be followed. Bin packages usually are a product of compiling them our own and hosting our compilation results; there are some exceptions in the tree, but they merely are based on the high need for those packages and the complexity of doing it our own. It might be the case that jenkins needs to split up in multiple packages; as you can see, most of the directories contain their own file, so we would for example have jenkins-core, jenkins-plugin and so on... But after all, it doesn't look too complex to package.
I accept precompiled java bloat in sunrise since java sucks anyway and there is almost zero gain.
From the .git directory I found that there are source code releases available: https://github.com/jenkinsci/jenkins/releases
We first need to add hudson from bug #157550.
(In reply to Tom Wijsman (TomWij) from comment #12) > We first need to add hudson from bug #157550. Why this bug should depend on hudson? From the time of the fork, the two are independent?
(In reply to Christian Strahl from comment #13) > (In reply to Tom Wijsman (TomWij) from comment #12) > > We first need to add hudson from bug #157550. > > Why this bug should depend on hudson? > From the time of the fork, the two are independent? Thanks for the question and detail, let's me explain and look close: It fails to build because hudson is missing; so, it seems to be necessary. Small excerpt listing some from /var/tmp/portage/dev-java/jenkins-core-1.527/work/jenkins-jenkins-1.527/core/pom.xml: ... <dependency> <groupId>org.jvnet.hudson</groupId> <artifactId>jtidy</artifactId> <version>4aug2000r7-dev-hudson-1</version> <exclusions> <exclusion> <groupId>jdom</groupId> <artifactId>jdom</artifactId> </exclusion> </exclusions> </dependency> ... <dependency> <groupId>org.jvnet.hudson</groupId> <artifactId>task-reactor</artifactId> <version>1.2</version> </dependency> ... <dependency> <groupId>org.jvnet.hudson</groupId> <artifactId>activation</artifactId> <version>1.1.1-hudson-1</version> </dependency> ... Small excerpt from the build log: [javac] /var/tmp/portage/dev-java/jenkins-core-1.527/work/jenkins-jenkins-1.527/core/src/main/java/jenkins/model/Jenkins.java:34: error: cannot find symbol [javac] import hudson.model.Messages; [javac] ^ [javac] symbol: class Messages [javac] location: package hudson.model On a second look: There however are some parts of hudson present, actually the above class does appear to be there under the form of ./work/jenkins-jenkins-1.527/core/src/main/resources/hudson/model/Messages.properties; so, this might also be the consequence of building with Ant instead of Maven. Because as long as there is no source build Maven in the tree, we cannot build it that way... The structure indeed seems to fork but it does more than that and actually wrap around the code; so, it is a source bundled library. To end up with sane ebuilds, we will need to separately package this under the form of something like jenkins-hudson-*. Packaging hudson on its own will come as a benefit; as what we achieve there, can easily be reused to package this source bundled library. Especially since the recursive logic appears to be missing here.
(In reply to Tom Wijsman (TomWij) from comment #9) > For Java packages we prefer them to be build from source when they can, as > well as to unbundle any dependencies that may arise. > > For Jenkins, we will again have to work with snapshotting to do this; we can > basically capture a snapshot of > https://ci.jenkins-ci.org/view/Jenkins%20core/job/jenkins_main_trunk/ws/ > (using zip link at the bottom) and then work on getting that compiled. All the instruction to build Jenkins from sources is available at https://wiki.jenkins-ci.org/display/JENKINS/Building+Jenkins This need mvn that is provided by dev-java/maven-bin which itself is not compiled from source in portage tree. Maven is pretty fat bloat if I'm not wrong (but probably) and bring a lot of dependencies (even dev-java/osgi-core-api with fetch RESTRICT). Anyway I'm trying to make it compile from source with your recommendation. > It might be the case that jenkins needs to split up in multiple packages; as > you can see, most of the directories contain their own file, so we would for > example have jenkins-core, jenkins-plugin and so on... Good idea. On the way to do this.
What's the status on this?
(In reply to Samuel Damashek from comment #16) > What's the status on this? I continue to maintain binary ebuild as mvn usage is a bit huge for my current needs.
(In reply to Bertrand Jacquin from comment #17) > I continue to maintain binary ebuild as mvn usage is a bit huge for my > current needs. I don't see an issue with adding an mvn ebuild; we have a lot of other huge packages in the tree as well. That's off topic though, does that prevent us from adding a jenkins ebuild?
(In reply to Samuel Damashek from comment #18) > (In reply to Bertrand Jacquin from comment #17) > > I continue to maintain binary ebuild as mvn usage is a bit huge for my > > current needs. > > I don't see an issue with adding an mvn ebuild; we have a lot of other huge > packages in the tree as well. That's off topic though, does that prevent us > from adding a jenkins ebuild? Not at all. The point is that building jenkins from source with mvn is a huge work while binary packages provided by jenkins-ci are fine for me.
*** Bug 526166 has been marked as a duplicate of this bug. ***
Jenkins is now in portage: dev-util/jenkins-bin This bug can be closed.
Indeed Christian so I'm gonna go ahead and close to bug so that it clears up a bit the bugzilla queue. Please reopen in case of problems.
No, it is not fixed yet, as jenkins-bin is just a binary package. This is a bad workaround for packages, that you cannot compile from source easily. Please check if dev-utils/jenkins is added to the tree, before marking this bug as resolved.
