Re: Blogging on Commons

[Viraj Turakhia]

If I have read it right, I do agree with the point that we need to give
committers access to people more freely.
Suggested solution of having a separate development branch sounds good to me
(don't know how feasible it is).


-v

On Mon, Nov 10, 2008 at 10:38 AM, Martin Cooper <[EMAIL PROTECTED]> wrote:

> On Sun, Nov 9, 2008 at 8:06 AM, Luc Maisonobe <[EMAIL PROTECTED]>
> wrote:
>
> > I would strongly protest against such a move.
>
>
> I wasn't proposing such a move, merely speculating.
>
>
> > Commons are used outside
> > of the ASF and are successful there. I even think [math] is used almost
> > only outside of ASF and not internally ... Commons appear also as low
> > level libraries for general use and this should not be stopped.
> >
> > I have seen many projects that depend on a huge number of libraries. For
> > such projects, a reliable set of reusable components with consistent
> > look and feel is a sure gain.
> >
> > Low level components are important and from my experience often need
> > specific development rules, very strict ones. The reason for that is
> > that you can never make any assumptions on how a low level component
> > will be called/integrated/reused from a random high level complete
> > application.
> >
> > I see the views expressed in both the original post and the previous
> > message as if high level applications were the only important thing and
> > low level components were second class "toys" to share but not to care
> > too much about. Is this really what you meant or did I misunderstood
> > your point ?
>
>
> I believe you misunderstood. I know that I did not mean to imply that, and
> I'm certain that Hen didn't either. His uses of the word "toys" are a play
> on an English idiom about "taking ones toys and going home", and are not
> meant to imply that there's anything toy-like about Commons components. On
> the contrary, I think we're both arguing that Commons components are
> important enough that we want to find ways to encourage people to bring
> reusable code here rather than simply keep it to themselves and not sharing
> it.
>
> --
> Martin Cooper
>
>
> Luc
> >
> > >
> > > No answers here, I'm afraid. Just some additional thoughts to add to
> the
> > > mix.
> > >
> > > --
> > > Martin Cooper
> > >
> > >
> > > On Fri, Nov 7, 2008 at 11:20 PM, Henri Yandell <[EMAIL PROTECTED]>
> > wrote:
> > >
> > >> Apologies for writing this as a blog rather than an email - it felt
> > >> more natural and will pull in other opinions:
> > >>
> > >>
> > >>
> >
> http://blog.generationjava.com/roller/bayard/entry/the-open-and-federated-commons
> > >>
> > >> Hen
> > >>
> > >> -
> > >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >> For additional commands, e-mail: [EMAIL PROTECTED]
> > >>
> > >>
> > >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>



-- 
The first right of human is the right of EGO.
--
http://www.xperienceexperience.blogspot.com

Re: [jelly] Is jelly still in development vs. Open/FederatedCommons

[John Spackman]

Hi Russel,


Forgive me for butting in on a conversation but . . .


Anytime :)


Isn't this whole Subversion centralism problem solved by using a DVCS
such as Bazaar, or Git -- and soon, I gather, Mercurial.


Yes, kind of - I've only recently come across Git and the concept of DVCS 
but it was my intention to look at using a DVCS for this.


But DVCS "only" does source code - setting up a seperate branch only works 
if the community at large see the new branch, whereas the Commons group are 
considering marking Jelly as "No Longer Maintained" and moving the 
repository out of the main branch.


From my point of view, I would only want to perform a public branch with the 
endorsment of the Commons team; IMHO it's important for new and existing 
users to see a future for the project, and for there to be a link from the 
official Commons website to the federated Jelly site.  The original 
downloads would remain for backward compatability, but the Commons site 
would clearly refer users onto the new site for upgrades and future 
development.


John




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] Is jelly still in development vs. Open/Federated Commons

[John Spackman]

Hi Paul,

I wasn't talking about *writing the documentation* but cleanly linking  to 
it.


Ah, ISWYM!  In that case I completely agree :)

I am prepared to upgrade Jelly to Maven2 (not that I know much about 
what that involves, yet)
I would rather disadvise that especially for the huge effort of maven  1 
scripting that was put in jelly building.


