Missing libraries in Eclipse .classpath - Git Master source code

Openfire Openfire Dev
1

Hi folks,

I noticed that .classpath file delivered with master branch is not correct. Once copied to project root directory eclipse reports the following missing jars:

Description

Project ‘Openfire’ is missing required library: ‘build/lib/ant/ant-jive-edition.jar’

Project ‘Openfire’ is missing required library: ‘build/lib/ant/qdox.jar’

Project ‘Openfire’ is missing required library: ‘build/lib/commons-el.jar’

Project ‘Openfire’ is missing required library: ‘build/lib/dist/jdic.jar’

Project ‘Openfire’ is missing required library: ‘build/lib/dist/servlet-api.jar’

Project ‘Openfire’ is missing required library: ‘build/lib/jasper-compiler.jar’

Project ‘Openfire’ is missing required library: ‘build/lib/jasper-runtime.jar’

Project ‘Openfire’ is missing required library: ‘build/lib/merge/commons-logging.jar’

Project ‘Openfire’ is missing required library: ‘build/lib/merge/jsp-api.jar’

Project ‘Openfire’ is missing required library: ‘build/lib/merge/jstl.jar’

Project ‘Openfire’ is missing required library: ‘build/lib/merge/spdy-http.jar’

The project cannot be built until build path errors are resolved

Can someone verify and correct it, please.

2

Actually, this is not a first time this has been brought up (myself also). But as i was able to work around this in my environment and i’m not so experienced with Eclipse and development i wasn’t sure about it. I feel this might be an old artifact before migrating to Ant build and Github and probably not needed at all. Currently it only creates confusion.

@Guus der Kinderen, @Daryl Herzmann ?

3

I am a big fan of not having any IDE files in the repository. They’re often specific to one particular installation, and they do lag behind all the time. I’m not even using Eclipse myself, so I don’t update those anyway. I’d rather put them all in .gitignore.

The downside of this is that new developers will have to create their own project. Since we’re not using Maven, that’s not a trivial exercise.

4

Alright, I understand that the reason Openfire keeps using Ant build tool with no dependency management support is that migration to Maven is very complex task and possibly would require to freeze the project for month or two. Fortunately there is another solution Openfire community would nicely implement with no drama. I had been using for a long while Apache Ivy dependency management tool which integrates easily with Ant. I suggest community to consider this solution while migration to Maven is too difficult manage. Here is Quick Start Guide which will give you the idea how to use it with Ant:

Quick Start | Apache Ivy™

I’d contribute with migration to Maven or Ivy if help needed.

Now, as a new Openfire developer I imported whole project to Eclipse using build/eclipse/.classpath & .project files. This gave me an overview of actual project and plugin source code:

src/java

src/plugins/broadcast/src/java

src/plugins/clientControl/src/java

src/plugins/contentFilter/src/java

src/plugins/dbaccess/src/java

src/plugins/emailListener/src/java

src/plugins/fastpath/src/java

src/plugins/gojara/src/java

src/plugins/jingleNodes/src/java

src/plugins/justmarried/src/java

src/plugins/kraken/src/java

src/plugins/loadStats/src/java

src/plugins/monitoring/src/java

src/plugins/motd/src/java

src/plugins/nodejs/src/java

src/plugins/packetFilter/src/java

src/plugins/presence/src/java

src/plugins/registration/src/java

src/plugins/search/src/java

src/plugins/stunserver/src/java

src/plugins/subscription/src/java

src/plugins/userCreation/src/java

src/plugins/userImportExport/src/java

src/plugins/userservice/src/java

src/plugins/xmldebugger/src/java

src/test/java

src/test/throttletest/src

I was able to build with Ant the main Openfire project using command line:

ant openfire

I investigated the target directory and realized that Openfire by itself does not use too many jars. All jars I noticed are:

bcpg-jdk15on.jar

bcpkix-jdk15on.jar

