I am building a plugin for openfire. I have upgraded to the new version of openfire (3.3.0) but this version comes with some things which I find quite ‘‘unorthodox’’.
After resolving some errors (due to the name change) in my plugin - I tried to compile - hit some errors about apache commons-lang classes. After much stuffing around I looked into the openfire jar and saw that it actually contains a package called org.apache.commons.lang and overrides the StringEscapeUtils.
Why is this done? It is causing problems because I am trying to use the actual commons-lang version of that class and causes conflicts.
I encountered the same problem, its not limited to commons-lang (which is rather outdated so it’'s a real problem if you want to use newer things like HTML escaping provided by commons-lang 2.0).
openfire.jar also contains (among others) sitemesh, jzlib, dom4j, sl4j, mina, JSP API, standard taglib, jaxen, …
The reason for this is probably to make the build process more easy given that dependency management is a bit difficult with ant. I am not sure how this could be easily solved without creating some trouble but the trouble may still be worth it.
At least the internally used versions of third party libraries should be renamed (e.g. org.jivesoftware.org.apache.commons…) so they are no longer conflicating.
Any thoughts?
P.S. Of course switching to Maven and using proper dependency management would be another great option g
Yes - I noticed that other libraries also had the same issue. I have seen this in a couple of projects I have worked and can see no good reason for it. As you said - they should rename the packages so as not to conflict with the original packages.
Maven would be great for this project - but it does have a fairly rigid project structure (which can of course be overcome with little effort).
I am not sure how to proceed now because I cannot use some of the functions in commons-lang 2. I am thinking I will have to copy over the relevant functions I wish to use into my own function and call that so as to get around the conflict - sux.
Do you have any ideas as to how to work around it - or maybe get ignite to change it?
Having openfire as a maven project would definitively be great.
In my company I’'m currently using maven to build a war version of openfire and we will be more than happy to help in the process of moving openfire to maven.
The hardest path in using maven is definitively dependency management.
Is there any Jira issue tracking this? That looks quite problematic to have standards packages like apache commons overriden by the API we’'re linking to. What changes should we expect actually?
Of course, Maven’'s dependancy management rocks as well