"Eric Pugh" <[EMAIL PROTECTED]> writes:
>Henning,
Hi,
yes. I'm all +1 for this, however I'd prefer to go with some sort of
"turbine-components" repository in the near future. Actually, I
neither like the "fulcrum" name, nor do I think that we should've
opened up another namespace like org.apache.fulcrum.
Before you actually delete code from src/java, please talk with
jmcnally and the other t3 developers/users, I know that they actually
deploy/use Fulcrum and it wouldn't be nice from us (that we don't even
use Fulcrum) to break code that they use.
Personally, I'd prefer org.apache.turbine.components.<componentname>
to make clear that this is really _turbine_ code. For other stuff,
like the quartz scheduler: I wouldn't integrate this into the turbine
repo itself. If this is a component that implements a scheduler and
works in our context without changes: Fine. We put a "3rd party
components that work with Turbine" on the web site, add a link and are
done.
>Did you get a chance to read my follow up email and look at the changes I
>made in Fulcrum? After spending a stack of time trying to understand
>Fulcrum, I think I ended up at the same point you are at, about the Avalon
>components, and ditching the ServiceBroker stuff...
Yes, I'm fine with this. But IMHO this is not really relevant to
Turbine 2.3 but to future stuff. If you have time to work on this,
cool.
>So, in preperation for the post 2.3 future.. Should I continue down the
>path I am? I am happy to slap in a quartz version of the scheduler as well.
>(might throw in the wrapper to my JCrontab one as well ;-) ).
The quartz scheduler has its own home page (don't know where, would
have to look) and I'm fine with where it is. We should work with its
author so it can be used with the AvalonComponentService in 2.3 (hint,
hint. ;-) ) and in further Turbine stuff.
>If we are happy with what I am doing, then I will start deleting code out of
>/src/java and replacing it with the components. My only other question
>though is should all the services become components? And any suggestions on
>order...
Reworking fulcrum is a nice thing, even if all we do in the future is
just salvaging out the good bits. I don't even know whether there are
good bits left. The turbine-2 code has a solid year more work in it,
so it might have actually fallen behind turbine in some aspects.
The reactor build is cool, too (once we get a maven version to be
actually usable with the reactor), but I'd like to still be able to
build the various components separately if only for debugging. If you
want to see an interdependence nightmare, try building a single Avalon
package like "excalibur-component" from source. You will end up with
almost everything from the avalon project checked out and building
before you actually get what you want. I'd like to build a single
component which fetches all of its dependencies from ibiblio.
BTW: I'd prefer that we call jars of the various components broken out
of fulcrum to be called fulcrum-<whatever>-<version>.jar. So there is
clear where they come from.
If you really have time on your hands ;-) , there was some suggestion
on the avalon-dev list, that if we want to use an avalon container
with the AvalonComponentService, ECM might not have been the best
choice. Some developers proposed that we switch to Fortress which
seems to have more advantages and the switch from ECM doesn't seem too
big.
With the rifts that opened inside the Avalon project lately and all
the bad blood going on between the various authors, I'm not sure that
using anything beyond the Avalon Interface stuff would be a wise
decision. I have just skimmed the various discussions but I don't like
the fact that there seems to be no clear idea where to head with
Avalon in the future. There has been even talk about "redoing the
interfaces" and "split up the development", so I don't feel too good
about Avalon currently.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
