Hi folk! This is an ongoing process, so you will see this issue move a couple of times until we consider it "complete". I have a number of things in the works that I'm going to begin documenting internally. But to give you a quick summary.

1. I'm looking to set up hosted yum and apt repositories, that admins can point directly at, run by us basically
2. Investigating the many distributions out there and seeing where people are already building dists for us, or where we should get our foot in the door, etc
3. Maybe even offer to take over a couple of the builds for certain distributions

I'll try to keep you posted as things progress! Probably via this issue. =)

See http://mcepl.fedorapeople.org/rpms/openfire-3.4.4-1.fc9.src.rpm – that's my first initial attempt of packaging for Fedora. It is still not what I would like it to be – too much stuff from your tarball which should be used from the system packages. But it seems to work, although it doesn't seem to be as stable as ejabberd on the same computer. I will try to put it on the diet a little bit more, build it in mock (I am not sure whether xxx succeeds; if it does, we have package which is buildable on Fedora/Rawhide with IcedTea).

Concerning your previous comment – I don't think it is a good idea, to make your own repository. Just cooperate with the downstream maintainers (like me ) to keep openfire packages inside of the downstream repositories. Then your users don't have to fiddle with yum/apt/whatever configuration but just run their native installation procedure (yum install openfire in my case).

Will keep in touch.

Sorry, forgot to add URL to the koji build http://koji.fedoraproject.org/koji/taskinfo?taskID=365939

chuckle I'd have to disagree. Plenty of folk have expressed quite a bit of excitement in us having our own repositories. And putting on my sysadmin hat a moment, I always prefer pointing at the vendor's own stuff instead of using whatever came from the distribution. (like frankly I like /opt/openfire and a bundled JRE over the openfire dist being scattered all over the file system and some JRE that I don't know that the vendor hasn't tested =) ) That said, I know a lot of folk have the opposite thoughts on it, so I feel having both options would cover both bases.

So regarding downstream maintainers ... are you volunteering to keep the Openfire Fedora RPM up to date? ;D

a) yeah, sure that's the point – I am a maintainer of the couple of packages in Fedora (none of them by far the size of openfire though, and none of them in Java), and I would like to maintain openfire in Fedora, so that we have both leading XMPP servers in (actually, ejabberd is now in pretty rough shape in Fedora/Rawhide, because of beta version of both ejabberd and erlang).

b) I have of course no problem with you maintaining your own version of the package – and I don't care that much about moving files around, that's the least of all problems.

c) What I would really like to clean out in your package is not using local packages for something we have in the distro already packaged. Not only it saves a lot of space (just by removing Sun JVM I saved 20MB; and there is just no reason in the world we should ship one more ant.jar with XMPP server), it is a maintenance nightmare to fiddle with all those duplicit libraries. I remember when development of Debian stalled for couple of weeks, when a security bug in libz was discovered, and everybody was just searching and fixing all those packages which used local copy of libz. One of the first things RH people changed in the IcedTea was that it now uses glibc version of time-data format, so we don't have to fiddle with Java whenever some politician decides that the current timezone of their country is not good enough for them.

And I guess that just by removing all .jars which are already present in the system won't be enough, right? I will have to patch (at least) build/build.xml, right? I am not a Java programmer, so I don't know, if for example just by removing path specification from build.xml, right (i.e., ant won't look for them in the standard locations)?

BTW, why I cannot find an open MUC for openfire-related discussions. The ones on conference.jivesoftware.com seem to be per-invitation only, which really doesn't foster community development. Couldn't you open at least community@ MUC, please? It looks really weird, when you have community only for invited.

open_chat@conference.igniterealtime.org is the main muc room for chatting about igniterealtime products =)

Yeah, I know about open_chat@conference.igniterealtime.org, but it would be nice if somebody was there .

More distribution locations have been located and recorded. We have worked out where we are going to serve the yum and apt repositories, but have not figured out the proper procedure. Haven't heard from the Fedora 9 contact in a bit, need to see how things are going on that front.

Sorry, the contact (that's me) was told by the administrators of of the part of the internal network where I planned to install the Jabber server, that OpenFire being Java app is too big for the internal network comparing to ejabberd which is apparently much more lightweight (there is currently not that many users of the server, so I won't get a dedicated server for that).

So, when I won't get answer to any of my questions I asked (see <http://www.igniterealtime.org/community/people/mcepl?view=discussions>) and I had to learn to use ejabberd anyway, I more or less stopped working on openfire packaging anymore.

=(

These things happen. Thanks for your input none-the-less! Good luck with your new setup!

Still, I would be interested in the answers to my questions – although in this particular project I won't use openfire, I consider it in same aspects (not hardware requirements, I am afraid, though) to be superior to ejabberd. For small server with sufficient hardware available it could be really good match (if I didn't have the problems I mentioned in the other threads).

Hi, I am also a Fedora packager, and am interested in ironing out these issues. I also know Java pretty well, so that should help.

I would say that the biggest issue I see here is that the "source" tarball has a lot more than just source in it. Not that it's a big deal, but Fedora has to build everything from source by policy anyway, so the extra jars and things don't help. Also, having a smaller upstream source release helps the Fedora mirrors, and avoids problems with shipping of things that Fedora might not be able to redistribute (like a JRE).

Any jar file or binary library you ship in your source tarball would have to be separately packaged in Fedora if it is not already. But that's no problem, I (or whoever packages it), will go through and package all the dependencies too. This was done for Eclipse, which was a pretty long process, but allows Fedora to guarantee that anyone can rebuild any of Fedora from scratch.

