You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Martijn Dashorst <ma...@gmail.com> on 2010/04/19 17:31:45 UTC
Future of wicketstuff.org
Currently we have a maintenance nightmare. Keeping up confluence,
jira, teamcity and the maven repo is cumbersome at best. We keep
running out of diskspace (/var has reached -300M disk free, yes minus
300M).
So I propose the following:
- use Apache's build grid for Wicket code, Apache repository for
staging and snapshot releases: separating the Apache Wicket projects
from Wicket Stuff projects
- no more custom, self hosted products a la confluence and jira (no
matter how much we like them)
- use wicketstuff.org only for running examples and a build server
for wicket stuff projects
- use sonatype's OSS repo hosting for our snapshots, release staging
and releases (no more wicketstuff.org/repository/maven)
Most importantly:
- vote on the future of the hosting of Wicket Stuff:
[ ] stay with sf.net
[ ] move to github
- if we stay on sf.net: use the sf.net provided tools to manage the
project: issues, wiki and website
- if we stay to move to github: use github's provided tools to manage
the project: issues, wiki and website
Martijn
Re: Future of wicketstuff.org
Posted by Michael O'Cleirigh <mi...@rivulet.ca>.
Hello,
The main feature I like about wicketstuff is that its easy for
developers to add in code that is automatically built and deployed into
maven. It allows an easy way to reactor a project to extract certain
reusable functionality, externalize it for others to use, and still be
able to build the originating project reliably.
+1 for using wicketstuff.org for the example applications and the build
server and removing jira and confluence, etc for presupplied low
maintenance options.
I want to help find a solution to the current team city <-> source forge
build problems. I want to look at changing build servers before
considering switching the repository from sf to github. (vote: [X] stay
with sf.net).
I'm not sure how much resources are required to build wicketstuff but I
plan on starting with an old Linux box at work (P4 single core 1.8
Ghz). I want to start with hudson and see if I can keep it unbanned
while running the same high frequency updates.
The other part is getting accounts setup through sonatype to let the
maven artifacts be deployed. This requires an issue being filed into
the sonatype JIRA.
I could start with creating the JIRA issue for me first then if I can
get it to work or others want to help we get the additional users added.
My thinking is that I could test this stuff out separately and if it
works then wicketstuff.org could be switched over.
If anyone thinks it would be a bad idea (or if there are other
considerations I don't seem to be aware of) for me to file the JIRA
request let me know otherwise I'll plan on getting started on this stuff
next week.
Regards,
Mike
> http://hudson.zones.apache.org/hudson/job/Apache%20Wicket%201.5.x/
>
> On Sun, Apr 25, 2010 at 11:16 PM, Martijn Dashorst
> <ma...@gmail.com> wrote:
>
>> I've requested hudson access to build our Apache Wicket core projects
>> on the Apache hudson grid.
>>
>> Martijn
>>
>> On Mon, Apr 19, 2010 at 5:31 PM, Martijn Dashorst
>> <ma...@gmail.com> wrote:
>>
>>> Currently we have a maintenance nightmare. Keeping up confluence,
>>> jira, teamcity and the maven repo is cumbersome at best. We keep
>>> running out of diskspace (/var has reached -300M disk free, yes minus
>>> 300M).
>>>
>>> So I propose the following:
>>> - use Apache's build grid for Wicket code, Apache repository for
>>> staging and snapshot releases: separating the Apache Wicket projects
>>> from Wicket Stuff projects
>>> - no more custom, self hosted products a la confluence and jira (no
>>> matter how much we like them)
>>> - use wicketstuff.org only for running examples and a build server
>>> for wicket stuff projects
>>> - use sonatype's OSS repo hosting for our snapshots, release staging
>>> and releases (no more wicketstuff.org/repository/maven)
>>>
>>> Most importantly:
>>> - vote on the future of the hosting of Wicket Stuff:
>>> [ ] stay with sf.net
>>> [ ] move to github
>>> - if we stay on sf.net: use the sf.net provided tools to manage the
>>> project: issues, wiki and website
>>> - if we stay to move to github: use github's provided tools to manage
>>> the project: issues, wiki and website
>>>
>>> Martijn
>>>
>>>
>>
>> --
>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>> Apache Wicket 1.4 increases type safety for web applications
>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.7
>>
>>
>
>
>
>
Re: Future of wicketstuff.org
Posted by Martijn Dashorst <ma...@gmail.com>.
http://hudson.zones.apache.org/hudson/job/Apache%20Wicket%201.5.x/
On Sun, Apr 25, 2010 at 11:16 PM, Martijn Dashorst
<ma...@gmail.com> wrote:
> I've requested hudson access to build our Apache Wicket core projects
> on the Apache hudson grid.
>
> Martijn
>
> On Mon, Apr 19, 2010 at 5:31 PM, Martijn Dashorst
> <ma...@gmail.com> wrote:
>> Currently we have a maintenance nightmare. Keeping up confluence,
>> jira, teamcity and the maven repo is cumbersome at best. We keep
>> running out of diskspace (/var has reached -300M disk free, yes minus
>> 300M).
>>
>> So I propose the following:
>> - use Apache's build grid for Wicket code, Apache repository for
>> staging and snapshot releases: separating the Apache Wicket projects
>> from Wicket Stuff projects
>> - no more custom, self hosted products a la confluence and jira (no
>> matter how much we like them)
>> - use wicketstuff.org only for running examples and a build server
>> for wicket stuff projects
>> - use sonatype's OSS repo hosting for our snapshots, release staging
>> and releases (no more wicketstuff.org/repository/maven)
>>
>> Most importantly:
>> - vote on the future of the hosting of Wicket Stuff:
>> [ ] stay with sf.net
>> [ ] move to github
>> - if we stay on sf.net: use the sf.net provided tools to manage the
>> project: issues, wiki and website
>> - if we stay to move to github: use github's provided tools to manage
>> the project: issues, wiki and website
>>
>> Martijn
>>
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.4 increases type safety for web applications
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.7
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.7
Re: Future of wicketstuff.org
Posted by Martijn Dashorst <ma...@gmail.com>.
I've requested hudson access to build our Apache Wicket core projects
on the Apache hudson grid.
Martijn
On Mon, Apr 19, 2010 at 5:31 PM, Martijn Dashorst
<ma...@gmail.com> wrote:
> Currently we have a maintenance nightmare. Keeping up confluence,
> jira, teamcity and the maven repo is cumbersome at best. We keep
> running out of diskspace (/var has reached -300M disk free, yes minus
> 300M).
>
> So I propose the following:
> - use Apache's build grid for Wicket code, Apache repository for
> staging and snapshot releases: separating the Apache Wicket projects
> from Wicket Stuff projects
> - no more custom, self hosted products a la confluence and jira (no
> matter how much we like them)
> - use wicketstuff.org only for running examples and a build server
> for wicket stuff projects
> - use sonatype's OSS repo hosting for our snapshots, release staging
> and releases (no more wicketstuff.org/repository/maven)
>
> Most importantly:
> - vote on the future of the hosting of Wicket Stuff:
> [ ] stay with sf.net
> [ ] move to github
> - if we stay on sf.net: use the sf.net provided tools to manage the
> project: issues, wiki and website
> - if we stay to move to github: use github's provided tools to manage
> the project: issues, wiki and website
>
> Martijn
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.7
Re: Future of wicketstuff.org
Posted by nino martinez wael <ni...@gmail.com>.
I'd say either move to googlecode (http://code.google.com/p/wicketstuff/) :
or
[X] stay with sf.net
But we will still need a building server. I'd hate to see wicketstuff die.
2010/4/19 Pointbreak <po...@ml1.net>:
> I would think that an eventual move to github is unrelated to any of the
> maintenance problems you describe. Therefore I would say keep it is
> simple as possible and stay with sourceforge when executing the proposed
> tags. As moving to a github (and a distributed VCS) will introduce its
> own problems, paradigm shifts, tool incompatibilities and general
> misunderstandings. Whether or not such a move would be beneficial or not
> should be a separate discussion, that is unrelated to the problems you
> are trying to solve in your proposal.
>
> [X] stay with sf.net
> [ ] move to github
>
>
> On Mon, 19 Apr 2010 17:31 +0200, "Martijn Dashorst"
> <ma...@gmail.com> wrote:
>> Currently we have a maintenance nightmare. Keeping up confluence,
>> jira, teamcity and the maven repo is cumbersome at best. We keep
>> running out of diskspace (/var has reached -300M disk free, yes minus
>> 300M).
>>
>> So I propose the following:
>> - use Apache's build grid for Wicket code, Apache repository for
>> staging and snapshot releases: separating the Apache Wicket projects
>> from Wicket Stuff projects
>> - no more custom, self hosted products a la confluence and jira (no
>> matter how much we like them)
>> - use wicketstuff.org only for running examples and a build server
>> for wicket stuff projects
>> - use sonatype's OSS repo hosting for our snapshots, release staging
>> and releases (no more wicketstuff.org/repository/maven)
>>
>> Most importantly:
>> - vote on the future of the hosting of Wicket Stuff:
>> [ ] stay with sf.net
>> [ ] move to github
>> - if we stay on sf.net: use the sf.net provided tools to manage the
>> project: issues, wiki and website
>> - if we stay to move to github: use github's provided tools to manage
>> the project: issues, wiki and website
>>
>> Martijn
>>
>
Re: Future of wicketstuff.org
Posted by Pointbreak <po...@ml1.net>.
I am aware of these problems, in fact I started a discussion about them
in 2008. Somebody else provided a continuum build server back than
(Jeremy Thomson?), that had none of these problems. The specific
exceptions thrown by teamcity show up on google searches with other SVN
servers as well.
What I was trying to say is that, since you are moving to other
buildservers in your proposal, that will more than likely solve the
sf<->teamcity problem. Moving to github may be a good thing, but is
really not related to the problems you described, and I do not see any
reason to couple the decision of a move to github to the other proposals
you make for the build environment.
But yes github is nice, seems to be well received, and I haven't touched
wicketstuff in over a year, so feel free to ignore this rant.
On Mon, 19 Apr 2010 21:13 +0200, "Martijn Dashorst"
<ma...@gmail.com> wrote:
> Unless you haven't read the lists last couple of weeks, there have
> been numerous problems letting our build server connect to sf.net's
> servers. In the past the service of sf.net was abysmal (but we haven't
> used their stuff for a while, so it may have improved).
>
> Moving to greener pastures most certainly is related to these
> problems: we don't have the time to manage the server properly. We
> don't have the time to ensure timely upgrades of the software, we
> don't have the time to investigate what is messing up our buildserver
> (is it teamcity, sf.net, our polling schedule?).
>
> Moving to github may not solve these problems or introduce new ones,
> but it provides some really nice infrastructure, together with the
> best SCM currently available (Hg could also classify as best, I hear).
>
> Github solves: wiki, site, tracker, scm (post commit hooks!). No more
> confluence/jira to maintain... now that would be a boon!
>
> Martijn
>
> On Mon, Apr 19, 2010 at 5:49 PM, Pointbreak
> <po...@ml1.net> wrote:
> > I would think that an eventual move to github is unrelated to any of the
> > maintenance problems you describe. Therefore I would say keep it is
> > simple as possible and stay with sourceforge when executing the proposed
> > tags. As moving to a github (and a distributed VCS) will introduce its
> > own problems, paradigm shifts, tool incompatibilities and general
> > misunderstandings. Whether or not such a move would be beneficial or not
> > should be a separate discussion, that is unrelated to the problems you
> > are trying to solve in your proposal.
> >
> > [X] stay with sf.net
> > [ ] move to github
> >
> >
> > On Mon, 19 Apr 2010 17:31 +0200, "Martijn Dashorst"
> > <ma...@gmail.com> wrote:
> >> Currently we have a maintenance nightmare. Keeping up confluence,
> >> jira, teamcity and the maven repo is cumbersome at best. We keep
> >> running out of diskspace (/var has reached -300M disk free, yes minus
> >> 300M).
> >>
> >> So I propose the following:
> >> - use Apache's build grid for Wicket code, Apache repository for
> >> staging and snapshot releases: separating the Apache Wicket projects
> >> from Wicket Stuff projects
> >> - no more custom, self hosted products a la confluence and jira (no
> >> matter how much we like them)
> >> - use wicketstuff.org only for running examples and a build server
> >> for wicket stuff projects
> >> - use sonatype's OSS repo hosting for our snapshots, release staging
> >> and releases (no more wicketstuff.org/repository/maven)
> >>
> >> Most importantly:
> >> - vote on the future of the hosting of Wicket Stuff:
> >> [ ] stay with sf.net
> >> [ ] move to github
> >> - if we stay on sf.net: use the sf.net provided tools to manage the
> >> project: issues, wiki and website
> >> - if we stay to move to github: use github's provided tools to manage
> >> the project: issues, wiki and website
> >>
> >> Martijn
> >>
> >
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.4 increases type safety for web applications
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4
>
Re: Future of wicketstuff.org
Posted by Johan Compagner <jc...@gmail.com>.
Don't know about the tooling of git not in eclipse
i am monitoring it a bit, but as long as that is not the same as SVN (or
better cvs) i will not use it.
That sf.net outage is already there since pretty much day 1..
Then it works then it doesnt. very weird.
For example wicket-security-1.4 did work fine on 16 of april....
On Mon, Apr 19, 2010 at 21:13, Martijn Dashorst
<ma...@gmail.com>wrote:
> Unless you haven't read the lists last couple of weeks, there have
> been numerous problems letting our build server connect to sf.net's
> servers. In the past the service of sf.net was abysmal (but we haven't
> used their stuff for a while, so it may have improved).
>
> Moving to greener pastures most certainly is related to these
> problems: we don't have the time to manage the server properly. We
> don't have the time to ensure timely upgrades of the software, we
> don't have the time to investigate what is messing up our buildserver
> (is it teamcity, sf.net, our polling schedule?).
>
> Moving to github may not solve these problems or introduce new ones,
> but it provides some really nice infrastructure, together with the
> best SCM currently available (Hg could also classify as best, I hear).
>
> Github solves: wiki, site, tracker, scm (post commit hooks!). No more
> confluence/jira to maintain... now that would be a boon!
>
> Martijn
>
> On Mon, Apr 19, 2010 at 5:49 PM, Pointbreak
> <pointbreak+wicketstuff@ml1.net <po...@ml1.net>> wrote:
> > I would think that an eventual move to github is unrelated to any of the
> > maintenance problems you describe. Therefore I would say keep it is
> > simple as possible and stay with sourceforge when executing the proposed
> > tags. As moving to a github (and a distributed VCS) will introduce its
> > own problems, paradigm shifts, tool incompatibilities and general
> > misunderstandings. Whether or not such a move would be beneficial or not
> > should be a separate discussion, that is unrelated to the problems you
> > are trying to solve in your proposal.
> >
> > [X] stay with sf.net
> > [ ] move to github
> >
> >
> > On Mon, 19 Apr 2010 17:31 +0200, "Martijn Dashorst"
> > <ma...@gmail.com> wrote:
> >> Currently we have a maintenance nightmare. Keeping up confluence,
> >> jira, teamcity and the maven repo is cumbersome at best. We keep
> >> running out of diskspace (/var has reached -300M disk free, yes minus
> >> 300M).
> >>
> >> So I propose the following:
> >> - use Apache's build grid for Wicket code, Apache repository for
> >> staging and snapshot releases: separating the Apache Wicket projects
> >> from Wicket Stuff projects
> >> - no more custom, self hosted products a la confluence and jira (no
> >> matter how much we like them)
> >> - use wicketstuff.org only for running examples and a build server
> >> for wicket stuff projects
> >> - use sonatype's OSS repo hosting for our snapshots, release staging
> >> and releases (no more wicketstuff.org/repository/maven)
> >>
> >> Most importantly:
> >> - vote on the future of the hosting of Wicket Stuff:
> >> [ ] stay with sf.net
> >> [ ] move to github
> >> - if we stay on sf.net: use the sf.net provided tools to manage the
> >> project: issues, wiki and website
> >> - if we stay to move to github: use github's provided tools to manage
> >> the project: issues, wiki and website
> >>
> >> Martijn
> >>
> >
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.4 increases type safety for web applications
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4
>
Re: Future of wicketstuff.org
Posted by Martijn Dashorst <ma...@gmail.com>.
Unless you haven't read the lists last couple of weeks, there have
been numerous problems letting our build server connect to sf.net's
servers. In the past the service of sf.net was abysmal (but we haven't
used their stuff for a while, so it may have improved).
Moving to greener pastures most certainly is related to these
problems: we don't have the time to manage the server properly. We
don't have the time to ensure timely upgrades of the software, we
don't have the time to investigate what is messing up our buildserver
(is it teamcity, sf.net, our polling schedule?).
Moving to github may not solve these problems or introduce new ones,
but it provides some really nice infrastructure, together with the
best SCM currently available (Hg could also classify as best, I hear).
Github solves: wiki, site, tracker, scm (post commit hooks!). No more
confluence/jira to maintain... now that would be a boon!
Martijn
On Mon, Apr 19, 2010 at 5:49 PM, Pointbreak
<po...@ml1.net> wrote:
> I would think that an eventual move to github is unrelated to any of the
> maintenance problems you describe. Therefore I would say keep it is
> simple as possible and stay with sourceforge when executing the proposed
> tags. As moving to a github (and a distributed VCS) will introduce its
> own problems, paradigm shifts, tool incompatibilities and general
> misunderstandings. Whether or not such a move would be beneficial or not
> should be a separate discussion, that is unrelated to the problems you
> are trying to solve in your proposal.
>
> [X] stay with sf.net
> [ ] move to github
>
>
> On Mon, 19 Apr 2010 17:31 +0200, "Martijn Dashorst"
> <ma...@gmail.com> wrote:
>> Currently we have a maintenance nightmare. Keeping up confluence,
>> jira, teamcity and the maven repo is cumbersome at best. We keep
>> running out of diskspace (/var has reached -300M disk free, yes minus
>> 300M).
>>
>> So I propose the following:
>> - use Apache's build grid for Wicket code, Apache repository for
>> staging and snapshot releases: separating the Apache Wicket projects
>> from Wicket Stuff projects
>> - no more custom, self hosted products a la confluence and jira (no
>> matter how much we like them)
>> - use wicketstuff.org only for running examples and a build server
>> for wicket stuff projects
>> - use sonatype's OSS repo hosting for our snapshots, release staging
>> and releases (no more wicketstuff.org/repository/maven)
>>
>> Most importantly:
>> - vote on the future of the hosting of Wicket Stuff:
>> [ ] stay with sf.net
>> [ ] move to github
>> - if we stay on sf.net: use the sf.net provided tools to manage the
>> project: issues, wiki and website
>> - if we stay to move to github: use github's provided tools to manage
>> the project: issues, wiki and website
>>
>> Martijn
>>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4
Re: Future of wicketstuff.org
Posted by Pointbreak <po...@ml1.net>.
I would think that an eventual move to github is unrelated to any of the
maintenance problems you describe. Therefore I would say keep it is
simple as possible and stay with sourceforge when executing the proposed
tags. As moving to a github (and a distributed VCS) will introduce its
own problems, paradigm shifts, tool incompatibilities and general
misunderstandings. Whether or not such a move would be beneficial or not
should be a separate discussion, that is unrelated to the problems you
are trying to solve in your proposal.
[X] stay with sf.net
[ ] move to github
On Mon, 19 Apr 2010 17:31 +0200, "Martijn Dashorst"
<ma...@gmail.com> wrote:
> Currently we have a maintenance nightmare. Keeping up confluence,
> jira, teamcity and the maven repo is cumbersome at best. We keep
> running out of diskspace (/var has reached -300M disk free, yes minus
> 300M).
>
> So I propose the following:
> - use Apache's build grid for Wicket code, Apache repository for
> staging and snapshot releases: separating the Apache Wicket projects
> from Wicket Stuff projects
> - no more custom, self hosted products a la confluence and jira (no
> matter how much we like them)
> - use wicketstuff.org only for running examples and a build server
> for wicket stuff projects
> - use sonatype's OSS repo hosting for our snapshots, release staging
> and releases (no more wicketstuff.org/repository/maven)
>
> Most importantly:
> - vote on the future of the hosting of Wicket Stuff:
> [ ] stay with sf.net
> [ ] move to github
> - if we stay on sf.net: use the sf.net provided tools to manage the
> project: issues, wiki and website
> - if we stay to move to github: use github's provided tools to manage
> the project: issues, wiki and website
>
> Martijn
>
Re: Future of wicketstuff.org
Posted by Major Péter <ma...@sch.bme.hu>.
A few weeks ago I cleaned up the userspaces in wicketstuff (with help of
Nino), hopefully no SPAM were left after that...
Regards,
Peter
2010-04-19 17:41 keltezéssel, Martijn Dashorst írta:
> This time the problem was the confluence backups. I've cleaned those
> up, but that is only one small part of the maintenance: confluence
> contains spam like we've never seen and I don't want to be held
> accountable for the pron links (or worse) that are hosted in our
> confluence instance.
>
> Martijn
>
> On Mon, Apr 19, 2010 at 5:37 PM, Johan Compagner <jc...@gmail.com> wrote:
>> problem is that we need to roll those var logs better.
>> With those latest maven fixes for this unique version number problems did
>> fix most of the hd problems
>> only var is now an issue because of those logs that are just appending and
>> appending.
>> that will not solve even if we just host the examples because that is the
>> problem i think. (apache and or tomcat logs)
>>
>> So first if somebody could look once at those logs then i think many of
>> those maintenance issues are gone
>>
>> i dont think that /repository/maven and so on is now a problem with
>> diskspace.
>>
>>
>> On Mon, Apr 19, 2010 at 17:31, Martijn Dashorst
>> <ma...@gmail.com>wrote:
>>
>>> Currently we have a maintenance nightmare. Keeping up confluence,
>>> jira, teamcity and the maven repo is cumbersome at best. We keep
>>> running out of diskspace (/var has reached -300M disk free, yes minus
>>> 300M).
>>>
>>> So I propose the following:
>>> - use Apache's build grid for Wicket code, Apache repository for
>>> staging and snapshot releases: separating the Apache Wicket projects
>>> from Wicket Stuff projects
>>> - no more custom, self hosted products a la confluence and jira (no
>>> matter how much we like them)
>>> - use wicketstuff.org only for running examples and a build server
>>> for wicket stuff projects
>>> - use sonatype's OSS repo hosting for our snapshots, release staging
>>> and releases (no more wicketstuff.org/repository/maven)
>>>
>>> Most importantly:
>>> - vote on the future of the hosting of Wicket Stuff:
>>> [ ] stay with sf.net
>>> [ ] move to github
>>> - if we stay on sf.net: use the sf.net provided tools to manage the
>>> project: issues, wiki and website
>>> - if we stay to move to github: use github's provided tools to manage
>>> the project: issues, wiki and website
>>>
>>> Martijn
Re: Future of wicketstuff.org
Posted by Martijn Dashorst <ma...@gmail.com>.
This time the problem was the confluence backups. I've cleaned those
up, but that is only one small part of the maintenance: confluence
contains spam like we've never seen and I don't want to be held
accountable for the pron links (or worse) that are hosted in our
confluence instance.
Martijn
On Mon, Apr 19, 2010 at 5:37 PM, Johan Compagner <jc...@gmail.com> wrote:
> problem is that we need to roll those var logs better.
> With those latest maven fixes for this unique version number problems did
> fix most of the hd problems
> only var is now an issue because of those logs that are just appending and
> appending.
> that will not solve even if we just host the examples because that is the
> problem i think. (apache and or tomcat logs)
>
> So first if somebody could look once at those logs then i think many of
> those maintenance issues are gone
>
> i dont think that /repository/maven and so on is now a problem with
> diskspace.
>
>
> On Mon, Apr 19, 2010 at 17:31, Martijn Dashorst
> <ma...@gmail.com>wrote:
>
>> Currently we have a maintenance nightmare. Keeping up confluence,
>> jira, teamcity and the maven repo is cumbersome at best. We keep
>> running out of diskspace (/var has reached -300M disk free, yes minus
>> 300M).
>>
>> So I propose the following:
>> - use Apache's build grid for Wicket code, Apache repository for
>> staging and snapshot releases: separating the Apache Wicket projects
>> from Wicket Stuff projects
>> - no more custom, self hosted products a la confluence and jira (no
>> matter how much we like them)
>> - use wicketstuff.org only for running examples and a build server
>> for wicket stuff projects
>> - use sonatype's OSS repo hosting for our snapshots, release staging
>> and releases (no more wicketstuff.org/repository/maven)
>>
>> Most importantly:
>> - vote on the future of the hosting of Wicket Stuff:
>> [ ] stay with sf.net
>> [ ] move to github
>> - if we stay on sf.net: use the sf.net provided tools to manage the
>> project: issues, wiki and website
>> - if we stay to move to github: use github's provided tools to manage
>> the project: issues, wiki and website
>>
>> Martijn
>>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4
Re: Future of wicketstuff.org
Posted by Johan Compagner <jc...@gmail.com>.
problem is that we need to roll those var logs better.
With those latest maven fixes for this unique version number problems did
fix most of the hd problems
only var is now an issue because of those logs that are just appending and
appending.
that will not solve even if we just host the examples because that is the
problem i think. (apache and or tomcat logs)
So first if somebody could look once at those logs then i think many of
those maintenance issues are gone
i dont think that /repository/maven and so on is now a problem with
diskspace.
On Mon, Apr 19, 2010 at 17:31, Martijn Dashorst
<ma...@gmail.com>wrote:
> Currently we have a maintenance nightmare. Keeping up confluence,
> jira, teamcity and the maven repo is cumbersome at best. We keep
> running out of diskspace (/var has reached -300M disk free, yes minus
> 300M).
>
> So I propose the following:
> - use Apache's build grid for Wicket code, Apache repository for
> staging and snapshot releases: separating the Apache Wicket projects
> from Wicket Stuff projects
> - no more custom, self hosted products a la confluence and jira (no
> matter how much we like them)
> - use wicketstuff.org only for running examples and a build server
> for wicket stuff projects
> - use sonatype's OSS repo hosting for our snapshots, release staging
> and releases (no more wicketstuff.org/repository/maven)
>
> Most importantly:
> - vote on the future of the hosting of Wicket Stuff:
> [ ] stay with sf.net
> [ ] move to github
> - if we stay on sf.net: use the sf.net provided tools to manage the
> project: issues, wiki and website
> - if we stay to move to github: use github's provided tools to manage
> the project: issues, wiki and website
>
> Martijn
>
Re: Future of wicketstuff.org
Posted by Igor Vaynberg <ig...@gmail.com>.
i like the idea of moving to github because we wont have to manage all
the access requests, etc. people can branch, send a pull request and
we can merge their branches easily. i think it will also help with
code dumping where someone commits something for a week and then
leaves their stuff quarter finished in the repo.
-igor
On Mon, Apr 19, 2010 at 8:31 AM, Martijn Dashorst
<ma...@gmail.com> wrote:
> Currently we have a maintenance nightmare. Keeping up confluence,
> jira, teamcity and the maven repo is cumbersome at best. We keep
> running out of diskspace (/var has reached -300M disk free, yes minus
> 300M).
>
> So I propose the following:
> - use Apache's build grid for Wicket code, Apache repository for
> staging and snapshot releases: separating the Apache Wicket projects
> from Wicket Stuff projects
> - no more custom, self hosted products a la confluence and jira (no
> matter how much we like them)
> - use wicketstuff.org only for running examples and a build server
> for wicket stuff projects
> - use sonatype's OSS repo hosting for our snapshots, release staging
> and releases (no more wicketstuff.org/repository/maven)
>
> Most importantly:
> - vote on the future of the hosting of Wicket Stuff:
> [ ] stay with sf.net
> [ ] move to github
> - if we stay on sf.net: use the sf.net provided tools to manage the
> project: issues, wiki and website
> - if we stay to move to github: use github's provided tools to manage
> the project: issues, wiki and website
>
> Martijn
>
Update on wicketstuff.org using the oss.sonatype maven repository
Posted by Michael O'Cleirigh <mi...@rivulet.ca>.
Hello,
I filed an issue to get a wicketstuff.org repository setup within the
sonatype.org infrastructure.
I've been testing and have been able to reliably deploy snapshots (maven
2.2.x is required otherwise uniqueVersion false is not honoured in child
POM's).
We deploy snapshots to here:
http://oss.sonatype.org/content/repositories/snapshots and they are are
accessible.
The 1.4.7-SNAPSHOT off the current trunk is here:
http://oss.sonatype.org/content/repositories/snapshots/org/wicketstuff/
There is a bit of a propogation delay into the release and snapshot url
here: http://oss.sonatype.org/content/groups/public/org/wicketstuff/
which is why the wicketstuff-core pom is using the deploy to url vs this
one.
I've setup a Hudson build server and am trying to get it to work for
deploying snapshots. right now I am using poll scm and an @hourly interval
Once this works I can either add in more users or fold the configuration
into the actual box running wicketstuff.org. If left seperate for now I
was thinking hudson.wicketstuff.org pointing at the box could be a way
to integrate it.
Sonatype can authorize accounts for different parts of a project but it
is all tied to the maven group id.
So right now everything has a groupid of org.wicketstuff so no
differentiation will be possible. Since projects exist both in
wicketstuff-core and also just by themselves its possible that conflicts
could arise if the other one were committed. We could create a sub
group for like org.wicketstuff.core for core projects or a sub group for
everything else like: org.wicketstuff.individual or leave it as it is.
releases can be staged and once promoted will be propagated into the
central maven repository. The first time through we need to file a
ticket but after that its automatic.
I think I need to cut a release and then check some things with a
1.4.8-SNAPSHOT (or the 1.4.9-SNAPSHOT numbering scheme that was
discussed on the list recently). I first deployed without the
<uniqueVersion>false</uniqueVersion> and there is a glitch right now
that the unique versions don't appear in the standard snapshot path of:
http://oss.sonatype.org/content/groups/public/org/wicketstuff. I'm
hoping a clear directory structure with a new path will resolve the issue.
After releases are known to work I want to coordinate the syncing of
teamcity users into hudson users and the addition of more users at
oss.sonatype.org for others to be able to cut releases.
It may not be possible to get older wicketstuff releases into
oss.sonatype because for releases the pom's have to meet the central
sync up requirements. They also have to be signed but that is easy and
well documented. But its something that should be tried to give us the
option to totally shutdown the wicketstuff maven repository.
Regards,
Mike
Key changes:
jslibraries was commented out. I added it back as it is needed for
calendarviews. jslibraries needed the servlet-api-2.5 for a test case
but the wicketstuff-core/pom.xml defined a hard version of 6.1.22 which
didn't exist for the servlet-api-2.5 artifact in central. I hard coded
the version for the current deployed central version of 6.1.14.
flot-parent was directly refering to the wicketstuff.org maven
repository so I commented out that section.
jquery was refering to wicketstuff-misc from before it was included in
wicketstuff-core. I changed the dependency to refer to the
wicketstuff-core version.
In order to deploy releases through to central we can't have repository
or pluginRepository sections in the pom root. So I've removed those
sections from the root and added profiles to encapsulate them.
tinymce-parent was using the wicketstuff maven repo due to the
jazzyplugin, see this message from March 10 for details:
http://mail-archives.apache.org/mod_mbox/wicket-users/201003.mbox/%3C23eb48361003181229o2aca732ci38b415dc7afd554f@mail.gmail.com%3E
a better way would be to get a sonatype account for this artifact and
upload a release bundle and then change the linkage in the
tinymce-parent pom. I believe they allow this situation where the
account creator is doing the upload on behalf of the project as a help
to maven users. JBoss seems to have it or a varient in their maven repo
so that might be another way.
artwork and calendarviews were refering to jslibraries 1.4-SNAPSHOT
which was part of the wicketstuff maven repo which I've changed to point
at 1.4.7-SNAPSHOT.(${project.version}).
> Was there an actual decision about this?
> It's really bad, that the current artifacts are not available in the
> Maven repo..
>
> Regards,
> Peter
>
> 2010-04-19 17:31 keltezéssel, Martijn Dashorst írta:
>
>> Currently we have a maintenance nightmare. Keeping up confluence,
>> jira, teamcity and the maven repo is cumbersome at best. We keep
>> running out of diskspace (/var has reached -300M disk free, yes minus
>> 300M).
>>
>> So I propose the following:
>> - use Apache's build grid for Wicket code, Apache repository for
>> staging and snapshot releases: separating the Apache Wicket projects
>> from Wicket Stuff projects
>> - no more custom, self hosted products a la confluence and jira (no
>> matter how much we like them)
>> - use wicketstuff.org only for running examples and a build server
>> for wicket stuff projects
>> - use sonatype's OSS repo hosting for our snapshots, release staging
>> and releases (no more wicketstuff.org/repository/maven)
>>
>> Most importantly:
>> - vote on the future of the hosting of Wicket Stuff:
>> [ ] stay with sf.net
>> [ ] move to github
>> - if we stay on sf.net: use the sf.net provided tools to manage the
>> project: issues, wiki and website
>> - if we stay to move to github: use github's provided tools to manage
>> the project: issues, wiki and website
>>
>> Martijn
>>
Re: Future of wicketstuff.org
Posted by Major Péter <ma...@sch.bme.hu>.
Was there an actual decision about this?
It's really bad, that the current artifacts are not available in the
Maven repo..
Regards,
Peter
2010-04-19 17:31 keltezéssel, Martijn Dashorst írta:
> Currently we have a maintenance nightmare. Keeping up confluence,
> jira, teamcity and the maven repo is cumbersome at best. We keep
> running out of diskspace (/var has reached -300M disk free, yes minus
> 300M).
>
> So I propose the following:
> - use Apache's build grid for Wicket code, Apache repository for
> staging and snapshot releases: separating the Apache Wicket projects
> from Wicket Stuff projects
> - no more custom, self hosted products a la confluence and jira (no
> matter how much we like them)
> - use wicketstuff.org only for running examples and a build server
> for wicket stuff projects
> - use sonatype's OSS repo hosting for our snapshots, release staging
> and releases (no more wicketstuff.org/repository/maven)
>
> Most importantly:
> - vote on the future of the hosting of Wicket Stuff:
> [ ] stay with sf.net
> [ ] move to github
> - if we stay on sf.net: use the sf.net provided tools to manage the
> project: issues, wiki and website
> - if we stay to move to github: use github's provided tools to manage
> the project: issues, wiki and website
>
> Martijn