Oh OK - this really underlines my lack of familiarity with the Commons group 
because I was under the impression that M2 was wanted across the project.


Returning again to Henri's blog, instead of Jelly being a first use  case 
for retiring a commons project, how about it being a first use  case for 
a "Federated Commons" subproject?  [...snip...]

And you would host that?


Not me personally but an independent body such as SourceForge, Codehaus, 
etc; anything so long as it's open and easily accessible for everyone, and 
can have any/all Commons members immediately added as project administrators



That might be a clean way to attempt maybe...
and I see this fairly easy to use so as to port back changes although  it 
might byte us from time to time.
I think a self-hosted fixed web-site is, for example, a very useful  thing 
to use!


Cool!  This is actually my preferred option and I hope it would give the 
Commons team a way to wind-down a project which is no longer key, but at the 
same time to keep it alive and get some bugs fixed and patches applied.


Most importantly, using Git or similar would mean that there is a route back 
into the Commons in the future if necessary.


What about identifying a handful of issues that you think you could  submit 
one or several patches for?


I'm on holiday right now so the quickest way for you to see something would 
be to generate a patch for a bug I've recently found and fixed with 
selecting the expression parser - please see JELLY-285.  The patch includes 
inline documentation and test cases.


I quickly went through the top 10 bugs in JIRA (ordered by priority) and 
there are 6 bug reports already with patches ready to be added; of the 
remaining 4, 1 was without a straightforward test case, 1 minor feature 
request, 1 questionable report, leaving 1 to be worked on (JELLY-184).  Some 
of these date back to 2004.


(The 11th one was one reported by you via Hans Gilde, in 2004 - JELLY-163 
about handling JEXL expression exceptions)


I can have a look at JELLY-184 when I get back but it's surprising to see 
how many bug reports are still open which had been submitted with patches; 
obviously this is only because the project has not been maintained for 
several years but it's a real shame that they haven't been incorporated. 
One of the first tasks I'd undertake in rejuvenating Jelly would be to 
integrate patches and start updating JIRA.


Regards
John

- Original Message - 
From: "Paul Libbrecht" <[EMAIL PROTECTED]>

To: "Commons Developers List" 
Sent: Sunday, November 09, 2008 8:26 PM
Subject: Re: [jelly] Is jelly still in development vs. Open/Federated 
Commons




Le 09-nov.-08 à 05:35, John Spackman a écrit :
I agree that the website needs some changes although I had thought  that 
this was largely for broken links and for a consistent left- hand side 
menu; updating the documentation for the taglibs is a  pretty herculean 
task, not least because in order to document a  taglib you have to fully 
understand it first, and that would often  mean having a test environment 
and ideally a practical application  for them.


Oh boy, sure!
I wasn't talking about *writing the documentation* but cleanly linking
to it.
There's been an attempt of making documentation a bit better with
examples' link... but it hasn't been pushed enough and, I think,
should mostly be retired going back to jelly doc which has a
sufficient amount of content I believe.

Generally, however, although not perfect I think that the current 
documentation is "adequate" - it certainly was enough for me to get  the 
concepts and get going with it quickly.


Right... but there are slightly misleading parts (including wrong tag-
doc-links and "take maven to start") which really need fixes.

Using Henri's analogies from his recent blog, I took Jelly home from  the 
Commons a couple of years ago and we're now ready to "put it in  the 
window and see if we're invited to play".  If we're invited to  play then 
great - any changes we make will be contributed back (and  documentation 
will come with those changes) - but my "home life" is  a small business 
that keeps me very busy and my focus here is on  gradually contributing 
fixes/improvements and documentation rather  than taking Jelly a great 
leap forward as an O/S product.


I believe that this is what jelly needs... maintenance

I am prepared to upgrade Jelly to Maven2 (not that I know much about  what 
that involves, yet)


I would rather disadvise that especially for the huge effort of maven
1 scripting that was put in jelly building.

and to improve the website but I have to be conf

Re: Blogging on Commons

[Martin Cooper]

