the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3

[Martijn Dashorst <ma...@gmail.com>]

All,

With the rise of databinder, what should we do with the hibernate
contrib projects? Are they maintained, or even necessary? Their last
release has been 1.0, and stems from 2005.

The projects:

wicket-contrib-data
wicket-contrib-data-hibernate2
wicket-contrib-data-hibernate-3.0

If there is no activity on these projects, I'd like to disable their
releases on sourceforge, and move the subversion modules to an attic.
Having the releases available drives people in the wrong direction
IMO. Databinder is actively maintained and provides the best direct
hibernate integration.

Martijn

-- 
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6 contains a very important fix. Download Wicket now!
http://wicketframework.org

Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3

[Eelco Hillenius <ee...@gmail.com>]

> wicket-contrib-data-hibernate2

Was already pulled out of trunk a very long time ago.

Eelco

Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3

[Martijn Dashorst <ma...@gmail.com>]

Not having a good internet connection will create a huge backlog for
messages never sent... grmbl

I also got a ping from a coworker of Al Maw where these projects went:
this means there is genuine interest in them (apart from the downloads
mentioned below).

On 5/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
> I also didn't see the point of why releases have
> to be disabled or code that compiles and at least does something has
> to be moved.

These particular releases imply that the code is unmaintained and left
to die. If someone does download these releases and tries to get them
to work with the current Wicket code base, then they are in for a
nasty surprise. The code in SVN doesn't have that problem. So
disabling the releases will decrease the visibility, but will also
remove the idea that they are no longer maintained. [1]

These projects clearly are maintained, and should be used as examples
from what I hear from you. Therefore I think the best value for these
projects and your effort invested in them is in having a source
distribution release available for download (based on 1.3 code), and
not the currently, obsolete binary release for download.

I would also consider adding a small page to the wiki explaining the
intent and how/what to do with the projects.

> > why not take a step back and
> > see why we actually have these projects?
>
> At the very least they were examples that people could check out and
> take a look at.

I have no problem with that. But it was not clear to me, and I would
guess not for other users.

> It's 1.0 based as the version implies. If that isn't clear, then we
> could look at that further.

I would suggest disabling the downloads: they are not of any
particular use at the moment, other than making the stuff visible to
casual browsing users. They are dangerous in that they (the downloads)
won't work with the current state of Wicket.

The usage of the projects look like they are actively downloaded: [2]

So let's either update these projects and release new binaries or
remove the binaries and keep it in svn. I have a slight preference for
the former: releases make things nice and explicit and gives people
something solid to build on.

Martijn

[1] http://faler.wordpress.com/2007/05/28/all-the-wicket-components-you-could-ever-wish-for/

[2] http://sourceforge.net/project/stats/detail.php?group_id=134391&ugn=wicket-stuff&type=prdownload&mode=alltime&package_id=149074&release_id=0

-- 
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6 contains a very important fix. Download Wicket now!
http://wicketframework.org

Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3

[Eelco Hillenius <ee...@gmail.com>]

> Instead of all people reacting furiously,

It's the third time or so in a couple of months I have to 'defend'
those projects. And looking up the history would have revealed that
the last commits weren't that long ago, and that the projects compiled
up to two days ago. I also didn't see the point of why releases have
to be disabled or code that compiles and at least does something has
to be moved.

> why not take a step back and
> see why we actually have these projects?

At the very least they were examples that people could check out and
take a look at.

> The contrib-data projects seemed dead to me. Consider me mistaken in
> that regard.

Fair enough.

> In my defense:
>  - the projects didn't have a release since 2005
>  - there are no wiki pages for the projects
>  - there is an actively maintained external project with similar scope

But the basic thing, the code, is at least maintained for API updates.
With the last updates a couple of weeks ago.

