Matt,
I noticed your reply to one JIRA issue, but didn't see your comments
regarding later issues. Would you mind if i'll commit those trivial changes:
http://issues.apache.org/jira/browse/JXPATH-102
http://issues.apache.org/jira/browse/JXPATH-101
Best regards,
Sergey.
2007/8/26, Matt Benson <[E
Thanks Hen!
-Matt
--- Henri Yandell <[EMAIL PROTECTED]> wrote:
> *pokes JIRA permissions*
>
> Should be fixed. I'm changing Commons projects so
> that
> commons-developers are admins on each of them. Turns
> out that admins
> don't get all the permissions.
>
> They do now :)
>
> Hen
>
> On 8
Stefan Bodewig wrote:
On Sat, 25 Aug 2007, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Gump needs to run maven in online mode, so it can download the
necessary dependencies, see below...
No, if it did, it wouldn't be serving the purpose it is used for. If
Gump runs Maven in online mode it can
On Sat, 25 Aug 2007, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
> Gump needs to run maven in online mode, so it can download the
> necessary dependencies, see below...
No, if it did, it wouldn't be serving the purpose it is used for. If
Gump runs Maven in online mode it cannot control the artifa
On 8/25/07, Phil Steitz <[EMAIL PROTECTED]> wrote:
>
> On 8/25/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> > Martin Cooper wrote:
> >
> > > > GUMP builds are deemed non-trusted, since GUMP downloads from
> > > > non-ASF sites and includes them in builds without any vetting
> > > > of the third
On 8/25/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> Martin Cooper wrote:
>
> > > GUMP builds are deemed non-trusted, since GUMP downloads from
> > > non-ASF sites and includes them in builds without any vetting
> > > of the third party dependencies.
>
> > True, but it's not clear that everythi
Martin Cooper wrote:
> > GUMP builds are deemed non-trusted, since GUMP downloads from
> > non-ASF sites and includes them in builds without any vetting
> > of the third party dependencies.
> True, but it's not clear that everything in the public Maven repo
> should be considered as "vetted" eith
On 8/25/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
>
> > Why not use the Gump output for the nightlies?
>
> Because GUMP builds are deemed non-trusted, since GUMP downloads from
> non-ASF sites and includes them in builds without any vetting of the third
> party dependencies.
True, but it's n
> Why not use the Gump output for the nightlies?
Because GUMP builds are deemed non-trusted, since GUMP downloads from
non-ASF sites and includes them in builds without any vetting of the third
party dependencies.
--- Noel
---
Mario Ivankovits wrote:
Hi!
It is an interesting topic (to underline this: I am sitting here on vacation
for a hadful of days using my mobile to write this mail ;-) ), though, due to
some other OS projects I am really getting out of time.
Anyway, the j.i.file way of truezip is the case why I d
On 8/25/07, Dion Gillard <[EMAIL PROTECTED]> wrote:
> On 8/26/07, Martin Cooper <[EMAIL PROTECTED]> wrote:
> > On 8/24/07, Phil Steitz <[EMAIL PROTECTED]> wrote:
> > >
> > > Continuum works differently from the old bash script in a couple of
> > > ways. First, it only executes builds when svn chan
Hi!
It is an interesting topic (to underline this: I am sitting here on vacation
for a hadful of days using my mobile to write this mail ;-) ), though, due to
some other OS projects I am really getting out of time.
Anyway, the j.i.file way of truezip is the case why I didnt support this idea
ac
On 8/26/07, Martin Cooper <[EMAIL PROTECTED]> wrote:
> On 8/24/07, Phil Steitz <[EMAIL PROTECTED]> wrote:
> >
> > Continuum works differently from the old bash script in a couple of
> > ways. First, it only executes builds when svn changes have happened.
> > So if there are no changes, there will
On 8/24/07, Phil Steitz <[EMAIL PROTECTED]> wrote:
>
> Continuum works differently from the old bash script in a couple of
> ways. First, it only executes builds when svn changes have happened.
> So if there are no changes, there will be no "nightly build" for a
> component. It also looks for cha
> > In fact, i compared the TrueZip implementation to Compress yesterday.
> > We have quite less features and on some points in the code we depend
> > on java.util.zip packages.
>
> Why is using java.uil.zip bad?
In some discussion in here people said that they wanted implementation
which is indep
...but it would be still a bit of work. When I was
trying to add a new archiver implementation I was frustrated with
some of the details of the current API
I remember. Can you be more concrete? Maybe i can add some
improvements here.
Uff ...would love to help but this has already been a whil
> I am not sure I totally agree here. Last time I looked it was pretty
> much a one-man show from the original author. I wanted to provide a
> patch for some feature. It did not fit into his vision of truezip. So
> I left. (Did I hear someone say fork?) IMO extending java.io.File is
> also a very q
On 25.08.2007, at 14:31, Chr. Grobmeier wrote:
ah very well-
i checked out truezip yesterday and found it quite good.
Its time to ask again if compress should go to dormancy
when such a good component is available with ASF license.
I am not sure I totally agree here. Last time I looked it was
> That's not true :)
hehe ok sorry then :-)
>...but it would be still a bit of work. When I was
> trying to add a new archiver implementation I was frustrated with
> some of the details of the current API
I remember. Can you be more concrete? Maybe i can add some improvements here.
In fact, i c
Problem is that not too much people are interested in seeing compress
out of the sandbox.
That's not true :) ...but it would be still a bit of work. When I was
trying to add a new archiver implementation I was frustrated with
some of the details of the current API
cheers
--
Torsten
--
ah very well-
i checked out truezip yesterday and found it quite good.
Its time to ask again if compress should go to dormancy
when such a good component is available with ASF license.
Regards,
Chris
On 8/25/07, Asankha C. Perera <[EMAIL PROTECTED]> wrote:
> Hi Chris
> > It may be more effective
Hi Chris
It may be more effective with that open TrueZip issue.
Yes, I have checked with Christian Schlichtherle on getting TrueZip into
Maven repos already and he is supportive of the effort. Also I have made
good progress on http://issues.apache.org/jira/browse/VFS-106 patch by
Filip Defo
hi asankha,
the point is, that VFS depends on Compress which is a Sandbox component.
Cause of this Mario copied the compress code into VFS. It was planned that
whenever compress leaves the sandbox VFS will have an dependency on it.
Will wrote code for compress like i did. When it is submitted we h
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-jelly-tags-jsl-test has an issue affecting its community
integration.
Th
Gump needs to run maven in online mode, so it can download the necessary
dependencies, see below...
Adam Jack wrote:
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-id has an issue affecting its community integration.
This issue affects 1
26 matches
Mail list logo
