A roadmap to bring together XpTrackerPlugin and YetAnotherXpTrackerPlugin

My apologies to the authors of XpTrackerPlugin. Our organization has leveraged this plugin to great succes and made, over the years, many enhancements to this plugin. Unfortunately, we remained on Athens due to reasons not important here, and thus we are vastly out of synch with the current version. I have now moved our version to Dakar and wanted to share these enhancements with the community. My hope is that this plugin can eventually merge back into XpTrackerPlugin. -- YetAnotherXpTrackerPlugin

As someone looking to adopt such a plugin, which of these two plugins is advised? What are their relative strengths? Are their dependencies incompatible? Do the teams behind each of these projects see themselves supporting their own branch going forward?

Having two incompatible projects is plain confusing. Can we guide people as to which to use? Is there a chance to eliminate the differences?

-- MartinCleaver - 06 Aug 2008

Actually, there are at least four different implementations that I know of:

• XpTrackerPlugin
• EnhancedXpTrackerPlugin
• YetAnotherXpTrackerPlugin
• XpTrackerNGPlugin (an evolution of XpTrackerPlugin that we use, which is not public yet)

I have looked through the ones that are not mine, and noticed that they are quite the same, but not the same. As both of them have good ideas inside (like, using DBCacheContrib as a backend for the Stories, or enhanced navigation through the information), I'm trying to consolidate them.

My idea is to have something like XpTrackerContrib that provides the "object model", topic parsers, storage engine and such, so each plugin focus only on the navigation and reports. Perhaps even integrate ideas from ProjectPlannerPlugin and forks.

In an ideal world, you should be able to use all plugins at the same time in the same web to exploit their features, as the underlying information is abstracted by the contrib.

-- RafaelAlvarez - 08 Aug 2008