On Sun, Nov 9, 2008 at 8:06 AM, Luc Maisonobe <[EMAIL PROTECTED]> wrote:

> I would strongly protest against such a move.


I wasn't proposing such a move, merely speculating.


> Commons are used outside
> of the ASF and are successful there. I even think [math] is used almost
> only outside of ASF and not internally ... Commons appear also as low
> level libraries for general use and this should not be stopped.
>
> I have seen many projects that depend on a huge number of libraries. For
> such projects, a reliable set of reusable components with consistent
> look and feel is a sure gain.
>
> Low level components are important and from my experience often need
> specific development rules, very strict ones. The reason for that is
> that you can never make any assumptions on how a low level component
> will be called/integrated/reused from a random high level complete
> application.
>
> I see the views expressed in both the original post and the previous
> message as if high level applications were the only important thing and
> low level components were second class "toys" to share but not to care
> too much about. Is this really what you meant or did I misunderstood
> your point ?


I believe you misunderstood. I know that I did not mean to imply that, and
I'm certain that Hen didn't either. His uses of the word "toys" are a play
on an English idiom about "taking ones toys and going home", and are not
meant to imply that there's anything toy-like about Commons components. On
the contrary, I think we're both arguing that Commons components are
important enough that we want to find ways to encourage people to bring
reusable code here rather than simply keep it to themselves and not sharing
it.

--
Martin Cooper


Luc
>
> >
> > No answers here, I'm afraid. Just some additional thoughts to add to the
> > mix.
> >
> > --
> > Martin Cooper
> >
> >
> > On Fri, Nov 7, 2008 at 11:20 PM, Henri Yandell <[EMAIL PROTECTED]>
> wrote:
> >
> >> Apologies for writing this as a blog rather than an email - it felt
> >> more natural and will pull in other opinions:
> >>
> >>
> >>
> http://blog.generationjava.com/roller/bayard/entry/the-open-and-federated-commons
> >>
> >> Hen
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Resurrecting commons-email - Was:MultiPartMail order of parts

[Siegfried Goeschl]

Hi Markus,

I opened a JIRA a while ago
(http://issues.apache.org/jira/browse/EMAIL-77) to no avail. So it seems
that commons-email do need some additional attention  :-).

+) well, during the next 2-3 weeks I try to get my commons-exec release
out of the door (politely spoken the release is overdue)
+) after that I can spend some time on commons-email to fix the most
pressing issues
+) I have an snapshot which does not have the problem and is used in
productions

Any hands out to help with commons-email and become a commons-email
maintainer?

+) looking at the changes report none of the original developers are
around and/or actively working on commons ... :-(
+) as part of Apache Turbine folks I'm attached to this project since it
originated from there ... :-)

Cheers,

Siegfried Goeschl

PS: a bit off-topic, does anyone know what Eric Pugh is currently doing?!

Markus Mehrwald wrote:
> Hello,
>
> I use a HTMLEmail with attachments. If I only set the text of the mail
> everything works fine but adding attachments messes up the parts and
> something else then my original text (in this case the attached text
> file) is shown in my mail client.
> It makes no difference if I attach files before or after setting the
> mail text.
>
> Thank you for help,
> Markus
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Fwd: bug?- org.apache.tools.bzip2.CBZip2InputStream

[Emmanuel Bourg]

I don't think this is a bug, CBZip2InputStream ignores the 2 bytes 
header by design (not sure why though). This is documented in the javadoc.


Emmanuel Bourg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] Is jelly still in development vs. Open/Federated Commons

[Paul Libbrecht]

Le 09-nov.-08 à 05:35, John Spackman a écrit :
I agree that the website needs some changes although I had thought  
that this was largely for broken links and for a consistent left- 
hand side menu; updating the documentation for the taglibs is a  
pretty herculean task, not least because in order to document a  
taglib you have to fully understand it first, and that would often  
mean having a test environment and ideally a practical application  
for them.


Oh boy, sure!
I wasn't talking about *writing the documentation* but cleanly linking  
to it.
There's been an attempt of making documentation a bit better with  
examples' link... but it hasn't been pushed enough and, I think,  
should mostly be retired going back to jelly doc which has a  
sufficient amount of content I believe.


