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