> I don't want them removed as you state you are maintaining them, but I
> would like there to be some form of documentation or other form of
> information as to the purpose and intent of these projects. Having a
> downloadable release on sf.net that is obsolete (wicket 1.0? based)
> seems worse than not having them available and the projects only
> accessible from svn as that seems to be the intent of the projects.

It's 1.0 based as the version implies. If that isn't clear, then we
could look at that further.

> As hibernate is lgpl, this project would never (read: until legal@
> decides otherwise) be acceptable in core.

Those projects were started long time before Apache even came in
sight, and there are Apache projects that have Hibernate as a
dependency. But it's not relevant as I never intended those projects
to go beyond the scope of simple wicket-stuff projects to start with.

Eelco

Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3

[Martijn Dashorst <ma...@gmail.com>]

On 5/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
> Well, then someone would complain wouldn't they? You know what, I'm
> sick of this and deleted the projects, including the
> wicket-stuff-examples, which was another one of these projects only
> maintained by me.

Instead of all people reacting furiously, why not take a step back and
see why we actually have these projects?

The contrib-data projects seemed dead to me. Consider me mistaken in
that regard. In my defense:
 - the projects didn't have a release since 2005
 - there are no wiki pages for the projects
 - there is an actively maintained external project with similar scope

I don't want them removed as you state you are maintaining them, but I
would like there to be some form of documentation or other form of
information as to the purpose and intent of these projects. Having a
downloadable release on sf.net that is obsolete (wicket 1.0? based)
seems worse than not having them available and the projects only
accessible from svn as that seems to be the intent of the projects.

As hibernate is lgpl, this project would never (read: until legal@
decides otherwise) be acceptable in core.

Martijn

-- 
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6 contains a very important fix. Download Wicket now!
http://wicketframework.org

Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3

[Eelco Hillenius <ee...@gmail.com>]

> As a wicket-stuff developer, I for one would hate to see restrictions
> placed on what can or can not be a wicket-stuff project.  The beauty
> of the wicket-stuff idea is that it is a playground for people try out
> potentially cool ideas.  It's a place for people to learn how to use
> wicket and build "possibly" cool widgets and tools.
>
> I know that *my* project (wicketstuff-scriptaculous) has occasionally
> been left "in the dark" for several months before a whole slew of
> changes and features get built in.
>
> Sure, there may be a "better" wicket/hibernate project out there (aka:
> databinder), but I really don't see any issues with that.  Especially
> now that there's a wicket-stuff wiki, it can be clearly spelled out
> there what each project's strengths/weaknesses are.

Yes, I completely agree with that. It's in fact what we've been
advertising wicket-stuff is about.

Anyway, I've deleted wicket-contrib-data,
wicket-contrib-data-hibernate3 and wicket-contrib-examples. I'm
working on moving the Velocity project to core. The license is
compatible, I've heard from various people using it, and in this way I
can move the example to the wicket-examples project.

Eelco

Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3

[Ryan Sonnek <ry...@gmail.com>]

As a wicket-stuff developer, I for one would hate to see restrictions
placed on what can or can not be a wicket-stuff project.  The beauty
of the wicket-stuff idea is that it is a playground for people try out
potentially cool ideas.  It's a place for people to learn how to use
wicket and build "possibly" cool widgets and tools.

I know that *my* project (wicketstuff-scriptaculous) has occasionally
been left "in the dark" for several months before a whole slew of
changes and features get built in.

Sure, there may be a "better" wicket/hibernate project out there (aka:
databinder), but I really don't see any issues with that.  Especially
now that there's a wicket-stuff wiki, it can be clearly spelled out
there what each project's strengths/weaknesses are.