Maybe a good start is to figure out what can be split out of your source tarball.

Hi, Adam,

just to note, that a) I am not a Java deloper, b) I gave up on Openfire (and running my own JAbber server), so openfire in Fedora is probably all yours to play.

Update: In addition to seeing OpenFire in distribution channels, I would very much like to see an RPM download which does NOT include a JRE. I'd prefer to rely on my OS or update channels for keeping the JRE current.

Hi, yet another Fedora packager here. I am willing to help create a Fedora / Enterprise Linux package and package all dependencies for Fedora. I would have to comply with Fedora's packaging guidelines. Specifically, it is not allowed to bundle software from other projects. For more information on this policy, you can read here: http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

From the build instructions at http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/source-build.html, it is clear that I can use my system JRE. I have successfully built openfire this way, so that is not a problem. However, I see a lot of .jar files (with already compiled java code) and even a .so file in the source distribution. I would not be allowed to distribute these. Thankfully, there is build/lib/versions.txt, which will be really helpful when unbundling the dependencies from the source distribution.

I see there was no reply to Adam's comment. Is there any interest in this community to create a smaller source distribution, and work with package maintainer (me) to make openfire compatible with system libraries? Having openfire in official Fedora repositories could encourage its popularity. Work to unbundle openfire from dependencies would help not just for Fedora, but for any Linux distribution. It allows system administrators to use system libraries, if they wish so, or if they need to follow company policy, too.

Howdy. I, a svn committer, would be happy to help with this process.

Nice to hear from you, Daryl Herzmann. Okay, as a first step. What do you think about this patch to always rebuild subdirinfo task from source?

Index: build.xml
===================================================================
--- build.xml	(revision 13041)
+++ build.xml	(working copy)
@@ -32,11 +32,6 @@
             <pathelement location="${basedir}/build/lib/ant-contrib.jar"/>
         </classpath>
     </taskdef>
-    <taskdef name="subdirinfo" classname="org.jivesoftware.ant.SubDirInfoTask">
-        <classpath>
-            <pathelement location="${basedir}/build/lib/ant-subdirtask.jar"/>
-        </classpath>
-    </taskdef>
     <taskdef name="xmltask" classname="com.oopsconsultancy.xmltask.ant.XmlTask">
         <classpath>
             <pathelement location="${basedir}/build/lib/xmltask.jar"/>
@@ -338,7 +333,7 @@
         </if>
     </target>
 
-    <target name="plugins-dev">
+    <target name="plugins-dev" depends="anttasks">
         <!-- Setup Openfire -->
         <ant antfile="${basedir}/build/build.xml" dir="${basedir}" target="openfire"
              inheritAll="false" inheritRefs="false"/>
@@ -1206,7 +1201,7 @@
     </target>
 
     <!-- plugins =============================================================================== -->
-    <target name="plugins" description="Builds all plugins">
+    <target name="plugins" description="Builds all plugins" depends="anttasks">
         <tstamp>
             <format property="buildJavaDate" pattern="MMM dd, yyyy"/>
         </tstamp>
@@ -1248,7 +1243,7 @@
         </for>
 
     </target>
-    <target name="-plugins-impl-dev" if="plugin.dev.dir">
+    <target name="-plugins-impl-dev" if="plugin.dev.dir" depends="anttasks">
 
         <!-- Get a list of plugins in the optional dev dir -->
         <subdirinfo dir="${plugin.dev.dir}" property="dirlist2" ifexists="plugin.xml"/>
@@ -1638,6 +1633,12 @@
         <jar jarfile="${anttools.target.dir}/ant-subdirtask.jar">
             <fileset dir="${anttools.target.dir}/classes" includes="**/*.class"/>
         </jar>
+ 
+        <taskdef name="subdirinfo" classname="org.jivesoftware.ant.SubDirInfoTask">
+            <classpath>
+                <pathelement location="${basedir}/build/lib/ant-subdirtask.jar"/>
+            </classpath>
+        </taskdef>
     </target>
 
     <!-- clean ================================================================================= -->

Thank you for your time.

I've assigned this to Guus so that he can follow along as well with these suggestions, thanks for the help!

r13042 has the patch

I am very sorry. When I updated to r13042, I noticed I made a silly mistake. Now, it does build from source each time, but it doesn't use that, it still uses the version in build/lib.

Perhaps it is a good idea to delete build/lib/ant-subdirtask.jar? That would make sure it relies on the version that is built from source. This jar builds fast, so a convenience copy is probably not necessary. That would mean 1 bundled jar down, only 71 to go.

Index: build.xml
===================================================================
--- build.xml	(revision 13042)
+++ build.xml	(working copy)
@@ -1636,7 +1636,7 @@
  
         <taskdef name="subdirinfo" classname="org.jivesoftware.ant.SubDirInfoTask">
             <classpath>
-                <pathelement location="${basedir}/build/lib/ant-subdirtask.jar"/>
+                <pathelement location="${anttools.target.dir}/ant-subdirtask.jar"/>
             </classpath>
         </taskdef>
     </target>

Thanks, lets see what Guus has to say about this.

Is there any update? Can I continue working on this?

Sorry, I have not heard from Guus.

Can someone add openfire to an APT repository so we can install it and get upgrades using apt-get?

Currently even Oracle Java is available via webupd8.org repository.

One bug related to Java 7 is that init.d script does not look for /usr/lib/jvm/java-7-oracle so it is missing from detecting java and fails silently.

This ticket is rather vague and probably needs to be closed in favor of more specific ones. Any objections?

closing as this ticket is too vague.