On 5/7/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
...The problem is that we need to vote on those artifacts, and get
approval from the IPMC too. At least, that is my understanding
You're right, releasing additional stuff requires an IPMC vote.
I don't know enough about Maven to comme
On 5/7/07, James McLaughlin <[EMAIL PROTECTED]> wrote:
> Jim, if you're reading with us, would you be ok
> with granting us official permission?
Certainly, for this code and for any other snipplets i may have
contributed :)
For this to be official, do you already have an individual contribu
Jim, if you're reading with us, would you be ok
with granting us official permission?
Certainly, for this code and for any other snipplets i may have
contributed :)
best,
jim
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
On 5/7/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Current one sounds easier to me. Then we don't have to rush a new
release with a new vote etc.
The problem is that we need to vote on those artifacts, and get
approval from the IPMC too. At least, that is my understanding.
Given that the ar
an svn log shows the following entries that require further looking
into (first is by JBQ, on behalf of someone else, or with code by
someone else):
r970 | quenotj | 2006-10-12 01:51:44 -0700 (Thu, 12 Oct 2006) | 7 lines
Ad
Current one sounds easier to me. Then we don't have to rush a new
release with a new vote etc.
Eelco
On 5/7/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
Our release is a bit borked for maven users due to the fact that I
didn't deploy the jdk-1.4 and jdk-1.5 parent poms to the repository
(the
On 5/7/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
I'd like to create project wicket-velocity as a core project. It's a
rather simple project (5 classes) with just the extra Velocity
dependency. The main reason for wanting this project is that I heard
from several people using it and thinking
Our release is a bit borked for maven users due to the fact that I
didn't deploy the jdk-1.4 and jdk-1.5 parent poms to the repository
(the release profile explicitly excludes them). This is something that
needs to be fixed for future releases, and in my opinion for the
current release too.
We ca
I'd like to create project wicket-velocity as a core project. It's a
rather simple project (5 classes) with just the extra Velocity
dependency. The main reason for wanting this project is that I heard
from several people using it and thinking it's a useful project, and
I'd like it to go with our r
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
On 4.5.2007, at 14.23, Upayavira wrote:
So, do we want to propose graduation?
[x] Yes, propose Wicket for Graduation
[ ] No, Wicket is not ready to graduate
Please cast your votes.
Janne
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
On 5/4/07, Upayavira <[EMAIL PROTECTED]> wrote:
[x] Yes, propose Wicket for Graduation
Frank
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
36 matches
Mail list logo