On 5/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
> Well, then someone would complain wouldn't they? You know what, I'm
> sick of this and deleted the projects, including the
> wicket-stuff-examples, which was another one of these projects only
> maintained by me.
>
> As you brought this up Martijn, please do a review of the other
> wicket-stuff projects that are *possibly* not actively 'maintained'
> (wicket-database, datepicker, gmap?). Let's do the cleanup properly
> then.
>
> Eelco
>
> On 5/6/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > well, yes it does matter. there is a difference between a project and a
> > bunch of compiling code. for example that project will break if anyone tries
> > to use it with hibernate 3.2 because it hasnt been updated to their switch
> > of aggregate return types form int to long. who knows what else is broken.
> > this project needs to be maintained from both ends: wicket and hibernate.
> > and you are only doing it form one end.
> >
> > -igor
> >
> >
> > On 5/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > > you _maintain_ them as far as keeping api with wicket in sync. but do
> > > you
> > > > actively develop them? do they provide any value in their current state?
> > > are
> > > > they up to the latest hibernate version?
> > >
> > > Huh? Does it matter for this project more than other wicket-stuff
> > > projects? Does it matter what release of Hibernate it's on? Don't you
> > > have more important things to do than to bith about wicket-stuff
> > > projects that I say I take responsibility for?
> > >
> > > > imho those projects never got finished, not even close.
> > >
> > > The great motivator speaks again.
> > >
> > > Eelco
> > >
> >
>

Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3

[Eelco Hillenius <ee...@gmail.com>]

Well, then someone would complain wouldn't they? You know what, I'm
sick of this and deleted the projects, including the
wicket-stuff-examples, which was another one of these projects only
maintained by me.

As you brought this up Martijn, please do a review of the other
wicket-stuff projects that are *possibly* not actively 'maintained'
(wicket-database, datepicker, gmap?). Let's do the cleanup properly
then.

Eelco

On 5/6/07, Igor Vaynberg <ig...@gmail.com> wrote:
> well, yes it does matter. there is a difference between a project and a
> bunch of compiling code. for example that project will break if anyone tries
> to use it with hibernate 3.2 because it hasnt been updated to their switch
> of aggregate return types form int to long. who knows what else is broken.
> this project needs to be maintained from both ends: wicket and hibernate.
> and you are only doing it form one end.
>
> -igor
>
>
> On 5/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > > you _maintain_ them as far as keeping api with wicket in sync. but do
> > you
> > > actively develop them? do they provide any value in their current state?
> > are
> > > they up to the latest hibernate version?
> >
> > Huh? Does it matter for this project more than other wicket-stuff
> > projects? Does it matter what release of Hibernate it's on? Don't you
> > have more important things to do than to bith about wicket-stuff
> > projects that I say I take responsibility for?
> >
> > > imho those projects never got finished, not even close.
> >
> > The great motivator speaks again.
> >
> > Eelco
> >
>

Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3

[Igor Vaynberg <ig...@gmail.com>]

well, yes it does matter. there is a difference between a project and a
bunch of compiling code. for example that project will break if anyone tries
to use it with hibernate 3.2 because it hasnt been updated to their switch
of aggregate return types form int to long. who knows what else is broken.
this project needs to be maintained from both ends: wicket and hibernate.
and you are only doing it form one end.

-igor


On 5/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > you _maintain_ them as far as keeping api with wicket in sync. but do
> you
> > actively develop them? do they provide any value in their current state?
> are
> > they up to the latest hibernate version?
>
> Huh? Does it matter for this project more than other wicket-stuff
> projects? Does it matter what release of Hibernate it's on? Don't you
> have more important things to do than to bith about wicket-stuff
> projects that I say I take responsibility for?
>
> > imho those projects never got finished, not even close.
>
> The great motivator speaks again.
>
> Eelco
>

Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3

[Eelco Hillenius <ee...@gmail.com>]

> you _maintain_ them as far as keeping api with wicket in sync. but do you
> actively develop them? do they provide any value in their current state? are
> they up to the latest hibernate version?

Huh? Does it matter for this project more than other wicket-stuff
projects? Does it matter what release of Hibernate it's on? Don't you
have more important things to do than to bith about wicket-stuff
projects that I say I take responsibility for?

> imho those projects never got finished, not even close.

The great motivator speaks again.