Generally, however, although not perfect I think that the current  
documentation is "adequate" - it certainly was enough for me to get  
the concepts and get going with it quickly.


Right... but there are slightly misleading parts (including wrong tag- 
doc-links and "take maven to start") which really need fixes.


Using Henri's analogies from his recent blog, I took Jelly home from  
the Commons a couple of years ago and we're now ready to "put it in  
the window and see if we're invited to play".  If we're invited to  
play then great - any changes we make will be contributed back (and  
documentation will come with those changes) - but my "home life" is  
a small business that keeps me very busy and my focus here is on  
gradually contributing fixes/improvements and documentation rather  
than taking Jelly a great leap forward as an O/S product.


I believe that this is what jelly needs... maintenance

I am prepared to upgrade Jelly to Maven2 (not that I know much about  
what that involves, yet)


I would rather disadvise that especially for the huge effort of maven  
1 scripting that was put in jelly building.


and to improve the website but I have to be confident that the  
changes will happen quickly and easily, and that the project will  
not be retired.


We can make a vote on that... or we can simply try to make it cleaner  
and start applying code patches. I don't think retirement was what  
Henri suggested.


Please don't get me wrong - I am very grateful for your offer to  
apply patches etc sent via JIRA but I am cautious as I think of the  
potential extra work that would entail and how much simpler it would  
be if I could just issue an SVN commit.


I fully understand but Apache foundations' practice has really always  
been such.


Returning again to Henri's blog, instead of Jelly being a first use  
case for retiring a commons project, how about it being a first use  
case for a "Federated Commons" subproject?  I appreciate the point  
that making commits open to anybody has it's problems and is not  
something the team want to do right now, but given that the list is  
contemplating retiring Jelly this could be an ideal opportunity to  
experiment with something where the team has little to lose.  The  
original SVN archive would remain intact at Apache, and I'd take a  
copy of it for my 1.x trunk so that I could create branches  
(possibly using Git); any projects already using Jelly 1.0 would be  
completely unaffected, but new users and users wishing to update  
would be referred to the new Federated Jelly website & repository.


And you would host that?
That might be a clean way to attempt maybe...
and I see this fairly easy to use so as to port back changes although  
it might byte us from time to time.


I think a self-hosted fixed web-site is, for example, a very useful  
thing to use!


What about identifying a handful of issues that you think you could  
submit one or several patches for?


paul

smime.p7s
Description: S/MIME cryptographic signature

Re: Blogging on Commons

[Phil Steitz]

On 11/9/08, Martin Cooper <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 8, 2008 at 12:46 PM, Jochen Wiedmann
> <[EMAIL PROTECTED]>wrote:
>
> > On Sat, Nov 8, 2008 at 7:51 PM, Martin Cooper <[EMAIL PROTECTED]> wrote:
> >
> > > For example, one of the reasons people don't want to bring things to
> > Commons
> > > any more is because they have to buy in to the entire Commons enchilada.
> > > Consistent build systems, consistent web sites, consistent release
> > criteria,
> > > and so on. This consistency is crucial when Commons is being promoted to
> > the
> > > "outside world", because it allows consumers to understand what they will
> > > see / get from any given component. I believe it's a big part of what has
> > > made Commons a "brand" in and of itself, and for Commons as an
> > > externally-facing project, it's definitely a Good Thing (tm).
> >
> > I don't agree with that. IMO, it's gross how much a commons
> > subproject is influenced by others. I'd clearly prefer if the subprojects
> > were
> > completely driven by those who actually do the subprojects work.
>
>
> But that's exactly my point. If you're a (prospective) Commons developer,
> you quite likely don't want to have to buy into the whole Commons enchilada,
> and would likely prefer to just get on and do things your own way. However,
> if you're someone looking to consume Commons within an enterprise (which is
> part of what I meant by the "outside world"), that consistency across all
> Commons components is a great benefit, because once you understand how one
> of them works, you understand how they all work (within reason, of course).
>

