You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Jukka Zitting <ju...@zitting.name> on 2005/09/08 11:46:26 UTC
[VOTE] Revert the great split
Hi,
As suggested by Tobias, I'd like to start a vote on whether to revert
the "great split" proposed and implemented as issue JCR-157
(http://issues.apache.org/jira/browse/JCR-157). I'm ready to undo the
restructuring, but I'd like a clear consensus before doing that. So
please vote on whether we should revert the split.
[ ] +1 Revert the JCR-157 changes
[ ] 0 Happy with either project structure
[ ] -1 Do not revert the JCR-157 changes
The vote is open until the end of this week. I'll close the vote and
take actions accordingly on Monday the 12th.
BR,
Jukka Zitting
Re: [VOTE] Revert the great split
Posted by Jukka Zitting <ju...@zitting.name>.
Hi,
> [ ] +1 Revert the JCR-157 changes
> [ ] 0 Happy with either project structure
> [ ] -1 Do not revert the JCR-157 changes
+1, see my previous messages on the subject for arguments.
BR,
Jukka Zitting
Re: [VOTE] Revert the great split
Posted by Edgar Poce <ed...@gmail.com>.
[ ] +1 Revert the JCR-157 changes
[X] 0 Happy with either project structure
[ ] -1 Do not revert the JCR-157 changes
BR,
edgar
Re: [VOTE] Revert the great split
Posted by Manu <ma...@dimano.sk>.
[X] +1 Revert the JCR-157 changes
[ ] 0 Happy with either project structure
[ ] -1 Do not revert the JCR-157 changes
Re: [RESULT] [VOTE] Revert the great split
Posted by Michael Wechner <mi...@wyona.com>.
Jukka Zitting wrote:
> Hi,
>
> The vote result is mixed with one +1, two 0, and one -1 committer
> votes and three +1 non-committer votes.
>
> Committers:
>
> +1 Jukka Zitting
>
> 0 Stefan Guggisberg
> 0 Edgar Poce
>
> -1 Tobias Bocanegra
what's the reason for the -1? Please apologize if I might have
missed the explanation.
Thanks
Michi
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
Re: [RESULT] [VOTE] Revert the great split
Posted by Jukka Zitting <ju...@zitting.name>.
Hi,
Tobias Bocanegra wrote:
> oops, i think i wasn't clear enough. roy actually convinced me, that
> the current project structure only causes problems. so i change my
> vote to: '0'.
OK, thanks. I'll consider the vote passed and revert the split in one
commit and get back to the package renaming issue in a moment.
BR,
Jukka Zitting
Re: [RESULT] [VOTE] Revert the great split
Posted by Tobias Bocanegra <to...@day.com>.
:-)
oops, i think i wasn't clear enough. roy actually convinced me, that
the current project structure only causes problems. so i change my
vote to: '0'.
cheers, tobi
On 9/12/05, Jukka Zitting <jz...@yukatan.fi> wrote:
> Hi,
>
> The vote result is mixed with one +1, two 0, and one -1 committer votes
> and three +1 non-committer votes.
>
> Committers:
>
> +1 Jukka Zitting
>
> 0 Stefan Guggisberg
> 0 Edgar Poce
>
> -1 Tobias Bocanegra
>
> Non-committers:
>
> +1 Manu <ma...@dimano.sk>
> +1 Joseph Ottinger
> +1 Felix Meschberger
>
> The -1 vote is a veto and thus I will not make the proposed changes
> until more consensus is gained. I'll follow up on Tobias's repackaging
> proposal in hope of finding a compromise that everyone is happy with.
>
> BR,
>
> Jukka Zitting
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
[RESULT] [VOTE] Revert the great split
Posted by Jukka Zitting <jz...@yukatan.fi>.
Hi,
The vote result is mixed with one +1, two 0, and one -1 committer votes
and three +1 non-committer votes.
Committers:
+1 Jukka Zitting
0 Stefan Guggisberg
0 Edgar Poce
-1 Tobias Bocanegra
Non-committers:
+1 Manu <ma...@dimano.sk>
+1 Joseph Ottinger
+1 Felix Meschberger
The -1 vote is a veto and thus I will not make the proposed changes
until more consensus is gained. I'll follow up on Tobias's repackaging
proposal in hope of finding a compromise that everyone is happy with.
BR,
Jukka Zitting
Re: [VOTE] Revert the great split
Posted by Felix Meschberger <Fe...@day.com>.
Hi,
+1 Revert the JCR-157 changes
After long thoughts I came to the conclusion, that this would probably
be the best way to go and to have postgoals to produce the util (aka
commons) jar.
Regards
Felix
Re: [VOTE] Revert the great split
Posted by "Joseph B. Ottinger" <jo...@enigmastation.com>.
+1 on reverting the structure.
On Thu, 8 Sep 2005, Jukka Zitting wrote:
> Hi,
>
> As suggested by Tobias, I'd like to start a vote on whether to revert the
> "great split" proposed and implemented as issue JCR-157
> (http://issues.apache.org/jira/browse/JCR-157). I'm ready to undo the
> restructuring, but I'd like a clear consensus before doing that. So please
> vote on whether we should revert the split.
>
> [ ] +1 Revert the JCR-157 changes
> [ ] 0 Happy with either project structure
> [ ] -1 Do not revert the JCR-157 changes
>
> The vote is open until the end of this week. I'll close the vote and take
> actions accordingly on Monday the 12th.
>
> BR,
>
> Jukka Zitting
>
-----------------------------------------------------------------------
Joseph B. Ottinger http://enigmastation.com
Editor, http://www.TheServerSide.com joeo@enigmastation.com
Re: [VOTE] Revert the great split
Posted by Stefan Guggisberg <st...@gmail.com>.
[ ] +1 Revert the JCR-157 changes
[X] 0 Happy with either project structure
[ ] -1 Do not revert the JCR-157 changes
cheers
stefan
Re: [VOTE] Revert the great split
Posted by Tobias Bocanegra <to...@day.com>.
> [ ] -1 Do not revert the JCR-157 changes
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: [VOTE] Revert the great split
Posted by Marcel Reutegger <ma...@gmx.net>.
Tobias Bocanegra wrote:
> it seems, that the majority wants to switch back to the old structure.
> before moving the files, i suggest to think about the repackaging as
> suggested by roy.
>
> commons will go to: org.apache.jackrabbit.util.*
to me this change does not add any additional meaning to the package.
util says as much / little as commons. I suggest to mostly keep the
package naming for classes we currently have in commons. e.g. classes
that deal with values are in package value. This makes perfectly sense
to me, and I don't see why we should move all that to o.a.j.util.value.
Another discussion is how we name the artifact resulting from those
classes. jackrabbit-commons.jar or jackrabbit-util.jar, both are fine
with me.
> core will go to: org.apache.jackrabbit.jcr.*
I think this actually weakens the meaning of what this package contains,
since jackrabbit is per definition an implementation of jcr. The first
sentence on the jackrabbit site is: "The Jackrabbit Project has been
formed to develop an open source implementation of the Content
Repository for Java Technology API (JCR)..."
To me 'core' is currently as close as we can get to describe what the
packages are about. It's the core of jackrabbit, which implements the
JCR standard. But I'm always open to better names ;)
I know this is a weak argument, but still, there are numerous jakarta
projects that use core as a package name.
> api would go to: org.apache.jackrabbit.* but is currently empty.
>
> i'm not happy with the api packaging, but i can't come up with a
> better solution.
dito.
> please note, that the refactoring will break all existing
> configurations, since the class names (eg of the persistence managers)
> are referenced in the xmls. maybe we could provide a backward
> compatibility mapping in the config reader which logs a deprecation
> warning. on the other hand, 1.0 is not released yet, and we should not
> respect backward compatibility too much.
+1 to not care about backward compatibility at this point.
regards
marcel
Re: [VOTE] Revert the great split
Posted by Stefan Guggisberg <st...@gmail.com>.
On 9/12/05, Felix Meschberger <Fe...@day.com> wrote:
> Hi,
>
> >commons will go to: org.apache.jackrabbit.util.*
> >
> >
> Considering, what is now found in the commons library (name, util, uuid,
> value), I don't think those should be moved down the package hierarchy.
> In fact, these already are four distinct packages. The remaing classes
> in o.a.j, are not really "util" classes. They are rather common grounds,
> which IMHO is very well suited for o.a.j.
>
> BTW: BaseException does not sound very interesting - what is it a basis
> for anyway ? How about renaming it to JackrabbitException ?
BaseException is the the *base* class of all implementation specific
exceptions thrown by jr. i agree it's not a very significant name,
therefore i wouldn't object to renaming it to JackrabbitException
if the result would be considered worth the considerable refactoring
effort.
>
> BTW2: Is there are reason, why BaseException does not extend
> RepositoryException ?
to clearly distinguish between implementation specific (i.e. jackrabbit)
and api (i.e. jcr) exceptions. it my experience it helped a lot while
implementing the jcr interfaces.
cheers
stefan
>
> >core will go to: org.apache.jackrabbit.jcr.*
> >
> >
> Sounds good for me :-)
>
> >api would go to: org.apache.jackrabbit.* but is currently empty.
> >
> >i'm not happy with the api packaging, but i can't come up with a
> >better solution.
> >
> >
> As there is no defined Jackrabbit API yet and considering that this API
> will not be that big, I think we can currently live with that situation.
>
> >please note, that the refactoring will break all existing
> >configurations, since the class names (eg of the persistence managers)
> >are referenced in the xmls. maybe we could provide a backward
> >compatibility mapping in the config reader which logs a deprecation
> >warning. on the other hand, 1.0 is not released yet, and we should not
> >respect backward compatibility too much.
> >
> >
> I tend to agree with the last statement and not introduce deprecation
> and backward compatibility hacks in a not-yet-released product.
>
> Regards
> Felix
>
>
Re: [VOTE] Revert the great split
Posted by Felix Meschberger <Fe...@day.com>.
Hi,
>commons will go to: org.apache.jackrabbit.util.*
>
>
Considering, what is now found in the commons library (name, util, uuid,
value), I don't think those should be moved down the package hierarchy.
In fact, these already are four distinct packages. The remaing classes
in o.a.j, are not really "util" classes. They are rather common grounds,
which IMHO is very well suited for o.a.j.
BTW: BaseException does not sound very interesting - what is it a basis
for anyway ? How about renaming it to JackrabbitException ?
BTW2: Is there are reason, why BaseException does not extend
RepositoryException ?
>core will go to: org.apache.jackrabbit.jcr.*
>
>
Sounds good for me :-)
>api would go to: org.apache.jackrabbit.* but is currently empty.
>
>i'm not happy with the api packaging, but i can't come up with a
>better solution.
>
>
As there is no defined Jackrabbit API yet and considering that this API
will not be that big, I think we can currently live with that situation.
>please note, that the refactoring will break all existing
>configurations, since the class names (eg of the persistence managers)
>are referenced in the xmls. maybe we could provide a backward
>compatibility mapping in the config reader which logs a deprecation
>warning. on the other hand, 1.0 is not released yet, and we should not
>respect backward compatibility too much.
>
>
I tend to agree with the last statement and not introduce deprecation
and backward compatibility hacks in a not-yet-released product.
Regards
Felix
Re: [VOTE] Revert the great split
Posted by Tobias Bocanegra <to...@day.com>.
it seems, that the majority wants to switch back to the old structure.
before moving the files, i suggest to think about the repackaging as
suggested by roy.
commons will go to: org.apache.jackrabbit.util.*
core will go to: org.apache.jackrabbit.jcr.*
api would go to: org.apache.jackrabbit.* but is currently empty.
i'm not happy with the api packaging, but i can't come up with a
better solution.
please note, that the refactoring will break all existing
configurations, since the class names (eg of the persistence managers)
are referenced in the xmls. maybe we could provide a backward
compatibility mapping in the config reader which logs a deprecation
warning. on the other hand, 1.0 is not released yet, and we should not
respect backward compatibility too much.
--
tobi
On 9/8/05, Jukka Zitting <ju...@zitting.name> wrote:
> Hi,
>
> As suggested by Tobias, I'd like to start a vote on whether to revert
> the "great split" proposed and implemented as issue JCR-157
> (http://issues.apache.org/jira/browse/JCR-157). I'm ready to undo the
> restructuring, but I'd like a clear consensus before doing that. So
> please vote on whether we should revert the split.
>
> [ ] +1 Revert the JCR-157 changes
> [ ] 0 Happy with either project structure
> [ ] -1 Do not revert the JCR-157 changes
>
> The vote is open until the end of this week. I'll close the vote and
> take actions accordingly on Monday the 12th.
>
> BR,
>
> Jukka Zitting
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---