Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-dev@incubator.apache.org
Message-ID: <1203089095.1230433424250.JavaMail.jira@brutus>
Date: Sat, 27 Dec 2008 19:03:44 -0800 (PST)
From: "Murray Altheim (JIRA)" <jira@apache.org>
To: jspwiki-dev@incubator.apache.org
Subject: [jira] Commented: (JSPWIKI-38) Rename packages to
 "org.apache.jspwiki"
In-Reply-To: <13380135.1195162423024.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/JSPWIKI-38?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1265=
9407#action_12659407 ]=20

Murray Altheim commented on JSPWIKI-38:
---------------------------------------

Since there seems to be some perception that my comments are overly critica=
l I'll preface this with the note that my entire motivation for writing thi=
s is in hope that I'll be able to continue to use JSPWiki 3.0 following the=
 migration. There are a number of factors that effect that, the biggest bei=
ng time available. [Apologies for the length.]

As Andrew has alluded, I'm not one who appreciates complexity for complexit=
y' sake. I doubt Janne is either and I'm assuming his motivations for this =
are as he has stated. Reading over his comments above (27/Dec/08 03:26 AM) =
I think I agree with most of them, particularly that our priority is to pro=
duce the WikiEngine. I certainly don't require an API to that, which would =
only limit my abilities. [And *please* don't create private packages or beg=
in using dashes in package names. Ugh.]

In the case of the JAXP API I can see the rationale for separating the API =
from the implementations, since the latter are derived from a number of dis=
parate code bases. But in this case we are developing a *wiki*, which tradi=
tionally has been one of the simplest software applications, and we're deve=
loping an implementation that is: (a) likely to be the main if only impleme=
ntation; (b) has no prior API commitments; and (c) is going to break all pr=
evious implementations, given it is going to (by design) recommend and/or r=
equire that all previous extensions (frameworks, plugins, etc.) use the new=
 implementation since that implementation is guaranteed to change (with at =
least a package name change). This latter point might seem to suggest the n=
eed for an API, but that would also be satisfied by a relatively stable imp=
lementation (which has been the status quo). A package name change would ma=
intain that stability more than changes to the fundamental architecture.

I must confess that I don't know why we *really* need a separate API packag=
e. For the past few years I've been able to follow the changes to the imple=
mentation as it has gradually gone from version to version. Would such an A=
PI be any more stable? Really? I'm probably a good test case on how much ac=
cess to the innards of the engine will be available via the API. While Jann=
e is rightfully critical of my armchair statements, not having attempted to=
 migrate my Assertion Framework to 3.0, at this point I'd be a fool to do s=
o even if I had the time. It's a bit of a chicken and an egg problem, as I'=
d much prefer to wait until the 3.0 code has stabilised before doing that, =
yet I'd be the first to note any deficiencies for extension classes as I hi=
t those limitations, so any API 1.0 would likely need to become an API 1.1 =
as I found places in the API that needed opening.=20

While I'd really hate to lock the project into the 2.x code, I'm going to h=
ave a tough time convincing management of what is (to an outside observer) =
going to look like architectural changes with few if any user benefits. I.e=
., I'd be spending a large amount of time coding to remain with the 3.0 cod=
e base with little obvious benefit in the outward application. I'd have to =
rewrite *all* of the custom plugins (which includes all the CeryleWikiPlugi=
ns plus others not publicly available), the Assertion Framework, and (on th=
e side, unrelated to paid work) all of the integration code used to make JS=
PWiki work embedded in Ceryle (if that will even be still possible, which r=
emains to be seen since they're fairly tightly integrated). I don't know ho=
w much work that'd be but it hardly sounds trivial.=20

Merely changing the package names is by comparison almost a trivial exercis=
e (accomplished e.g., via a sed script). While not wanting to sound sour ab=
out 3.0 you might begin to see that my perspective on this is based on look=
ing ahead at what *sounds like* a great deal of work (with little in-house =
support for it), which is why I'm a bit worried. I am enthusiastic as I've =
said before about Priha since I can likely justify that to my boss and perh=
aps even use that in other places. But wholesale architectural changes for =
what is an wiki project seem to me to be overkill, at least for 3.0.

If put to a vote I'd agree with Andrew's recommendation that we simply rena=
me the packages for now.  If there's a need for an API for the rendering en=
gine, we make a simple API for that within the package hierarchy. I don't s=
ee the need for a separate package for that API. If an API really simplifie=
s things for me, well, then great; I just don't yet see that.

In a nutshell, this is again simply a call for simplicity where possible.

Murray

PS. While this may seem tangential to any arguments here, my time on this i=
s until sometime in the coming year very limited, as like many here I've go=
t a busy project schedule. I've basically got to apply to my boss if I'm go=
ing to spend a substantial amount of time doing the migration, which means =
I need to convince him of the need. The Assertion Framework was "unfunded" =
by a rather useless director who just resigned, so following his happy disa=
ppearance I've got to re-apply in the new year to get the project re-funded=
, and the amount of time required will have a lot to do with the decision, =
given the organisation has a lot of pressing needs that I'm qualified to sa=
tisfy. I don't want to fork the code, or be forced into using a fork, but I=
 can say that looking at our organisation for the next three years we're go=
ing to be under a very restrained budget. We're also moving out of the curr=
ent building during a renovation with all that entails for a . I simply won=
't have the time to do large changes. I know that none of this is anyone el=
se's concern but I doubt I'm the only one in a similar situation. Maybe I a=
m and I'm therefore ignorable. I don't know.=20

> 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
>
>


--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.