Not sure I agree with either of the conclusions above - either the
statement about what users like or what causes pain for contributors.
Regarding users, while I don't have hard data to support this, I
suspect that the vast majority of commons users (inside and outside
the ASF) don't muck with the builds at all - i.e., they download jars
or have maven do it and just use the components.  For this use, it
makes no difference whether the jars were built using Ant, Maven 1,
Maven 2 or something else.  So I don't agree with the statement that
everyone using the same build structure helps users all that much.
Common look-and-feel for sites may have some value, but as long as the
nav is not horrendous, I personally don't see this as a big deal.  I
don't remember users complaining about it when we had a mix of maven
and anakia-generated sites a few years back.

I also disagree with the "whole enchilada" idea as the primary cause
of pain for contributors.  The problem for new contributors is getting
builds to work at all and then for the true punishment-seekers,
navigating the release process.  The release obstacles here are as
much ASF obstacles as commmons - lots of quasi-documented requirements
about what has to be included, what to vote on, how tags need to work,
etc.  At the end of the Maven 1 period, we at least had a documented
process for building and cutting releases that made it a little easier
for people to get started and even push out releases.  My HO here is
that if we could get a really fully functional standardized way to
build and release in M2, it would actually be a lot easier for people
and there would be no reason for people to want to "do their own
thing" since the standardized way would save them boring work.  We
have gotten close to this thanks to Niall,. Dennis, Rahul and a few
others and I think things will be better when we have sorted out the
last bits.  That said, I have always maintained that do-ocracy should
trump tidiness here, so those doing the work to develop and cut
releases should be allowed to choose, as long as what we vote on ends
up meeting ASF requirements.

Phil

> --
> Martin Cooper
>
>
> Jochen
> >
> >
> > --
> > I have always wished for my computer to be as easy to use as my
> > telephone; my wish has come true because I can no longer figure out
> > how to use my telephone.
> >
> >-- (Bjarne Stroustrup,
> > http://www.research.att.com/~bs/bs_faq.html#really-say-that
> >   My guess: Nokia E50)
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Blogging on Commons

[Luc Maisonobe]

Martin Cooper a écrit :
> Interesting post. Allow me to do some thinking out loud of my own. ;-)
> 
> IMHO, in its earlier days, Commons worked well in that quite a few projects
> did "donate" parts of their code bases to Commons, thus seeding it and
> enhancing the commonality between those projects and promoting sharing
> beyond the ASF as well. In fact, I believe that it is actually Commons'
> success that has led to some of the problems that we see today, and some of
> the problems you blogged about.
> 
> You see, we actually did two things with Commons, one of which we explicitly
> set out to do, and the other that I don't think we really thought about too
> much, at least at that time. The former is what you describe in your blog
> post - "a place for Jakarta [and later, other] projects to come together".
> Great idea, great initial execution, and I think many projects, Jakarta and
> otherwise, have benefited from that.
> 
> The second thing we did was to expose these common pieces of code as ASF
> release artifacts, and to promote them as reusable components outside of the
> ASF. This was a fairly natural thing to do. After all, if the code is
> reusable across ASF projects, then it's probably reusable across non-ASF
> projects as well. However, I think it's the extent to which we have gone
> down this path that has led to many of the problems.
> 
> For example, one of the reasons people don't want to bring things to Commons
> any more is because they have to buy in to the entire Commons enchilada.
> Consistent build systems, consistent web sites, consistent release criteria,
> and so on. This consistency is crucial when Commons is being promoted to the
> "outside world", because it allows consumers to understand what they will
> see / get from any given component. I believe it's a big part of what has
> made Commons a "brand" in and of itself, and for Commons as an
> externally-facing project, it's definitely a Good Thing (tm).
> 
> However, this is a pain in the neck for the Commons developers, and it's a
> significant hurdle for someone bringing code to Commons from some other ASF
> project. Thinking back to when Struts broke out several chunks of code
> (BeanUtils, Digester, etc.) and moved them to the nascent Commons, that was
> straightforward because each component pretty much did its own thing back
> then. Would we have done the same thing if we'd had to go through today's
> shenanigans? I don't know, but it wouldn't have been the slam dunk that it
> was.
> 
> What's the answer? I don't know. It would be kinda antisocial to "take
> Commons private" and make it "internal use only", although that might be the
> easiest way to relax the rules and make it easier for projects to "donate"
> parts of their code base. With such a model, we might even eliminate
> releases altogether and leave the onus on the consuming projects to
> determine the quality of whatever tag / revision they consume. There would
> be pressure, in some form, to release some of the pieces, and the question
> then becomes one of who would be willing to go through the extra steps to
> create a release out of an internal shared library, especially if that was
> not necessary for internal consumption.

