[
https://issues.apache.org/jira/browse/JSPWIKI-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659421#action_12659421
]
Murray Altheim commented on JSPWIKI-38:
---------------------------------------
Janne,
Yes, I have realized I would have to rewrite all of the existing plugins for
3.0. That represents about 45 plugins (of the publicly available ones; there
are more private ones) and more than 150 classes, many of which will be
affected. I assume that support for a lot of these in 3.0 will disappear, as I
can't realistically rewrite that many plugins. Yes, I might be able to solicit
some help. The Assertion Framework is about 20 plugin classes and a lot of
tie-ins to the WikiEngine, PageManager, events code, etc. The TagManager would
likewise need wholesale revision. I'm hoping all of my higher-priority classes
can be migrated, otherwise I'll be forced to stay with 2.x. I really don't
want to be the Fletcher Christian of JSPWiki, believe me. We all know what it
was like on Pitcairn Island for the survivors.
While we've not had interfaces, I've treated any of the *Manager classes as
relatively stable entities, and in the past been able to maintain currency with
the trunk through a constant migration. As I wrote, this was a relatively
stable migration, and yes, it would have been mitigated had there been APIs.
I have assumed that going to JCR meant a wholesale upending of any previous
managers, but I have also assumed (perhaps wrongly) that the basic
functionality of the manager classes would be *relatively* easy to recreate via
some bridging manager classes. Are you saying there'd be no PageManager at all
in 3.0? If there is, or there's something akin to it, it should be *relatively*
easy to replicate the functionality via a bridging PageManager class that I can
use. As for using factory classes rather than constructors, hey, I'm all for
that. I don't mind rewriting stuff when it truly is a simplification but
doesn't alter the fundamental structure and functionality.
As you say, JSPWiki has been a set of classes on which you can. And I have
hacked a great deal and now I must pay.
As for not permitting APIs within the regular class hierarchy, why is that a
non-starter? Aesthetics? I've resisted making arguments based on aesthetics
during this discussion. I may not be the world's cleanest coder, but of the
~200K lines of code in Ceryle l've got interfaces and implementations in the
same hierarchy, and I've got them in separate hierarchies. With versioning the
interfaces over time (over seven years) I'm not sure that either has made a
substantial difference. I've had to make changes in the interface based on
changing project needs. Where the API was located would have made little
difference. Interfaces vary in stability too.
But yes, I understand the difference and I don't think I disagree with you in
the basics. A guarantee would be nice, but it would be only a relative
guarantee and (to my mind) shouldn't come at the expense of significantly
complicated code or package structure. Factories are by nature a bit more
complicated, but god have I seen a variety of different approaches to that,
some extravagantly complicated, others almost as simple as using a constructor.
What about the idea of creating a single package {{org.apache.jspwiki.api.*}},
and placing within that the WikiEngine and all of the existing manager classes
as interfaces (bridges to previous managers)? How different is that from what
you're proposing? Why do the APIs need to be in some other hierarchy? [I don't
have a problem with Foo and FooImpl being in the same package hierarchy or even
the same package if Foo is labeled as a stable interface with a version number,
where FooImpl is the default implementation.]
You keep writing things that I agree with, then you write something that
seemingly contradicts that agreement. Perhaps I'm just misunderstanding you.
Yes, we're just having a conversation towards finding a good solution to this.
Thanks for your continued patience.
> Rename packages to "org.apache.jspwiki"
> ---------------------------------------
>
> Key: JSPWIKI-38
> URL: https://issues.apache.org/jira/browse/JSPWIKI-38
> Project: JSPWiki
> Issue Type: Task
> Reporter: Janne Jalkanen
> Assignee: Janne Jalkanen
> Fix For: 3.0
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
