This was added with the JPA commit and I think we should discuss a
little bit about the need for this component and how it will work.
The way it is currently setup it's obviously pretty limited since it
really only contains a few classes, but the way I see it if we are going
to use this core component it should be reserved for those things which
truly are 'core' to all existing and potential Roller apps. I also
think it should attempt to limit its dependencies as much as possible so
that you don't need a dozen jars to make use of the roller-core.jar.
And finally, I think it should refrain from attempting to house code
which could potentially have a reason to be different between apps.
So with those guidelines in mind here's what I think about what is
currently there and what could be put in there ...
* RollerException class. I am okay with this *only* if it becomes an
abstract class. We already do a horrible job of classifying our
exceptions and instead resort to just throwing a RollerException in
pretty much all cases and that's not good programming practice. If we
take this class and move it into Roller Core then that would likely only
make things worse. What I would suggest is that we use the
RollerException class in Roller Core to serve as a base for each app to
derive it's own app specific exceptions from, so Roller Weblogger should
have a WebloggerException which extends RollerException, and Roller
Planet should have a PlanetException which extends RollerException.
* JPAPersistenceStrategy. My personal opinion is that this class should
not be in Roller Core because it's not something we can guarantee should
be the same across all apps. I can certainly envision a time in the
future when we want to make a change to this class to support something
in Roller Weblogger, but making that change would conflict with other
apps like Roller Planet. I also don't like the fact that it puts a
dependency on a persistence framework and it's jars in order to build
and user Roller Core. And I also think it's annoying that it moves this
critical piece of code away from the place where you would expect to
find it in the app code, which makes it hard to be looking at the
Weblogger code and trace the full persistence implementation.
* UUIDGenerator. jdk 1.5 has a UUID class which we could possibly use
instead and this would be nice since it eliminates a dependency. Also,
strictly speaking this is something that I could see different apps
wanting to have their own control over. If at some point one of the
apps wants to change it's surrogate key strategy then it would be
forcing that change for other apps, which is not a good thing.
I think the best candidates for inclusion are things from the
roller.util package which are purely reusable utility code, such as
something like a DateUtil class.
To be honest though, at the end of the day I'm not really sure that it
makes much sense to try and manage a core component at this time. We
only have 2 apps and from what I see the amount of code that would be
appropriately shared between the two is fairly limited. I think it may
be more of an annoyance to maintain this core component, but of course
code reuse is something we should strive for.
-- Allen
- Roller Core Component Allen Gilliland
-