I would strongly protest against such a move. Commons are used outside
of the ASF and are successful there. I even think [math] is used almost
only outside of ASF and not internally ... Commons appear also as low
level libraries for general use and this should not be stopped.

I have seen many projects that depend on a huge number of libraries. For
such projects, a reliable set of reusable components with consistent
look and feel is a sure gain.

Low level components are important and from my experience often need
specific development rules, very strict ones. The reason for that is
that you can never make any assumptions on how a low level component
will be called/integrated/reused from a random high level complete
application.

I see the views expressed in both the original post and the previous
message as if high level applications were the only important thing and
low level components were second class "toys" to share but not to care
too much about. Is this really what you meant or did I misunderstood
your point ?

Luc

> 
> No answers here, I'm afraid. Just some additional thoughts to add to the
> mix.
> 
> --
> Martin Cooper
> 
> 
> On Fri, Nov 7, 2008 at 11:20 PM, Henri Yandell <[EMAIL PROTECTED]> wrote:
> 
>> Apologies for writing this as a blog rather than an email - it felt
>> more natural and will pull in other opinions:
>>
>>
>> http://blog.generationjava.com/roller/bayard/entry/the-open-and-federated-commons
>>
>> Hen
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For addi

Re: Blogging on Commons

[sebb]

On 09/11/2008, Martin Cooper <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 8, 2008 at 12:46 PM, Jochen Wiedmann
>  <[EMAIL PROTECTED]>wrote:
>
>
>  > On Sat, Nov 8, 2008 at 7:51 PM, Martin Cooper <[EMAIL PROTECTED]> wrote:
>  >
>  > > For example, one of the reasons people don't want to bring things to
>  > Commons
>  > > any more is because they have to buy in to the entire Commons enchilada.
>  > > Consistent build systems, consistent web sites, consistent release
>  > criteria,
>  > > and so on. This consistency is crucial when Commons is being promoted to
>  > the
>  > > "outside world", because it allows consumers to understand what they will
>  > > see / get from any given component. I believe it's a big part of what has
>  > > made Commons a "brand" in and of itself, and for Commons as an
>  > > externally-facing project, it's definitely a Good Thing (tm).
>  >
>  > I don't agree with that. IMO, it's gross how much a commons
>  > subproject is influenced by others. I'd clearly prefer if the subprojects
>  > were
>  > completely driven by those who actually do the subprojects work.
>
>
>
> But that's exactly my point. If you're a (prospective) Commons developer,
>  you quite likely don't want to have to buy into the whole Commons enchilada,
>  and would likely prefer to just get on and do things your own way. However,
>  if you're someone looking to consume Commons within an enterprise (which is
>  part of what I meant by the "outside world"), that consistency across all
>  Commons components is a great benefit, because once you understand how one
>  of them works, you understand how they all work (within reason, of course).

It's also a lot easier for committers to work on multiple commons
projects if the components all do things in the same way.

And it probably helps with PMC oversight too.

>  --
>  Martin Cooper
>
>
>
>  Jochen
>  >
>  >
>  > --
>  > I have always wished for my computer to be as easy to use as my
>  > telephone; my wish has come true because I can no longer figure out
>  > how to use my telephone.
>  >
>  >-- (Bjarne Stroustrup,
>
> > http://www.research.att.com/~bs/bs_faq.html#really-say-that
>
> >   My guess: Nokia E50)
>  >
>  > -
>  > To unsubscribe, e-mail: [EMAIL PROTECTED]
>  > For additional commands, e-mail: [EMAIL PROTECTED]
>  >
>  >
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[EMAIL PROTECTED]: Project commons-configuration-test (in module apache-commons) failed

