Revised ebuild for jetty from source
Created attachment 96878 [details] jetty-6.0.0.ebuild
Created attachment 96879 [details] ChangeLog
Created attachment 96880 [details] ChangeLog
Created attachment 96881 [details] files/6.0.0/jetty
Created attachment 96882 [details] files/6.0.0/jetty.init
I'm getting this, I guess due to my usersandbox userfetch userpriv. Also, any reason you aren't using the tar.gz file from the website, now its out? * subversion check out start --> * repository: http://svn.codehaus.org/jetty/jetty/tags/jetty-6.0.0 mkdir: cannot create directory `jetty': Permission denied !!! ERROR: www-servers/jetty-6.0.0 failed. Call stack: ebuild.sh, line 1539: Called dyn_unpack ebuild.sh, line 711: Called src_unpack jetty-6.0.0.ebuild, line 19: Called subversion_src_unpack subversion.eclass, line 278: Called subversion_fetch subversion.eclass, line 183: Called die !!! subversion.eclass: can't mkdir jetty. !!! If you need support, post the topmost build error, and the call stack if relevant. !!! When you file a bug report, please include the following information: GENTOO_VM=sun-jdk-1.5 CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.5.0.08" JAVACFLAGS="-source 1.5 -target 1.5" COMPILER="" and of course, the output of emerge --info !!! This ebuild is from an overlay: '/usr/local/portage'
Live ebuilds, ie that pull from svn/cvs are relatively discouraged. Considering it is tagged, should probably make a tarball of it instead. Or better yet, use a released distfile if there is one containing source..
There are a number of other issues that need to be addressed. For starters, we aren't supporting building packages using maven yet for several reasons. See section of the meeting notes from our recent meeting: http://planet.gentoo.org/developers/nichoj/2006/09/10/summary_of_java_team_meeting Don't inherit java-vm-2. That is explicitly for vms. So unless jetty includes a vm, it doesn't need it :) The src_unpack is redudant, as subversion exports its src_unpack.. but as mentioned, subversion shouldn't be used in this case. Unnecessary cd ${S} in src_compile, as this happens by default. You don't need to switch-vm. This happens automatically for you. You could use ${T} as root's home, since that is already a temp dir. But as mentioned, we're not supporting building with maven. I would also consider slotting jetty, because we may want to let users have more than one jetty installed, ie jetty-5, jetty-4, etc.
http://prdownloads.sourceforge.net/jetty/jetty-6.0.0.zip?download Thats a valid url. Are we cool with using zips for downloads?
Yes, that's fine. Just be sure do DEPEND on app-arch/unzip.
Created attachment 97670 [details] jetty-6.0.0.ebuild Hows this one look? Using zips and slotted.
Slightly better. But there are still a number of improvements that could be made: P=${PN}-${PV}, so you can use the SRC_URI: SRC_URI="mirror://sourceforge/${PN}/${P}.zip" Since this is a major release from what was last in the tree, keywords should be dropped to what you can test on. It is also worth noting that we don't support Java on sparc in particular. The indentation in DEPEND is inconsistent, ie some is tabs, other is spaces. I'm pretty sure you generally want to be doing the creation of users/group in pkg_setup. This is because pkg_setup is the only phase that would happen when using binpkgs (tbz2). Doing a backup off the old /opt/jetty also seems a bit questionable to me. In src_compile, still making maven_temp and using that as maven home, should use ${T} instead. Also still using maven, which we aren't supporting yet within ebuilds. See http://overlays.gentoo.org/proj/java/wiki/Maven_Notes In src_install: * INSTALLING isn't used for anything * There is a way to set default options for doins, so it'd be owned by jetty by default. I forget offhand the way, but it should be in developer handbook or the devmanual. * There are convienence methods for installing conf.d and init.d methods, ie doconfd, newconfd, doinitd, newinitd. * Use insinto /etc/jetty and doins instead of cp * Use insinto ${JETTY_HOME} and doins -r instead of cp
Created attachment 97738 [details] www-servers/jetty/jetty-6.0.0.ebuild
Created attachment 97739 [details] www-servers/jetty/files/jetty-6.0.0-init.d
Created attachment 97740 [details] www-servers/jetty/files/jetty-6.0.0-conf.d
How do these new ones look? Think I did all your changes, added an "examples" useflag, made the doc useflag just vary on javadoc, stopped using maven and made the slotting nicer.
Looks much better. However, now the source isn't being compiled :) I'm not sure what the best way to deal with it is. Basically, for each maven module, you'd need to do mvn ant:ant to get a build.xml, and build them that way. Another minor thing: use examples && doins -r examples extras project-website webapps \ || dodir ${JETTY_HOME}/webapps This is a bit unwieldly, would be clearer to use if/else
(In reply to comment #17) > Looks much better. However, now the source isn't being compiled :) I'm not sure > what the best way to deal with it is. Basically, for each maven module, you'd > need to do mvn ant:ant to get a build.xml, and build them that way. Yeh, I realise that it isn't, but its distributed as a working binary, you don't need to use maven, the other guy just chose to. Should it be jetty-bin, or is it fine as jetty, as you don't support maven building yet? > Another minor thing: > use examples && doins -r examples extras project-website webapps \ > || dodir ${JETTY_HOME}/webapps > This is a bit unwieldly, would be clearer to use if/else Sure thing, will sort this. You may want to obsolete the other ebuilds, as I can't.
(In reply to comment #18) > Yeh, I realise that it isn't, but its distributed as a working binary, you > don't need to use maven, the other guy just chose to. Should it be jetty-bin, > or is it fine as jetty, as you don't support maven building yet? > We should be building it, that is what we should do :) What I was saying above is generate build.xml files for eveything, stick those into ${FILESDIR}, then use ant at build time.
> We should be building it, that is what we should do :) What I was saying above > is generate build.xml files for eveything, stick those into ${FILESDIR}, then > use ant at build time. Can that be done automagically, or does it require all the build.xml files to be manually created?
Only one way to find out...
This is a binary ebuild and really would need to be compile from source for acceptance. If someone works on a compile from source version, gets it into decent shape, and it meets minimum QA. We will add it to the overlay like with 5.1.x per bug 68082
Closing bug. Removed from tree, till we get a maintainer and current version from source.