Eelco

Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3

[Eelco Hillenius <ee...@gmail.com>]

> imho those projects never got finished, not even close.

Well, it pretty much does what I had in mind. From the start, this
project was just to give people an idea how they could work with
Hibernate and Wicket and just get something started up. But as basic
as it is, it can be (and is, as I know one project that does) used for
projects. I always kept it as a wicket-stuff project rather then a
core project because I didn't want to grow it, certainly not after
Databinder was created.

Eelco

Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3

[Igor Vaynberg <ig...@gmail.com>]

you _maintain_ them as far as keeping api with wicket in sync. but do you
actively develop them? do they provide any value in their current state? are
they up to the latest hibernate version?

imho those projects never got finished, not even close.

-igor


On 5/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > With the rise of databinder, what should we do with the hibernate
> > contrib projects? Are they maintained, or even necessary? Their last
> > release has been 1.0, and stems from 2005.
> >
> > The projects:
> >
> > wicket-contrib-data
> > wicket-contrib-data-hibernate2
> > wicket-contrib-data-hibernate-3.0
> >
> > If there is no activity on these projects, I'd like to disable their
> > releases on sourceforge, and move the subversion modules to an attic.
> > Having the releases available drives people in the wrong direction
> > IMO. Databinder is actively maintained and provides the best direct
> > hibernate integration.
>
> Why does this have to come up every few months? They *are* maintained
> in that they are kept in check with the changes. Please look at the
> commit logs. I don't even know why you have to bring this up, as I've
> been the only one feeling the pain of maintaining them.
>
> So, please for once and for all: no, we're not gonna delete them. I'll
> decide when I've had enough of maintaining them, and I might decide to
> put a warning somewhere that databinder is a lot better (which is an
> assumption I didn't even check).
>
> Eelco
>

Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3

[Eelco Hillenius <ee...@gmail.com>]

> With the rise of databinder, what should we do with the hibernate
> contrib projects? Are they maintained, or even necessary? Their last
> release has been 1.0, and stems from 2005.
>
> The projects:
>
> wicket-contrib-data
> wicket-contrib-data-hibernate2
> wicket-contrib-data-hibernate-3.0
>
> If there is no activity on these projects, I'd like to disable their
> releases on sourceforge, and move the subversion modules to an attic.
> Having the releases available drives people in the wrong direction
> IMO. Databinder is actively maintained and provides the best direct
> hibernate integration.

Why does this have to come up every few months? They *are* maintained
in that they are kept in check with the changes. Please look at the
commit logs. I don't even know why you have to bring this up, as I've
been the only one feeling the pain of maintaining them.

So, please for once and for all: no, we're not gonna delete them. I'll
decide when I've had enough of maintaining them, and I might decide to
put a warning somewhere that databinder is a lot better (which is an
assumption I didn't even check).

Eelco

Re: the future of wicket-contrib-hibernate2 and wicket-contrib-hibernate3

[Igor Vaynberg <ig...@gmail.com>]

move them to the attic.

-igor


On 5/6/07, Martijn Dashorst <ma...@gmail.com> wrote:
>
> All,
>
> With the rise of databinder, what should we do with the hibernate
> contrib projects? Are they maintained, or even necessary? Their last
> release has been 1.0, and stems from 2005.
>
> The projects:
>
> wicket-contrib-data
> wicket-contrib-data-hibernate2
> wicket-contrib-data-hibernate-3.0
>
> If there is no activity on these projects, I'd like to disable their
> releases on sourceforge, and move the subversion modules to an attic.
> Having the releases available drives people in the wrong direction
> IMO. Databinder is actively maintained and provides the best direct
> hibernate integration.
>
> Martijn
>
> --
> Learn Wicket at ApacheCon Europe: http://apachecon.com
> Join the wicket community at irc.freenode.net: ##wicket
> Wicket 1.2.6 contains a very important fix. Download Wicket now!
> http://wicketframework.org
>