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
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
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 pointbreak+wicketst...@ml1.net:
I would think that an eventual move to github is unrelated to any
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
martijn.dasho...@gmail.com wrote:
Currently we have a maintenance nightmare. Keeping up confluence,
jira, teamcity and the maven repo is
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
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
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
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
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
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,
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
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
12 matches
Mail list logo