bcprov-jdk15on.jar

hsqldb.jar

javax.websocket-api.jar

jtds.jar

log4j.xml

mail.jar

mysql.jar

npn-boot.jar

openfire.jar

postgres.jar

slf4j-log4j12.jar

startup.jar

I believe that all the rest required jars are part of Jetty or Tomcat server used to deploy Openfire to. I am not clear which jars actually are required but Eclipse reports the following classes missing:

bodyContent cannot be resolved

BodyTagSupport cannot be resolved to a type

Config cannot be resolved

Description

ContainerInitializer cannot be resolved to a type

Description

EVAL_BODY_BUFFERED cannot be resolved to a variable

Description

EVAL_PAGE cannot be resolved to a variable

InstanceManager cannot be resolved to a type

JettyJasperInitializer cannot be resolved to a type

JspC cannot be resolved to a type

JspException cannot be resolved to a type

JspTagException cannot be resolved to a type

JspWriter cannot be resolved to a type

LocalizationContext cannot be resolved to a type

Log cannot be resolved to a type

LogConfigurationException cannot be resolved to a type

org.apache.commons.logging cannot be resolved to a type

And many more…

It is not clear to me which jars from the following directories I am supposed to add to classpath in order to satisfy Eclipse configuration:

build/lib/*

build/lib/ant/*

build/lib/dist/*

build/lib/merge/*

build/lib/src/*

Another my observation is that even though I downloaded fresh Master version of the project from repository, the command “ant plugins” fails with errors which indicate missing libraries. Let me print here some:

[of.javac] /Users/softpro/devel/openfire/Openfire/work/plugins-dev/fastpath/target/jspc/ja va/org/jivesoftware/openfire/plugin/fastpath/user_002dbrowser_jsp.java:76: error: cannot access JspWriter

  • [of.javac] webManager.init(request, response, session, application, out ); *

  • [of.javac] ^*

  • [of.javac] class file for JspWriter not found*

  • [of.javac] /Users/softpro/devel/openfire/Openfire/work/plugins-dev/fastpath/target/jspc/ja va/org/jivesoftware/openfire/plugin/fastpath/workgroup_002dchatbot_jsp.java:77: error: cannot access PageContext*

  • [of.javac] workgroupAdminManager.init(pageContext);*

  • [of.javac] ^*

  • [of.javac] class file for PageContext not found*

  • [of.javac] /Users/softpro/devel/openfire/Openfire/work/plugins-dev/fastpath/target/jspc/ja va/org/jivesoftware/openfire/plugin/fastpath/workgroup_002dimage_002dsettings_js p.java:76: error: incompatible types: javax.servlet.jsp.PageContext cannot be converted to PageContext*

  • [of.javac] workgroupAdminManager.init(pageContext);*

  • [of.javac] ^*

  • [of.javac] /Users/softpro/devel/openfire/Openfire/work/plugins-dev/fastpath/target/jspc/ja va/org/jivesoftware/openfire/plugin/fastpath/workgroup_002dsound_002dsettings_js p.java:76: error: incompatible types: javax.servlet.jsp.PageContext cannot be converted to PageContext*

  • [of.javac] workgroupAdminManager.init(pageContext);*

  • [of.javac] ^*

  • [of.javac] /Users/softpro/devel/openfire/Openfire/work/plugins-dev/fastpath/target/jspc/ja va/org/jivesoftware/openfire/plugin/fastpath/workgroup_002dsummary_jsp.java:84: error: incompatible types: javax.servlet.jsp.PageContext cannot be converted to PageContext*

  • [of.javac] webManager.init(pageContext);*

  • [of.javac] ^*

  • [of.javac] /Users/softpro/devel/openfire/Openfire/work/plugins-dev/fastpath/target/jspc/ja va/org/jivesoftware/openfire/plugin/fastpath/workgroup_002dtext_002dsettings_jsp .java:126: error: incompatible types: javax.servlet.jsp.PageContext cannot be converted to PageContext*

  • [of.javac] workgroupAdminManager.init(pageContext);*

**

**

It would be very nice of community to share with me working eclipse project configuration files. Or any other specification showing which project or plugin project requires which libraries.

Thanks!

5

I’ve started the migration to Maven last year and created a pull request:

Migrate build process from Ant to Maven (WIP). by sco0ter · Pull Request #347 · igniterealtime/Openfire · GitHub

If you want you could help, share ideas, etc.

I feel like 60-70% of the work is done. It builds, creates documentation zips and creates an executable jar file, which starts Openfire.

The remaining issues are the native installers (which currently are built with Ant) and some dependencies on non-Maven artifacts (especially in plugins).

Plugins theoretically build as well, but they need some minor work.

If you are willing to help, we should discuss how to proceed.

6

Hi CSH,

I reviewed current implementation of Openfire Maven configuration and my top priority would be to refactor and use default Maven directories src/main/java, src/main/resource and src/test/java for all projects and plugin. Next step is to make sure that plugins have all dependencies satisfied.

I also noticed nice ability of Ant script which might be difficult to implement with Maven. What I mean is customization described here: Openfire: Customization Guide Did you think about it?

And the last thing on my priority list is to build native installers. I personally don’t need this functionality. I believe the easiest way to keep it is by using maven-antrun-plugin probably with some tweaks. This way we would reuse existing and well tested Ant configuration.

What do you think?

7

Please be aware that apart from regular “download-and-run” users, there is a very large number of projects that depend on the existing Openfire code base. Companies find ways to integrate with our product and/or our code base in ways that keep amaze me - and I only see a fraction of what people out there are doing. Ours is a pretty old code base: a lot of beautiful (and ugly) things have been created over time.

There are lots of organizations out there that depend on and/or have invested heavily in integration with our code-base: perhaps not in ways that we envisioned it, but those implementations exist none-the-less, providing value for their owners. It is too easy to think “gha, they’ll then have to stick with the old version, or re-do their integration” - we cannot do that. If we choose to turn things around, we must facilitate those people, and we must do so to a very long degree. We cannot apply “improvements” if that means that basically every integration has to be done over.

Whatever solution we find, it is important to be very, very conservative, be as backwards compatible as possible, and have a full set of migration aids (scripts, tutorials, etc) available. We will be applying a dramatic change (even when being conservative) - we should focus on limiting the impact as much as possible. This goes a long way down into nitty-gritty details. I am, for example, very wary of refactoring the directory structure to match the Standard Directory Layout. Yes, we’ll end op being more compliant to Maven, but it will make migration from the old code base to the new code base next to impossible for any larger project that uses something as simple as scripts to copy parts of our code. And that’s just a basic example.

I am, by the way, in favor of moving to Maven - that’s why I started the effort in the first place. However, we cannot treat this as a typical refactoring. Ours is an a-typical project: we’re very different from an in-house developed code stack, or a closed-source, over-the-shelf piece of software. Our software is open, widely distributed, and has a lot of legacy. That’s not bothersome bagage, that’s something to treasure.

8

Someone submitted this fix for eclipse Merge pull request #577 from danielhams/eclipseprojectfix · igniterealtime/Openfire@ea76ccd · GitHub

9

Hi wroot,

That would be me :slight_smile:

Hopefully you should be able to use the eclipse project out of the box now - with the notable exception of a couple of plugins (clustering and rayo) the majority of the source code is now included in the eclipse project too.

For the clustering plugin there’s a dependency on some code that isn’t in git, while for the rayo plugin there’s some little code clashes that make importing into a single eclipse project difficult. I think the thing is “good enough” ™.

I’d advise still performing the ant build (ant openfire; ant plugins) and then refreshing the eclipse project to pick up the necessary bits.

Let me know if you (or anyone else) have issues with it.

Cheers,

Dan