[Gump]

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-configuration-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 17 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-configuration-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven2 settings: 
[/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml]
 -DEBUG- (Gump generated) Maven2 Settings in: 
/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/apache-commons/configuration/pom.xml



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/gump_work/build_apache-commons_commons-configuration-test.html
Work Name: build_apache-commons_commons-configuration-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 21 secs
Command Line: mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml 
test 
[Working Directory: /srv/gump/public/workspace/apache-commons/configuration]
CLASSPATH: 
/usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/apache-commons/configuration/target/commons-configuration-1.6-SNAPSHOT.jar
-
  testSaveAttributes(org.apache.commons.configuration.TestXMLConfiguration)
  testCloneWithSave(org.apache.commons.configuration.TestXMLConfiguration)
  testEmptyElements(org.apache.commons.configuration.TestXMLConfiguration)
  testSaveWithEncoding(org.apache.commons.configuration.TestXMLConfiguration)
  
testSaveWithNullEncoding(org.apache.commons.configuration.TestXMLConfiguration)
  testSaveWithDoctype(org.apache.commons.configuration.TestXMLConfiguration)
  testSaveWithDoctypeIDs(org.apache.commons.configuration.TestXMLConfiguration)
  testSubsetWithReload(org.apache.commons.configuration.TestXMLConfiguration)
  
testConfigurationAtWithReload(org.apache.commons.configuration.TestXMLConfiguration)
  
testConfigurationsAtWithReload(org.apache.commons.configuration.TestXMLConfiguration)
  testGetKeysWithReload(org.apache.commons.configuration.TestXMLConfiguration)
  testSetTextRootElement(org.apache.commons.configuration.TestXMLConfiguration)
  
testClearTextRootElement(org.apache.commons.configuration.TestXMLConfiguration)
  
testAutoSaveWithSubnodeConfig(org.apache.commons.configuration.TestXMLConfiguration)
  
testAutoSaveWithSubSubnodeConfig(org.apache.commons.configuration.TestXMLConfiguration)
  
testSaveDelimiterParsingDisabled(org.apache.commons.configuration.TestXMLConfiguration)
  
testSaveDelimiterParsingDisabledAttrs(org.apache.commons.configuration.TestXMLConfiguration)
  
testMultipleAttrValuesEscaped(org.apache.commons.configuration.TestXMLConfiguration)
  
testAutoSaveWithReloadingStrategy(org.apache.commons.configuration.TestXMLConfiguration)
  testAutoSaveAddNodes(org.apache.commons.configuration.TestXMLConfiguration)
  testAddNodesAndSave(org.apache.commons.configuration.TestXMLConfiguration)
  testRegisterEntityId(org.apache.commons.configuration.TestXMLConfiguration)
  
testSaveAfterCreateWithCopyConstructor(org.apache.commons.configuration.TestXMLConfiguration)
  testCopyRootName(org.apache.commons.configuration.TestXMLConfiguration)
  
testCopyRootNameNoDocument(org.apache.commons.configuration.TestXMLConfiguration)
  testParse(org.apache.commons.configuration.TestBaseConfigurationXMLReader)
  
testSetRootName(org.apache.commons.configuration.TestBaseConfigurationXMLReader)
  
testParentReloadNotSupported(org.apache.commons.configuration.TestSubnodeConfiguration)
  
testParentReloadSupported(org.apache.commons.configuration.TestSubnodeConfiguration)
  
testParentReloadSupportAccessParent(org.apache.commons.configuration.TestSubnodeConfiguration)
  
testParentReloadSubSubnode(org.apache.commons.configuration.TestSubnodeConfiguration)
  
testParentReloadSubSubnodeNoChangeSupport(org.apache.commons.configuration.TestSubnodeConfiguration)
  
testParse(org.apache.commons.configuration.TestHierarchicalConfigurationXMLReader)
  
testLoadXMLWithSettings(org.apache.commons.configuration.TestDefaultConfigurationBuilder)

Tests run: 1268, Failures: 0, Errors: 47, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] --