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 <[EMAIL PRO
On 5/7/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
as far as i can see eelco is complaining because he is doing that and no one
is following! :)
No, I have been complaining/ asking other team members in the past to
fix those projects as well because it's hardly any effort for the one
who is wo
On 5/7/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
thats nice of you eelco, but like i said i dont think this is our job. if a
project is broken for some period of time we should move it off trunk. let
the next person who wants to use it fix it. we dont need to fix the world.
I think that atti
as far as i can see eelco is complaining because he is doing that and no one
is following! :)
-igor
On 5/7/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> we dont need to fix the world.
but nobody should or would stop you if you did!
the world needs saving! Igor start doing this maybe the
we dont need to fix the world.
but nobody should or would stop you if you did!
the world needs saving! Igor start doing this maybe the rest will follow!
johan
thats nice of you eelco, but like i said i dont think this is our job. if a
project is broken for some period of time we should move it off trunk. let
the next person who wants to use it fix it. we dont need to fix the world.
-igor
On 5/7/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> if we
if we break the
api it is not our responsibility to fix it, it is the job of whoever is
responsible for that wicket-stuff project.
Technically, you are right. Practically you are not.
* To start with, It's just a matter of courtesy.
* It's much less work for the one doing the API break to fix o
In my opinion Wicket Stuff is used as a Wicket specific incubator for
projects that will end up in core. At least for projects that have
'use' as intent.
this is not always the case. it is also a project place when the license
doesn't work out.
So to say that it is an incubator for everything
On 5/6/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> However, that does impose some form of oversight, and given the
> current state of Wicket Stuff, I doubt that it will ever happen, if it
> doesn't come from us.
Exactly.
i dont think you got it right eelco. oversight!=maintenance. if we
i think what we should do is create a two-tier system where projects that
are alive are directly in trunk, while other projects are in a subdirectory
of trunk. projects can move between these two tiers as needed.
Perhaps a wicket-stuff-incubator?? ideas can be tried out in the
incubator module
However, that does impose some form of oversight, and given the
current state of Wicket Stuff, I doubt that it will ever happen, if it
doesn't come from us.
Exactly.
It is just hard to find people with a sustained
interest in maintaining a project and actively working on its
progress.
We hav
Perhaps we should write up some goals for Wicket Stuff.
In my opinion Wicket Stuff is used as a Wicket specific incubator for
projects that will end up in core. At least for projects that have
'use' as intent.
Projects within Wicket have different intentions:
- actual use (i.e. wicket, extension
well, thats exactly it - very little is required to do this, just an svn
move. we should establish procedures/guidelines for what it takes to move
from tier 2 to tier 1 and viceversa, and where new projects start out.
-igor
On 5/6/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> i think what w
i do not use the project. i do not have time, nor honestly the desire, to
fix every wicketstuff project i do not use. do you find that unfair?
Well you do have pretty strong opinions on the quality of the project
and the way it is 'managed'. And you seem to think something is wrong
with the proj
i think what we should do is create a two-tier system where projects that
are alive are directly in trunk, while other projects are in a subdirectory
of trunk. projects can move between these two tiers as needed.
It would be interesting to see someone actively maintaining that. So
far it's even
i do not use the project. i do not have time, nor honestly the desire, to
fix every wicketstuff project i do not use. do you find that unfair? as for
it being fixed on a version, do you think anyone would bump down their
hibernate version just for an auxilary project? i think not. maybe no one
rep
what defines a project as alive? at the least it works, not just compiles.
take data-hibernate 3. it compiles, but doesnt work because it hasnt been
synced with hibernate 3 changes.
It is fixed on a version in the POM, and to my knowledge it works with
that version!
if someone was to pick it u
i love the fact that wicketstuff is both a playground (very little entry
barrier for anyone) and that it serves as a repository for additional wicket
modules. the problem is when i look into trunk i see ten thousand projects.
some are dead, some are half dead, and others are alive. how am i suppos
I think it's simple. If the projects compile for a given branch, there
is no need to pull them out. And even if they don't compile for a
while - which didn't happen that much as I'm generally playing the
cleanup guy after API breaks -; as long as the Wicket branch they are
written for doesn't appr
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
On 5/6/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote:
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.
This was not a thread on what constitutes a wicket stuff project, but
now that you brought it up :)
In my vision, the
On 5/6/07, Eelco Hillenius <[EMAIL PROTECTED]> 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 fur
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 "p
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
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 "p
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
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.
wicket-contrib-data-hibernate2
Was already pulled out of trunk a very long time ago.
Eelco
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
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 <[EMAIL PROTE
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 act
move them to the attic.
-igor
On 5/6/07, Martijn Dashorst <[EMAIL PROTECTED]> 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-c
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
33 matches
Mail list logo
