New ebuilds for the Glassfish Application Server (aka Sun Java System Application Server) - https://glassfish.dev.java.net/. Reproducible: Always Steps to Reproduce: I have created 2 new ebuilds for Glassfish - one for the current stable version V2UR2 (build 04) and another for the latest release V2.1 (build 37). These ebuilds are glassfish-bin-2.0.2.04.ebuild and glassfish-bin-2.1.0.37.ebuild respectively. They are both built from the downloadable artifacts provided off the Glassfish site. Locally, I have placed them under www-servers/glassfish-bin, however there may be a more appropriate location in the tree. glassfish-bin-2.0.2.04 has two USE flags: 'cluster' for server cluster build, and 'ml' for multilingual package. glassfish-bin-2.1.0.37.ebuild has only the 'cluster' USE flag as no multilingual package is provided. I have tested this on an x86 platform. I expect it should work on an amd64 platform simply by adding the "~amd64" keyword, but I can't test that. If/when the ebuilds are deemed usable, the glassfish-bin-2.0.2.04 should be made stable for x86 (and hopefully amd64), the other remaining as unstable. Glassfish also provides packages for other OSes, however I can't check those either (and some tweaking to the ebuild would likely be necessary). Finally, these are my first real ebuilds I've created, so any feedback on improvements would be appreciated.
Created attachment 156817 [details] Glassfish 2.0.2.04 ebuild
Created attachment 156819 [details] Glassfish 2.1.0.37 ebuild
- glassfish is open source, so there shouldn't be -bin ebuilds, but regular ones, please refere to the documentation by the Gentoo Java team - no reason for RESTRICT="nomirror I think, the software is under GPL - rdepend should be virtual/jre, no?! - elog "" --> einfo "", no log spamming please, I'm cringing on the additonal elog lines in pkg_setup() and the per domain elogs, too, while on the other hand I'd welcome an ewarn, when such an operation fails. pkg_postinst should better have one or two elog lines pointing to a file holding additional non-critical post install notices, pkg_postrm() can be shortened, too - cp -pPR, please
Two further issues I came across so far: 1) License Popup Before unpacking, the installer shows a graphical license popup on a non-headless machine... unfortunately, the installer seems to ignore -Djava.awt.headless=true, so the only way I got the installer to use the console license dialog was to unset DISPLAY before starting it. 2) Sandbox violation The ant target create.domain tries to write to /root: open_wr: /root/.asadmintruststore
(In reply to comment #3) > - glassfish is open source, so there shouldn't be -bin ebuilds, but regular > ones, please refere to the documentation by the Gentoo Java team Normally I would agree, however the source build process for glassfish requires cvs access with a userid (see: https://glassfish.dev.java.net/public/BuildGlassFish.html#Complete_Instructions_on_how_to_Build). The source bundle provided on the download page is not adequate to build it. > - no reason for RESTRICT="nomirror I think, the software is under GPL Ok, I'll remove it. I just had troubles getting the downloads from the glassfish.dev.java.net site until I put that in - it was hitting my mirror sites and failing. > - rdepend should be virtual/jre, no?! No. An app server needs a JDK, not a JRE. It needs access to javac when running (to compile jsp). > - elog "" --> einfo "", no log spamming please, I'm cringing on the additonal > elog lines in pkg_setup() and the per domain elogs, too, while on the other > hand I'd welcome an ewarn, when such an operation fails. pkg_postinst should > better have one or two elog lines pointing to a file holding additional > non-critical post install notices, pkg_postrm() can be shortened, too I'll change the elog to einfo for the messages. I read the devloper docs and was looking at the tomcat ebuilds as an example and it's littered with elogs, so I was a bit unsure. I'll fix the pkg_postinst to point to a file with the details and somehow reduce pkg_postrm message (I may even remove it entirely, it's not that important). And I'll see what I can do about ewarn message(s). > - cp -pPR, please No problems, will change.
(In reply to comment #4) > Two further issues I came across so far: > > 1) License Popup > Before unpacking, the installer shows a graphical license popup on a > non-headless machine... unfortunately, the installer seems to ignore > -Djava.awt.headless=true, so the only way I got the installer to use the > console license dialog was to unset DISPLAY before starting it. right - I did this on non-X server box and didn't catch this. I'll unset DISPLAY to remove the problem. > > 2) Sandbox violation > The ant target create.domain tries to write to /root: > open_wr: /root/.asadmintruststore I'll look into it.
Created attachment 157087 [details] Glassfish 2.0.2.04 ebuild with fixes I've marked the original 2 ebuilds as obselete. I'll add a fixed 2.1.0.37 ebuild when this version has been deemed acceptable. Fixes in this ebuild: * einfo instead of elog * cp -pPR * cleaned up the messages to a file put into the installation, a 1 line message to indicate the file. * removed pkg_postrm * added unset DISPLAY to stop graphical popup. * removed RESTRICT * added ~amd64 - I was able to test on this arch The only thing I was not able to satisfactorily solve were the sandbox issues (there's 2 files written outside the sandbox). I added 'addwrite' for those, as I could not get any workarounds to actually work. :(
For glassfish to be added to tree, it needs to be built from source. With most aspects of glassfish packaged on it's own. We have packaged a few pieces in tree. I was last hung up on glassfish-jsf-api or what ever I called the package in java-experimental overlay. Some time ago, haven't touched it since. At best a -bin version of glassfish might get committed to an overlay, but never to tree. Not likely what you want to hear, but that's the deal. Tons of work to be done, and as one packages aspects of glassfish on it's own. One quickly realizes many of glassfish's components require stuff no in tree. So more work there package those deps.
(In reply to comment #8) > For glassfish to be added to tree, it needs to be built from source. And I agree this is a good long-term aim, however I still think an interim 'bin' package is worthwhile. For example, maven is in the tree as a 'bin' package and I believe work is being done on a source built package. Glassfish is undergoing a major version change to V3. It's at this version I'd look at packaging from source, not V2. However, V3 is basically alpha and feature incomplete at this time. So, if this ebuild relegated to an overlay only that would be unfortunate, but there's little I can do about it.
Well maven is not really a good example comparison. Some might consider it a core package like ant, needed to build other packages. While we have not found the need to integrate it with portage yet. There was some work there. There also is work done to build maven from source in the java-overlay. Which just needs a maintainer to go to tree. Now back to Glassfish. I do not disagree that there are benefits to starting with a -bin package or having one. Comparison to any from source results with unbunled deps is a good one. Also more importantly. It's install aspects, init, system integration stuff. Can be used for any from source build. That stuff is not likely to change, other than maybe location stuff is when built, vs shipped in binary. If your serious about seeing Glassfish in tree we really need a maintainer. Even for a -bin package. If interested we can see about getting you overlay commit access. So you can work on the -bin from there, and if interested and skills are there can look to become a developer and maintainer of Glassfish if you wish. But beyond talking here, and contributions. Would be good to see and interact with you on IRC. That's usually a step in getting overlay commit access, and so on. I don't think anyone would be upset or stop someone from committing a -bin Glassfish, JBoss, etc to tree. It's not ideal per Gentoo Java policies, but really the limiting factor there is a dedicated maintainer. No one maintaining the herd, or other Java apps servers is interested or has the time atm. Even for a -bin package. I personally am not interested in proxy maintainership atm. But that might be an option as well.
(In reply to comment #10) Ok, all good points. And it's time to discuss elsewhere. I'll try to see you on IRC/email sometime to talk about these items.
This is a good work, but I have some problems with it: First, this ebuild doesn't handles a case of cluster node upgrade. I think the nodeagent dir checking, and stopping a listable nodeagent is a not too difficult step, but good if you really thinking about clustering support. The second thing is a server configuring. There is no reason for do it from ebuild, because this is completelly user decision, and I don't think this is a good solution. I think it would better, if you display a postinstall message about how to configuring GlassFish to clustering or to standalone server. The third thing: i think the support putting docroot/webapp dirs somewhere to /var folder can be a good idea. Symlinks is a good solution, like Tomcat.
