incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <Janne.Jalka...@ecyrd.com>
Subject Re: Vote requested: package renaming
Date Tue, 30 Dec 2008 19:03:20 GMT
> Ok. How stable is your ongoing JCR work? For what it's worth, I merged
> my Stripes branch with trunk continually for a year and a half. The
> solution I came up with, as you know, was to bend over backwards to
> break as little as possible.

That's my approach as well, but unfortunately, SVN merges are  
brittle, especially with respect to renames of files (which I learned  
when I moved WikiPage to *.api - which essentially broke everything.)

> that in the JIRA thread. If you would like to re-draft item #2, please
> feel free.

It's your vote.  I don't think we need to vote on these things -  
votes very easily become a blunt instrument for solving problems  
without thorough discussion.

I did telecom standardization for a few years.  We haven't even begun  
to disagree on anything in such a major way that a vote would be even  
remotely necessary, IMHO.

> Agreed, but we wouldn't be debating about "where it should be" if the
> new .api package didn't exist.

In which case we couldn't even *talk* about APIs, because we didn't  
have any - just interfaces for random classes.

I personally don't like factories much - it's somehow odd to create  
an interface, a class and a factory just to represent a single  
entity.  That's just way too many classes and too much development  
overhead.  Interfaces represent aspects and contracts, and really the  
only reason I think we should turn things like WikiPages into  
interfaces is in order to separate e.g. rendering engine from the  
core to ease embedding work.  And if we can't do that because there  
is no stable API interface set, then there's no point in creating  
interfaces either.

> I do not agree that it is "absolutely mandatory." Interfaces *should*
> be stable -- that's a tenet of good Java style. If we design
> interfaces carefully (as we both agree we should), why create a whole
> new package tree? It's redundant and inelegant.

Because we need to be able to separate stable and unstable  
interfaces.  Because it is not visually obvious whether you are using  
an interface or a class.  Because it is not obvious when something is  
stable.  Because JSPWiki the *implementation* is more important than  
JSPWiki the *API*.  Because convention should be preferred over  
documentation and configuration.  Because Exceptions are not  
interfaces, and therefore you can't say "interfaces are stable,  
classes are not".  Because of all the reasons I gave at JSPWIKI-38,  
none of which have been rebutted, except with a "it's a non- 
starter".  Which is also rather disappointing.

> I *would* favor creating a separate API package tree if we could name
> it something *really different*, like keeping com.ecyrd.jspwiki -- but
> that is not an option for us. So the next best option, IMO, is to keep
> everything in the same tree, just like we've always done.

Well, that's where we disagree.

> To get a sense from the group. You and I have expressed our opinions
> fairly clearly already. It's time to hear from everyone else.

Of course, there is no point for everyone else to vote, since -1  
vetoes all other opinions on code changes.  You could've just voted  
-1 (a notion of disagreement, without a veto) to get a consensus  
feeling.

/Janne

Mime
View raw message