[ANNOUNCE] Release of Commons HttpClient 2.0 Alpha 3

[Jeffrey Dever]

This is an intermediate alpha release. The build process used in the 
previous Alpha 2 changed from generating 4 build artifacts to a single 
distribution. This one zip contains everything: all the source, the 
binary jar, the logging dependancy, generated javadoc and required build 
files for Ant builds and JUnit tests.

   "One zip to rule them all, one zip to find them, one zip to bring
   them all and in the darkness
   bind them"
http://jakarta.apache.org/commons/httpclient/
http://www.apache.org/dist/jakarta/commons/httpclient/
Commons HttpClient Development Team

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

Re: HTTPClient Feature Patch

[Jeffrey Dever]

Thoralf Rickert wrote:

Hi!

I'm not subribed to the list, so please make a CC to my address...

I'm working on a small WebDAV application based on the 
org.apache.webdav library. For user feedback it is necessary to know 
how many bytes a Put request has already finished 
(0%...25%...50%...75%...100%) (especially for big files). Because the 
WebDAV PutMethod extends the httpclient PutMethod which extends the
org.apache.commons.httpclient.methods.EntityEnclosingMethod,
I would like to "submit" a small patch, which makes it possible to get 
the number of already sent bytes in a "controlling thread"Here is 
the code:

package org.apache.commons.httpclient.methods;
[...]
public abstract class EntityEnclosingMethod extends GetMethod {
[...]
  private long writtenBytes = 0;
[...]
  protected boolean writeRequestBody(HttpState state,
 HttpConnection conn)
  throws IOException, HttpException {
[]
writtenBytes = 0;
byte[] tmp = new byte[4096];
//int total = 0;
int i = 0;
while ((i = instream.read(tmp)) >= 0) {
  outstream.write(tmp, 0, i);
  //total += i;
  writtenBytes += i;
}
[]
  }
  /**
   * Returns the Number of Request Body Bytes send to the server
   */
  public long getWrittenRequestBodyBytes() {
return this.writtenBytes;
  }
}
If I would start the HttpConnection in a subthread I could call the 
getWrittenRequestBodyBytes() method (or however you call it) during 
upload to get the number of transfered bytes. So I can show the user, 
that the application still works...

Do you think, that this small patch is useful for you too or do you 
know another way?

Thanks,
Thoralf Rickert


-
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: HTTPClient Feature Patch

[Jeffrey Dever]

This is a good idea, particularly for updating a JProgressBar.  Can you 
please bring this up on the [EMAIL PROTECTED] 
mailing list?

Thoralf Rickert wrote:

Hi!

I'm not subribed to the list, so please make a CC to my address...

I'm working on a small WebDAV application based on the 
org.apache.webdav library. For user feedback it is necessary to know 
how many bytes a Put request has already finished 
(0%...25%...50%...75%...100%) (especially for big files). Because the 
WebDAV PutMethod extends the httpclient PutMethod which extends the
org.apache.commons.httpclient.methods.EntityEnclosingMethod,
I would like to "submit" a small patch, which makes it possible to get 
the number of already sent bytes in a "controlling thread"Here is 
the code:

package org.apache.commons.httpclient.methods;
[...]
public abstract class EntityEnclosingMethod extends GetMethod {
[...]
  private long writtenBytes = 0;
[...]
  protected boolean writeRequestBody(HttpState state,
 HttpConnection conn)
  throws IOException, HttpException {
[]
writtenBytes = 0;
byte[] tmp = new byte[4096];
//int total = 0;
int i = 0;
while ((i = instream.read(tmp)) >= 0) {
  outstream.write(tmp, 0, i);
  //total += i;
  writtenBytes += i;
}
[]
  }
  /**
   * Returns the Number of Request Body Bytes send to the server
   */
  public long getWrittenRequestBodyBytes() {
return this.writtenBytes;
  }
}
If I would start the HttpConnection in a subthread I could call the 
getWrittenRequestBodyBytes() method (or however you call it) during 
upload to get the number of transfered bytes. So I can show the user, 
that the application still works...

Do you think, that this small patch is useful for you too or do you 
know another way?

Thanks,
Thoralf Rickert


-
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: help - multiple location of commons releases

[Jeffrey Dever]

I was looking for just one physical location to manually put release 
packages, with any mirroring/grouping/multiple locations to be done 
automagicly.  Not wanting to break anything or remove old links, just 
wanting efficient use of computer resources and simple processes to follow.

Jeff.

Stefan Bodewig wrote:

On Sun, 16 Feb 2003, Craig R. McClanahan <[EMAIL PROTECTED]> wrote:

 

-1 on removing the nightly builds directory
(jakarta.apache.org/builds/jakarta-commons/nightly/).
   

But shouldn't that be on cvs.apache.org?  Again, rewrite rules are
your friend for people using the old URLs.

 

They already are, thanks to rewrite rules :-).
   


So there is no reason to keep the old physical locations 8-)

 

But there are *lots* of references in the world to the original
URLs, and we don't want to violate that.
   


Of course not.





all still work (and redirect to three different virtual hosts), even
though you won't find an ant or jakarta-ant directory under
jakarta.apache.org.

I think Jeff's proposal was to stop using and communicating the old
URLs, not to make them non-functional.

Stefan

-
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: help - multiple location of commons releases

[Jeffrey Dever]

Here are my suggestions for commons regarding release processes:

1) All release packages should be copied to 
www.apache.org/dist/jakarta/commons to allow for mirroring.
2) jakarta.apache.org/builds/jakarta-commons should be deprecated, 
removed or replaced with a softlink or a forward
3) single inclusive release package.  There should be only one release 
package that contains the license, jar, source, documentation and all 
other files for building and using the component.
4) the binary jar should be uploaded to ibiblio (need to deal with 
license issue)

Robert,
I have a release guide for httpclient.  It is based on the commons one, 
but more complete and accurate (I hope).  Its kept in xml form in the 
repository but is on the website in maven generated form:
http://jakarta.apache.org/commons/httpclient/releases.html


i was considering updating the release documentation but really a 
discussion about release procedures is probably in order first. i'll 
volunteer to update them afterwards if a consensus forms.

for the latest releases i've cut, i've added them only to the mirrored 
directories. i've also also tried to follow the apache mirroring 
guidelines. i've added instructions to the commons release directory 
telling people to obtain them through the mirrors. the reason why i 
haven'
t added them to the commons directory is that i want to encourage 
downloads from mirrors since this reduces the strain on the apache 
infrastructure.

- robert




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

Re: help - multiple location of commons releases

[Jeffrey Dever]

Hmmm, so even though www.apache.org and jakarta.apache.org are served 
from the same physical machines, we are to keep two binary and source 
repositories up to date with new releases? Why isn't one just a softlink 
of the other?

And speaking of releases, why in commons do we have two packages for 
each release, one for source and one for binaries?  These are small 
components where the biggest thing about them is the generated javadoc 
which is in both.  I find that people usually download the binary drop 
and then ask on the mailing list "where is the example code?" which is 
of course in the source package.

Can't we just release one package with everything in it?  In general the 
only thing that makes a binary a binary is that it has a packaged jar 
file which is small anyway compared to the source and documentation.

Whats the point?


robert burrell donkin wrote:

hi jeff

the www.apache.org location is mirrored. see 
http://www.apache.org/dev/mirrors.html.

the policy i've used for the latest beanutils and digester releases is 
to force users to download from the mirrored site. if you do want to 
keep a release available from the old location, there isn't really any 
updating that needs to be done since it's just a case of dropping the 
release off in two places.

- robert

On Thursday, February 13, 2003, at 08:14 PM, Jeffrey Dever wrote:

There appears to be (at least two) locations for releases that need 
to be manually updated: one on jakarta.apache.org and one on 
www.apache.org.  Are we supposted to keep both of these manually 
updated?  Why are there two?  I have an account on deadalus, but 
where would I even go to modify what www.apache.org points to?

http://www.apache.org/dist/jakarta/commons/httpclient/
http://jakarta.apache.org/builds/jakarta-
commons/release/commons-httpclient/

Jeff Dever


-
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]






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

help - multiple location of commons releases

[Jeffrey Dever]

There appears to be (at least two) locations for releases that need to 
be manually updated: one on jakarta.apache.org and one on 
www.apache.org.  Are we supposted to keep both of these manually 
updated?  Why are there two?  I have an account on deadalus, but where 
would I even go to modify what www.apache.org points to?

http://www.apache.org/dist/jakarta/commons/httpclient/
http://jakarta.apache.org/builds/jakarta-commons/release/commons-httpclient/

Jeff Dever


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

Re: [VOTE] FileUpload 1.0 Beta 1 Release Plan

[Jeffrey Dever]

Sounds a bit casual, but reasonable.
+0


Martin Cooper wrote:


On Sat, 8 Feb 2003, Jeffrey Dever wrote:

 

Just curious, if this is the first release build ever, should it not be
labeled Alpha1?
   


FileUpload has been in use by "external customers" such as Struts and
Turbine for some time now, without any serious issues. As such, I consider
that it has done its time in Alpha, despite not being labelled as such,
and is ready for a Beta release.

--
Martin Cooper


 

Martin Cooper wrote:

   

Here's my own +1.

--
Martin Cooper


On Sat, 8 Feb 2003, Martin Cooper wrote:



 

The FileUpload component has been stable for a while now, but available
only from nightly builds. It's time to create a milestone release against
which a final series of bug fixes and documentation updates can occur
before a FileUpload 1.0 Final release is created.


Therefore, I propose that the tip of the main trunk in CVS be released as
a FileUpload 1.0 Beta 1 release. I will act as the Release Manager.

--
Vote:  FileUpload 1.0 Beta 1 Release Plan
[X] +1 I am in favor of the release, and will help support it.
[ ] +0 I am in favor of the release, but am unable to help support it.
[ ] -0 I am not in favor of the release.
[ ] -1 I am against this proposal (must include a reason).
--

--
Martin Cooper


-
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]




 


-
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]


 




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

Re: [VOTE] FileUpload 1.0 Beta 1 Release Plan

[Jeffrey Dever]

Just curious, if this is the first release build ever, should it not be 
labeled Alpha1?

Martin Cooper wrote:

Here's my own +1.

--
Martin Cooper


On Sat, 8 Feb 2003, Martin Cooper wrote:

 

The FileUpload component has been stable for a while now, but available
only from nightly builds. It's time to create a milestone release against
which a final series of bug fixes and documentation updates can occur
before a FileUpload 1.0 Final release is created.


Therefore, I propose that the tip of the main trunk in CVS be released as
a FileUpload 1.0 Beta 1 release. I will act as the Release Manager.

--
Vote:  FileUpload 1.0 Beta 1 Release Plan
[X] +1 I am in favor of the release, and will help support it.
[ ] +0 I am in favor of the release, but am unable to help support it.
[ ] -0 I am not in favor of the release.
[ ] -1 I am against this proposal (must include a reason).
--

--
Martin Cooper


-
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]


 




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

Re: [codec] RE: Base64.java

[Jeffrey Dever]

Well said.  Totally agree.

Ryan Hoegg wrote:


We do as well.  Codec should probably end up with the union, not the 
intersection   However, ours tests for the MIME specific 76 character 
line wrapping.

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net

Jeffrey Dever wrote:

That sounds good here too.  We only call Base64 methods a couple of 
times anyway, so adaptation is a minor issue.

Just a note about tests, we have a Junit test class (not sure if 
xml-rpc has one) that should go along with the main Base64 class.  
You did a grep on the code base so I'm sure you are aware of it.

Jandalf.

I like your plan Tim.  Let's get 1.1 nailed down so we are all on 
the same codebase, and do the design of 2.0 right.  I don't think 
XML-RPC cares much whether we get the default in decode(byte[]) in 
1.1, I think that decision should be made based on RFC interpretation.

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net 





-
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: [codec] RE: Base64.java

[Jeffrey Dever]

Base64 is well understood just as a general encoding scheme outside of RFC
2045 MIME.   RFC 2045 MIME adds a further requirement that the content be
put into 76 character chunks.  Past 1.1 we could also talk about Base64.java
providing the core "base64" encoding, and MIMEBase64.java extending Base64
and adding "pre" and "post" processing to the algorithm.
 

As long as efficiency is held as a key requirement over OO purity. 
After all, Base64 is functional in nature.  

There should only be one memory allocation for the output, and one 
iteration over the input.  It would be inefficient to allocate the 
output array, iterate over the input for the general algorithm, then 
have to reallocate another array and iterate over the intermediate 
output just to drop in '\n' every 76 characters.

But in the HttpClient case, we only encode/decode small inputs (few 
hundred bytes) anyway.

Jandalf.


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

Re: [codec] RE: Base64.java

[Jeffrey Dever]

That sounds good here too.  We only call Base64 methods a couple of 
times anyway, so adaptation is a minor issue.

Just a note about tests, we have a Junit test class (not sure if xml-rpc 
has one) that should go along with the main Base64 class.  You did a 
grep on the code base so I'm sure you are aware of it.

Jandalf.

I like your plan Tim.  Let's get 1.1 nailed down so we are all on the 
same codebase, and do the design of 2.0 right.  I don't think XML-RPC 
cares much whether we get the default in decode(byte[]) in 1.1, I 
think that decision should be made based on RFC interpretation.

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net


-
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: [codec] RE: Base64.java

[Jeffrey Dever]

Fair enough.  I guess the normal case would be just 
encode/decode(byte[]) without 76 character chunks, which is what 
HttpClient would be using anyway.  

So I take back any preference to method signature, except that the 
"normal" or "default" case be not chunked.  If xml-rpc is going to be 
using the chunked form, then their prefrence should be given high weight.

Jandalf.


Henri Yandell wrote:

I agree with you up until the last point.

Rather than an obscure and irritating boolean argument on the end, just
offer a different name.

public static byte[] decode(byte[] data);
public static byte[] decodeChunked(byte[] data);

[bear in mind decodeChunked may be a bad name. I'm just copying :) ]

 



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

Re: [codec] RE: Base64.java

[Jeffrey Dever]

ntent-Transfer-Encoding, and does use Transfer-Encoding and
Content-Encoding. Another is that HTTP more frequently uses binary content
types than MIME, so it is worth noting that, in such cases, the byte order
used to compute the digest is the transmission byte order defined for the
type. Lastly, HTTP allows transmission of text types with any of several
line break conventions and not just the canonical form using CRLF."



Tim O'Brien 

 

-Original Message-
From: Jeffrey Dever [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, February 04, 2003 10:16 AM
To: O'brien, Tim
Cc: 'Martin Redington'; [EMAIL PROTECTED]
Subject: Re: Base64.java


Http is very cr/lf aware. We use Base64 for encoding/decoding values 
that are added to headers which are always appended with a cr/lf as a 
value is not to contain the line delimiter.

Where (which) rfc does it state the trailing cr/lf?

Jandalf.

   




 



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

A new VOTE list commoons-vote

[Jeffrey Dever]

The most recent dicsussion of having a commons-vote list had pretty good 
support but the thread died away.

Not having a dedicated place to vote is a continuous problem for 
HttpClient, and would be for any other project that is looking towards 
its own list.  When we vote, we have to decide:

   1) to post on the commons-httpclient-dev list where people most 
interested in httpclient hang out (about 130 subscribers)
   2) post to the commons-dev list where most of the commons committers 
are subscribed
   3) cross post and risk getting flamed and fragmenting the results to 
make the result difficult to veryify

A dedicated list would completely solve our voting problem.

Recently we have seen a number of poorly formed votes on commons.  That 
is just expected in the current framework.  The dev list is so casual, 
that it is natural to expect casual votes.  A dedicated vote list would 
give us well defined location to look to for examples, not 350 messages 
ago in the archives or somewhere on the website but right there, on the 
list.

I'm not going to propose a vote on this issue myself: I'm just happy 
being the release prime for HttpClient. I'm certainly willing to help, 
but this is somthing that should be driven at a higher level.  I would 
be very impressed if someone on the PMC would take up this cause and at 
least present a proposal here that we can vote on and bring this issue 
to a close one way or another.

-jsd


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

Re: [codec] RE: more common classes need a home

[Jeffrey Dever]

+1

Any timeline for raising codec out of the sandbox?


O'brien, Tim wrote:


Rev 1.1 of Base64 was checked in by Sander Striker about 1 year ago.  It was
initially from the HttpClient project.

The codec Base64 class has an open bug which also should point us in the
right direction: http://issues.apache.org/bugzilla/show_bug.cgi?id=16440

So, I'll make a proposal and hope for lazy consensus:

Let's replace Base64 in codec with the current HttpClient version.


Tim O'Brien 


 

-Original Message-
From: Jeffrey Dever [mailto:[EMAIL PROTECTED]] 
Sent: Monday, February 03, 2003 1:04 AM
To: Jakarta Commons Developers List
Subject: Re: more common classes need a home


*commons.codec* sounds like a good place for this class.  Perhaps you 
could look at the various current implementations, and see if you can 
provide a common Base64 class attractive to everyone in Jakarta.  

Currently these projects (at least) have one plus your new 
codec package:
   tomcat
   xml-rpc
   slide
   httpclient

Three cheers for code reuse!

   

This goes into codec, which is still in Sandbox.
Infact there's already a Base64 there, but I'm not
sure how well it matches Slide's needs.



 

-
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]


 



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

Re: more common classes need a home

[Jeffrey Dever]

*commons.codec* sounds like a good place for this class.  Perhaps you 
could look at the various current implementations, and see if you can 
provide a common Base64 class attractive to everyone in Jakarta.  

Currently these projects (at least) have one plus your new codec package:
   tomcat
   xml-rpc
   slide
   httpclient

Three cheers for code reuse!

This goes into codec, which is still in Sandbox.
Infact there's already a Base64 there, but I'm not
sure how well it matches Slide's needs.

 



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

more common classes need a home

[Jeffrey Dever]

There are still a bunch of classes that are in both HttpClient and 
Slide.  In particular:
Base64.java
HttpsURL.java
HttpURL.java
URIException.java
URI.java
URIUtil.java
URLUtil.java

First of all, I think these should come out of Slide as part of their 
migration to commons-httpclient which is still underway.

Second, I thnk that these classes are too general to be part of 
HttpClient.  They have use well beyond a http client, and so should be 
available to other packages without requiring the commons-httpclient.jar.

Do people agree with me?  If so, any idea where these could go?  Perhaps 
the root of org.apache.commons?  or a new commons-net package?  put 
Base64 in commons-lang, and create a new commons-uri package?

If we do this, would it be better for HttpClient to roll the classes 
into the commons-httpclient.jar, or require it as a dependancy?

Any comments would be helpful.

Jandalf.






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

maven style core javadoc on jakarta

[Jeffrey Dever]

It would be nice to have the javadoc generated for jakarta projects to 
link internally to the actual Sun core api documentation.  This was 
easily accomplished with ant, but I'm not sure how to do that with maven.

It would probablly be nice to have a set of core javadoc for various 
java versions hosted on Jakarta.  Perhaps in the Maven style?  Then 
projects could use that as a external refrence.  Does that sound like a 
good idea?

-jsd


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

Re: Time for more mailing lists ?

[Jeffrey Dever]

single component mailing lists
--
i think that single component mailing lists have not proved very 
successful. 


I completely disagree.  As the HttpClient 2.0 release prime, I am 
disheartened that you feel that way.


not only are they unpopular with the components themselves but they 
are hard for outsiders to monitor. i (for one) have no idea about 
what's happening in httpclient and i cannot effectively supervise them.

Please, subscribe to the httpclient list.  It would be no different for 
those who wanted all traffic to just subscribe to all lists.  You just 
have to subscribe once and thats it.  But for those who want to focus on 
particular components, there is no effictive way to do that on a single 
list.  Filtering is not effective as it relies on putting [name] in the 
subject, which is inadequate.

The other major benefit of list partitioning is the archives.  It sucks 
finding somthing particular in the archive of commons, or just browsing 
last weeks traffic, but is simple on a dedicated list.

If you are interested in HttpClient, and want to participate, please, 
just subscribe to the list.  You have the power.


when we decided to push them out onto their own list, i thought that 
all votes were supposed to remain on the main list. i don't recall 
seeing any VOTEs on this list about new committers or about releases. 
(i'm not saying that there's been any impropriety - just that if there 
was, there's no way that i'd know.)

This was a grey area.  When HttpClient got back to critical mass where 
we could sustain our own votes, we started voting on our own. I think 
that this is just natural evolution.  We have been voting on releases, 
release plans, committers and are about to vote on some amendments to 
coding style.  We are doing our best to do everything right and you are 
just a link away from joining in: 
mailto:[EMAIL PROTECTED]

The best voting solution is not to merge httpclient traffic back to 
commons but to create a dedicated VOTE list.  Committers should be 
subsribed to as as part of account creation and contributors could 
subscribe to if they are interested.  Just think how nice that would be 
for the PMC folks trying to monitor what was going on without having to 
sort through 5000 messages a month.


possible component groupings


BeanUtils, CLI, Collections, Discovery, Lang, Logging should have 
enough momentum to a become a viable core grouping.

JXPath, jelly, betwixt, digester may be big enough to become a viable 
xml grouping

pool, DBCP could fit together into a cache group - but i think that it 
would be too small to be viable.

httpclient, latka, fileupload could fit together into a http group - 
but again, probably too small


Logical or not, these groupings are arbitrairy.  Why enforce a grouping? 
Give users the finest granularity possible, and then they can choose 
their own group of lists to join based on their interests.  And have 
trivial filtering to boot.  If you REALLY wanted to have groupings, you 
could compose them from the fine grained lists.  A meta list of lists as 
it were, where the meta list would subscribe to other lists and the 
users could subscribe to the meta lists or the fine grained lists as it 
suited them.

-jsd
Jandalf
Jeff Dever




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Time for more mailing lists ?

[Jeffrey Dever]

I think that HttpClient was the last list to be partitioned.  We are 
quite happy with it.  The issue that remains is with voting.  We are 
still part of commons and still want voting input from commons in 
general.  A *commons-vote* list would be very excellent in helping keep 
us all together on major issues while still partitioning traffic 
efficiently.

Costin Manolache wrote:

This has been discussed in the past - but the traffic on commons is 
getting bigger as we add more very active components.

We could split the list based on category - expression languages (jxpath,
jexl, jsp-el, etc ), util libraries ( logging, discovery, modeler,
collections, etc ). 

Opinions ? Should we vote ?

Costin   


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Checkstyle problems

[Jeffrey Dever]

Yes.  It started when I added the checkstyle.properties file.  I don't 
know why maven started handing off the html files to checkstyle, and 
tried to fix it with those specific properties but they had no effect. 
The report still generates OK, so I had not yet pursued it further.

Mike Bowler wrote:

With the latest checkins, I'm no longer able to run checkstyle.  It's 
complaining that it can't parse the .html files.  The 
project.properties explicitly say that it should only check java files 
but it doesn't seem to be obeying this.  Is anyone else seeing this 
problem?

The target I'm running is:
maven checkstyle:generate-report



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Proposed style change

[Jeffrey Dever]

HttpClient.

As of the 2.0 Alpha 2 release, the maven checkstyle plugin produced 
about 2500 style violations.  We created a task to clean this up by the 
beta release, and Mike has taken on this task.

There are a few other coding conventions used in other Jakarta projects, 
as well as other commons projects.  We are reviewing these in 
consideration of our own checkstyle enforced coding standard.

We welcome any comments you may have.

Jandalf.


Martin van den Bemt wrote:

Which project are you talking about ? 

Mvgr,
Martin

On Mon, 2003-01-27 at 17:29, Mike Bowler wrote:
 

I am going through the code and changing it to conform to the style as 
per checkstyle.  There are two places that I think we may want to be a 
little more lenient than the defaults and so I'm putting them here for 
discussion.

   




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: help building commons with maven

[Jeffrey Dever]

Well, its related to the NTLM support in HttpClient.  A few tests fail, 
but I would suspect any NTLM use in 1.3 would fail similarly.  Most of 
the httpclient guys have been working on 1.4 (I did the release build in 
1.4) and the gump builds don't fail so I guess its using 1.4 as well.

I've brought the issue up on the commons-httpclient-dev list so we 
should move the conversation over there.

Jandalf.


Henri Yandell wrote:

Yeah. Linux jdk 1.3. Sun's.

Hen

On Sun, 26 Jan 2003 [EMAIL PROTECTED] wrote:

 

 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: help building commons with maven

[Jeffrey Dever]

We care!

[EMAIL PROTECTED] wrote:


Henri Yandell <[EMAIL PROTECTED]> wrote on 25/01/2003 05:33:50 AM:

 

On Fri, 24 Jan 2003, Craig R. McClanahan wrote:

   


I'm not a Maven guru, but it's not clear to me that the maven.xml and
project.xml files for all of the Commons projects have been kept up to
date (or even created in the first place), particularly for those
projects that started out with Ant based builds.
 

Maven itself hasn't had a release for quite a while. I think the
project.xml's and maven.xml's ought to be okayish at the moment, but 
   

when
 

they release b8 I bet a lot will break and take months to get fixed.
   

Gee thanks!

If you care, let me know, and I'll work with you on getting the 
descriptors up to date when b8 is released.

--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[Announce] HttpClient 2.0 Alpha 2 Released!

[Jeffrey Dever]

After many months and a great resurgence of developers, the new build of 
/HttpClient/ is finally here. The new group of developers has done 
extensive refactoring to move the project along the new vision. The code 
base has reached a significant level of maturity and we expect that the 
beta builds will come quickly and that the final release of 2.0 is not 
far away!

This is the first Maven based release with distributions and the website 
all generated by maven goals.  While it has been a long time coming for 
this release drop, (I won't even say *how* long) we will be focused on 
bug fixes and improvements as we stabilize towards a final release of 2.0.


Check it out on the website:
http://jakarta.apache.org/commons/httpclient/


The entire HttpClient development team.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: help building commons with maven

[Jeffrey Dever]

A few more questions:

Where does the nice navigation bar on the left come from?  There is one 
string I want to change (HTTP Client to HttpClient) and a few entries 
that should be removed (like Contributors which is redundant compared to 
Project Info -> Project Team).  There are a few other things that we are 
not using as well.

I see that some projects that are using maven are importing the commons 
project.xml into their own project.xml files.  HttpClient does this. 
But I still don't see where the nav bar comes from, or how to control it.

-jsd

Martin Cooper wrote:

On Sat, 25 Jan 2003, Jeffrey Dever wrote:

 

Yea, worked for me too.  I have been making some changes in there, so
you need a clean checkout.  (does maven do a checkout of the source
files, or just compiles what is already checkout and is local?)
   


Maven will build whatever is on your local disk, so you need to do at least
a 'cvs up' to get the latest before you build.

--
Martin Cooper


 

-jsd

Martin Cooper wrote:

   

On Sat, 25 Jan 2003, Henri Yandell wrote:



 

On Fri, 24 Jan 2003, Martin Cooper wrote:



   

On Fri, 24 Jan 2003, Henri Yandell wrote:



 

I've done a cvs update on commons, and have successfully built [well it
fails on a test] httpclient with just:  cd httpclient; maven


   

I just tried building HttpClient and it built and unit tested just fine
(apart from one deprecation warning). That's with Maven b7, and I've never
tried building HttpClient before.


 

test:test:
  [junit] dir attribute ignored if running in the same VM
  [junit] Running org.apache.commons.httpclient.TestNoHost
  [junit] Tests run: 161, Failures: 0, Errors: 2, Time elapsed: 1.89 sec
  [junit] [ERROR] TEST org.apache.commons.httpclient.TestNoHost FAILED

is the error I get.


   

Odd. That worked for me.

test:test:
  [junit] dir attribute ignored if running in the same VM
  [junit] Running org.apache.commons.httpclient.TestNoHost
  [junit] Tests run: 161, Failures: 0, Errors: 0, Time elapsed: 8.232 sec

--
Martin Cooper




 

Hen


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




   

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




 

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


   



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


 



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

Re: help building commons with maven

[Jeffrey Dever]

Yea, worked for me too.  I have been making some changes in there, so 
you need a clean checkout.  (does maven do a checkout of the source 
files, or just compiles what is already checkout and is local?)

-jsd

Martin Cooper wrote:

On Sat, 25 Jan 2003, Henri Yandell wrote:

 

On Fri, 24 Jan 2003, Martin Cooper wrote:

   

On Fri, 24 Jan 2003, Henri Yandell wrote:

 

I've done a cvs update on commons, and have successfully built [well it
fails on a test] httpclient with just:  cd httpclient; maven
   

I just tried building HttpClient and it built and unit tested just fine
(apart from one deprecation warning). That's with Maven b7, and I've never
tried building HttpClient before.
 

test:test:
   [junit] dir attribute ignored if running in the same VM
   [junit] Running org.apache.commons.httpclient.TestNoHost
   [junit] Tests run: 161, Failures: 0, Errors: 2, Time elapsed: 1.89 sec
   [junit] [ERROR] TEST org.apache.commons.httpclient.TestNoHost FAILED

is the error I get.
   


Odd. That worked for me.

test:test:
   [junit] dir attribute ignored if running in the same VM
   [junit] Running org.apache.commons.httpclient.TestNoHost
   [junit] Tests run: 161, Failures: 0, Errors: 0, Time elapsed: 8.232 sec

--
Martin Cooper


 

Hen


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


   



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: help building commons with maven

[Jeffrey Dever]

I re-downloaded it and reinstalled in another location.  Now it "just 
works".  Not sure what the root cause was, will investigate later.  Too 
busy with updating the httpclient xdocs to worry and am just happy I can 
maven build.

-jsd

Martin Cooper wrote:

On Fri, 24 Jan 2003, Henri Yandell wrote:

 

I've done a cvs update on commons, and have successfully built [well it
fails on a test] httpclient with just:  cd httpclient; maven

So something weird is up.

Maybe your b7 is damaged? You could try reinstalling and see if that fixes
it? [yes, I've been using Windows all week!]

Hopefully a 3rd person can give it a try so we can see which one of us has
the weird setup.
   


I just tried building HttpClient and it built and unit tested just fine
(apart from one deprecation warning). That's with Maven b7, and I've never
tried building HttpClient before.

--
Martin Cooper


 

Hen

On Fri, 24 Jan 2003, Jeffrey Dever wrote:

   

b7

$MAVEN_HOME is set correctly and $MAVEN_HOME/bin is in my path.  I'm
perplexed.

-jsd

Henri Yandell wrote:

 

java:jar is afaik, the default goal to run. it's basically 'compile'.

logging and lang both work for me. I'm on the latest stable maven, b7.

What verison are you on?

On Fri, 24 Jan 2003, Jeffrey Dever wrote:



   

I have tried running maven in a commons subdirectory, such as logging
and httpclient.  maven does go away and download the dependancies, but
then reports:

[ERROR] BUILD FAILED
[ERROR] Goal "java:jar" does not exist in this project.
Total time:  14 seconds

I don't see where this goal is defined.  Its not in the project.xml for
the particular project or commons, and does not appear to come from the
common maven.xml file either.

-jsd

Henri Yandell wrote:



 

If you go into a particular component and type 'maven', it should build
that project. I tend to use maven and maven site.

However, how you do the big build of all components at the same time, I'm
also clueless on.

Hen

On Fri, 24 Jan 2003, Jeffrey Dever wrote:





   

In my local checkout of jakarta-commons, when I run *maven -g* I only
the follwoing non documented goals:
build
build:start
deploy-front-end-site
site
site-front-end

When I run *maven build:start* I get:

BUILD SUCCESSFUL
Total time:  14 seconds

But in reality it did nothing, no other output, no generated files.
None of the other targets to anything useful either.  I have tried with
mavenb5 and b7 running on a linux box.

How do we build commons with maven?  How do I build a particular
component withing commons?  I couldn't find any instructions on this.

-jsd



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






 

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






   

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




 

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




   

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


 

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


   



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


 



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

Re: help building commons with maven

[Jeffrey Dever]

Doing that now ... thanks.

Martin van den Bemt wrote:


Looks like your xml is treated as text.. 
You better move this thread to maven-dev or maven-user.. :)

Mvgr,
Martin

On Fri, 2003-01-24 at 19:54, Jeffrey Dever wrote:
 

There is definately somthing wrong with my environment.  When I run that 
i get:

build:

BUILD SUCCESSFUL
Total time:  31 seconds

But it was completely unsuccessful, other than downloading the dependancies.


Henri Yandell wrote:

   

By the way, building commons itself seems to give:

[ERROR] File.. /usr/local/javalib/maven-1.0-beta-7/plugins/maven-reactor-plugin-1.0/plugin.jelly
[ERROR] Element... reactor:reactor
[ERROR] Line.. 32
[ERROR] Column 9
[ERROR] The content of elements must consist of well-formed character data or markup.

Hen

On 24 Jan 2003, Martin van den Bemt wrote:



 

Probably. Never looked at a solution though (using maven head from
31/12/2002 on windows and the latest maven-head on linux afaik).
If I have time i'll see if maven head is usable for commons..

Mvgr,
Martin

On Fri, 2003-01-24 at 19:34, Henri Yandell wrote:
  

   

So what you're saying is that a new maven user cannot build, but an old
maven user can? Because us old users of maven have the snapshots, but the
new ones do not?

So another way to solve it would be via a zipped patch the new user could
overlay on their maven-home?

Hen

On 24 Jan 2003, Martin van den Bemt wrote:



 

There are known problems with the b7 installation if you do that at
present (as far as I understood), since maven is depending on snapshots
and the snapshots are not currently anymore working on the b7 one..

So maybe you going to have to use maven-head because of that.

If I am wrong, please correct me :)

Mvgr,
Martin

On Fri, 2003-01-24 at 19:27, Henri Yandell wrote:
  

   

I've done a cvs update on commons, and have successfully built [well it
fails on a test] httpclient with just:  cd httpclient; maven

So something weird is up.

Maybe your b7 is damaged? You could try reinstalling and see if that fixes
it? [yes, I've been using Windows all week!]

Hopefully a 3rd person can give it a try so we can see which one of us has
the weird setup.

Hen

On Fri, 24 Jan 2003, Jeffrey Dever wrote:



 

b7

$MAVEN_HOME is set correctly and $MAVEN_HOME/bin is in my path.  I'm
perplexed.

-jsd

Henri Yandell wrote:

  

   

java:jar is afaik, the default goal to run. it's basically 'compile'.

logging and lang both work for me. I'm on the latest stable maven, b7.

What verison are you on?

On Fri, 24 Jan 2003, Jeffrey Dever wrote:





 

I have tried running maven in a commons subdirectory, such as logging
and httpclient.  maven does go away and download the dependancies, but
then reports:

[ERROR] BUILD FAILED
[ERROR] Goal "java:jar" does not exist in this project.
Total time:  14 seconds

I don't see where this goal is defined.  Its not in the project.xml for
the particular project or commons, and does not appear to come from the
common maven.xml file either.

-jsd

Henri Yandell wrote:



  

   

If you go into a particular component and type 'maven', it should build
that project. I tend to use maven and maven site.

However, how you do the big build of all components at the same time, I'm
also clueless on.

Hen

On Fri, 24 Jan 2003, Jeffrey Dever wrote:







 

In my local checkout of jakarta-commons, when I run *maven -g* I only
the follwoing non documented goals:
build
build:start
deploy-front-end-site
site
site-front-end

When I run *maven build:start* I get:

BUILD SUCCESSFUL
Total time:  14 seconds

But in reality it did nothing, no other output, no generated files.
None of the other targets to anything useful either.  I have tried with
mavenb5 and b7 running on a linux box.

How do we build commons with maven?  How do I build a particular
component withing commons?  I couldn't find any instructions on this.

-jsd



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






  

   

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








 

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




  

   

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






 

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


  

   

--
To un

Re: help building commons with maven

[Jeffrey Dever]

There is definately somthing wrong with my environment.  When I run that 
i get:

build:

BUILD SUCCESSFUL
Total time:  31 seconds

But it was completely unsuccessful, other than downloading the dependancies.


Henri Yandell wrote:

By the way, building commons itself seems to give:

[ERROR] File.. /usr/local/javalib/maven-1.0-beta-7/plugins/maven-reactor-plugin-1.0/plugin.jelly
[ERROR] Element... reactor:reactor
[ERROR] Line.. 32
[ERROR] Column 9
[ERROR] The content of elements must consist of well-formed character data or markup.

Hen

On 24 Jan 2003, Martin van den Bemt wrote:

 

Probably. Never looked at a solution though (using maven head from
31/12/2002 on windows and the latest maven-head on linux afaik).
If I have time i'll see if maven head is usable for commons..

Mvgr,
Martin

On Fri, 2003-01-24 at 19:34, Henri Yandell wrote:
   

So what you're saying is that a new maven user cannot build, but an old
maven user can? Because us old users of maven have the snapshots, but the
new ones do not?

So another way to solve it would be via a zipped patch the new user could
overlay on their maven-home?

Hen

On 24 Jan 2003, Martin van den Bemt wrote:

 

There are known problems with the b7 installation if you do that at
present (as far as I understood), since maven is depending on snapshots
and the snapshots are not currently anymore working on the b7 one..

So maybe you going to have to use maven-head because of that.

If I am wrong, please correct me :)

Mvgr,
Martin

On Fri, 2003-01-24 at 19:27, Henri Yandell wrote:
   

I've done a cvs update on commons, and have successfully built [well it
fails on a test] httpclient with just:  cd httpclient; maven

So something weird is up.

Maybe your b7 is damaged? You could try reinstalling and see if that fixes
it? [yes, I've been using Windows all week!]

Hopefully a 3rd person can give it a try so we can see which one of us has
the weird setup.

Hen

On Fri, 24 Jan 2003, Jeffrey Dever wrote:

 

b7

$MAVEN_HOME is set correctly and $MAVEN_HOME/bin is in my path.  I'm
perplexed.

-jsd

Henri Yandell wrote:

   

java:jar is afaik, the default goal to run. it's basically 'compile'.

logging and lang both work for me. I'm on the latest stable maven, b7.

What verison are you on?

On Fri, 24 Jan 2003, Jeffrey Dever wrote:



 

I have tried running maven in a commons subdirectory, such as logging
and httpclient.  maven does go away and download the dependancies, but
then reports:

[ERROR] BUILD FAILED
[ERROR] Goal "java:jar" does not exist in this project.
Total time:  14 seconds

I don't see where this goal is defined.  Its not in the project.xml for
the particular project or commons, and does not appear to come from the
common maven.xml file either.

-jsd

Henri Yandell wrote:



   

If you go into a particular component and type 'maven', it should build
that project. I tend to use maven and maven site.

However, how you do the big build of all components at the same time, I'm
also clueless on.

Hen

On Fri, 24 Jan 2003, Jeffrey Dever wrote:





 

In my local checkout of jakarta-commons, when I run *maven -g* I only
the follwoing non documented goals:
build
build:start
deploy-front-end-site
site
site-front-end

When I run *maven build:start* I get:

BUILD SUCCESSFUL
Total time:  14 seconds

But in reality it did nothing, no other output, no generated files.
None of the other targets to anything useful either.  I have tried with
mavenb5 and b7 running on a linux box.

How do we build commons with maven?  How do I build a particular
component withing commons?  I couldn't find any instructions on this.

-jsd



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






   

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






 

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




   

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




 

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


   

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


 


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


   

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


 


--
To unsubscribe, e-mail:   <mailto:[EMAI

Re: help building commons with maven

[Jeffrey Dever]

b7

$MAVEN_HOME is set correctly and $MAVEN_HOME/bin is in my path.  I'm 
perplexed.

-jsd

Henri Yandell wrote:

java:jar is afaik, the default goal to run. it's basically 'compile'.

logging and lang both work for me. I'm on the latest stable maven, b7.

What verison are you on?

On Fri, 24 Jan 2003, Jeffrey Dever wrote:

 

I have tried running maven in a commons subdirectory, such as logging
and httpclient.  maven does go away and download the dependancies, but
then reports:

[ERROR] BUILD FAILED
[ERROR] Goal "java:jar" does not exist in this project.
Total time:  14 seconds

I don't see where this goal is defined.  Its not in the project.xml for
the particular project or commons, and does not appear to come from the
common maven.xml file either.

-jsd

Henri Yandell wrote:

   

If you go into a particular component and type 'maven', it should build
that project. I tend to use maven and maven site.

However, how you do the big build of all components at the same time, I'm
also clueless on.

Hen

On Fri, 24 Jan 2003, Jeffrey Dever wrote:



 

In my local checkout of jakarta-commons, when I run *maven -g* I only
the follwoing non documented goals:
build
build:start
deploy-front-end-site
site
site-front-end

When I run *maven build:start* I get:

BUILD SUCCESSFUL
Total time:  14 seconds

But in reality it did nothing, no other output, no generated files.
None of the other targets to anything useful either.  I have tried with
mavenb5 and b7 running on a linux box.

How do we build commons with maven?  How do I build a particular
component withing commons?  I couldn't find any instructions on this.

-jsd



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




   

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




 

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


   



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


 



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

Re: help building commons with maven

[Jeffrey Dever]

I have tried running maven in a commons subdirectory, such as logging 
and httpclient.  maven does go away and download the dependancies, but 
then reports:

[ERROR] BUILD FAILED
[ERROR] Goal "java:jar" does not exist in this project.
Total time:  14 seconds

I don't see where this goal is defined.  Its not in the project.xml for 
the particular project or commons, and does not appear to come from the 
common maven.xml file either.

-jsd

Henri Yandell wrote:

If you go into a particular component and type 'maven', it should build
that project. I tend to use maven and maven site.

However, how you do the big build of all components at the same time, I'm
also clueless on.

Hen

On Fri, 24 Jan 2003, Jeffrey Dever wrote:

 

In my local checkout of jakarta-commons, when I run *maven -g* I only
the follwoing non documented goals:
 build
 build:start
 deploy-front-end-site
 site
 site-front-end

When I run *maven build:start* I get:

BUILD SUCCESSFUL
Total time:  14 seconds

But in reality it did nothing, no other output, no generated files.
None of the other targets to anything useful either.  I have tried with
mavenb5 and b7 running on a linux box.

How do we build commons with maven?  How do I build a particular
component withing commons?  I couldn't find any instructions on this.

-jsd



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


   



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


 



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

help building commons with maven

[Jeffrey Dever]

In my local checkout of jakarta-commons, when I run *maven -g* I only 
the follwoing non documented goals:
 build
 build:start
 deploy-front-end-site
 site
 site-front-end

When I run *maven build:start* I get:

BUILD SUCCESSFUL
Total time:  14 seconds

But in reality it did nothing, no other output, no generated files. 
None of the other targets to anything useful either.  I have tried with 
mavenb5 and b7 running on a linux box.

How do we build commons with maven?  How do I build a particular 
component withing commons?  I couldn't find any instructions on this.

-jsd



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

HttpClient bug emails finished

[Jeffrey Dever]

Sorry about all the bugzilla emails.  I moved a bunch of bugs over to 
the commons-httpclient-dev mailing list from this list, but each change 
was reported by bugzilla untill they were moved.

The default owner of httpclient bugs is still commons (unable to 
configure on a component basis) so there will still be some stray 
bugzilla messages here, but we'll try to keep it to a minimum.

Thanks for the patience.
-jsd


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[httpclient] request for comments for HttpClient/HttpMultiClient

[Jeffrey Dever]

Just a heads up that we are looking at a preliminary patch for merging 
the HttpClient and HttpMultiClient interfaces.  This has been a major 
issue blocking a release and it is great to finally have a patch for it 
(thanks to Michael Becke!)

If anyone is interested, please preuse the patch attached to bugzilla 
and post comments to the commons-httpclient-dev mailing list.  The 
changes are significant so I just wanted everyone to be aware.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10798

-jsd


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-commons/httpclient project.xml

[Jeffrey Dever]

You got it!

Adrian Sutton wrote:


Noticed this come through the cvs commits - thanks for the recogition.
Could I be picky and request that an Organisation tag be added akin to:

Ephox

Since they're paying me to do the work I figure they should get a mention.
:)

Thanks.

Adrian Sutton, Software Engineer
Ephox Corporation
www.ephox.com


This email and any files transmitted with it are confidential and intended
solely for the use of the individual to whom they are addressed. Opinions
contained in this email do not necessarily reflect the opinions of Ephox
Corporation.
If you have received this email in error please notify the sender
immediately and delete all copies of the correspondence from your computer
and/or computer network. No warranty is given that this message upon its
receipt is virus free and the sender in this respect accepts no liability.



-Original Message-
From: [EMAIL PROTECTED] [mailto:jsdever@;apache.org]
Sent: Thursday, 31 October 2002 6:37 PM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-commons/httpclient project.xml


jsdever 2002/10/31 00:37:03

 Modified:httpclient project.xml
 Log:
 Update the contributors and committer.
 Update the dependancy of commons-logging 1.0.2

 Revision  ChangesPath
 1.8   +19 -4 jakarta-commons/httpclient/project.xml

 Index: project.xml
 ===
 RCS file: /home/cvs/jakarta-commons/httpclient/project.xml,v
 retrieving revision 1.7
 retrieving revision 1.8
 diff -u -r1.7 -r1.8
 --- project.xml	8 Sep 2002 05:51:42 -	1.7
 +++ project.xml	31 Oct 2002 08:37:03 -	1.8
 @@ -10,7 +10,7 @@
Commons HttpClient


 -Embeddable Http Client
 +Embeddable HTTP Client



 @@ -56,16 +56,31 @@
Independent consultant
Java Developer
  
 -
 +
 +
 +  Sung-Gu
 +  jericho
 +  jericho_at_pache_org
 +  
 +  Java Developer
 +




 +
  
  	Ryan Lubke
  	[EMAIL PROTECTED]
  
 +
 +
 +	Adrian Sutton
 +	adrian.sutton_at_ephox_com
 +
 +

 +



 @@ -76,11 +91,11 @@

  
commons-logging
 -  1.0.1
 +  1.0.2
  

 -

 +







--
To unsubscribe, e-mail:

For additional commands, e-mail:




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclientHttpURL.java

[Jeffrey Dever]

Ooopss, really?  just one per each project?
Hmmm.. only putting classes in the sub packages?
I haven't known that...  :( And, I think, that's so not reasonable
and inconvient to add just a few or several classes for my current use.

If so, could you please point it out where I can find those rules?


This is the only link I have for that type of information:
http://jakarta.apache.org/commons/index.html
I still think a subpackage in httpclient is a reasonable solution.


Actually, my purpose for HttpClient was just to support correct URI
encoding mechanism in general and to adapt those thingys
(I mean I haven't been not interested in improving HttpClient,
because, I believe, it's going  forward well by you guys... )


Right, with your help it has.  But having a few related classes that 
"support correct URI encoding" still suits your personal goals and fits 
the vision for HttpClient as well.  

-jsd


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: CVSROOT and Eclipse

[Jeffrey Dever]

Absolutely right.

I had to add source folders for src/java, src/test and 
src/test-webapp/src, add jce.jar, junit.jar, jsse.jar, but I can run ant 
now to compile.  Very excellent!

-jsd

Martin van den Bemt wrote:

Go to the cvs repositories perspective. In the little toolbar you see a
little dropdown sign. If you click it you have two options : Show
Folders and Show Modules. Yours is probably on show modules and it
should be show folders..

Mvgr,
Martin

On Wed, 2002-10-30 at 01:23, Jeffrey Dever wrote:
 

But I don't see the jakarta projects, just the top level ones line httpd ...


   

Jeffrey Dever <[EMAIL PROTECTED]> wrote on 29/10/2002 07:07:17 PM:



 

Is anyone using Eclipse to access the CVS repository?  I have able to 
add a CVS location for cvs.apache.org, but the repository location is 
unclear.  There is /x1/home/cvs/jakarta-commons and 
/home/cvs/jakarta-commons but there are no CVSROOT directories in them.

Questions:
1) is cvs.apache.org:home/cvs/jakarta-commons the correct location for 
the cvs repository?
2) why are there no CVSROOT entries?
  

   

Hi Jeff,

I use eclipse regularly to access cvs.

host: cvs.apache.org
cvsroot: /home/cvs (if logging in with your apache id) or /home/cvspublic 
(if anoncvs'ing)

Then expand HEAD



 

BTW: I'm a hardcore command line vim/ant type, but Eclipse is SO 
impressive that its no fun working at the command line anymore :-(
  

   

--
dIon Gillard, Multitask Consulting
Work:  http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers




--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>




 



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>


   




--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>


 



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>

Re: cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclientHttpURL.java

[Jeffrey Dever]

Sung-Gu,
Creating a new package org.apache.commons.uri implies creating a new 
Jakarta Commons subproject called URI.  Are you suggesting that we start 
a new project for this?  

Instead of saying HttpURL should be useful outside of HttpClient, you 
should have a related set of classes that are useful outside of 
httpclient.  It does not make much sense to created an Object Oriented 
reusable class  which isolated from others in its package.  HttpURL 
should use NameValuePair directly to provide for the simplest interface 
and reduce object conversion inside of HttpClient.  Then HttpURL and 
NameValuePair can be taken out of HttpClient (if desired at some point) 
and used together in somthing else.

You could move these two classes into the httpclient.util package to 
clearly denote them as classes that can be removed into own subproject 
in the future.

Lets focus on making HttpClient clean, powerful and efficient right now.

-jsd

Sung-Gu wrote:

- Original Message -
From: "Ortwin Glück" <[EMAIL PROTECTED]>

 

Okay. But this class is in the package httpclient. If it was a generic
class then it should be in a package unrelated to httpclient. I am still
   


Yes, I think so.
So I have asked about it before I committed them that I don't know
which place would be ok.

This time, I suggest my recent URI related things to move to the new
package,
probably, org.apache.commons.uri.
+1

Or other suggestions?

Sung-Gu

 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: CVSROOT and Eclipse

[Jeffrey Dever]

But I don't see the jakarta projects, just the top level ones line httpd ...



Jeffrey Dever <[EMAIL PROTECTED]> wrote on 29/10/2002 07:07:17 PM:

 

Is anyone using Eclipse to access the CVS repository?  I have able to 
add a CVS location for cvs.apache.org, but the repository location is 
unclear.  There is /x1/home/cvs/jakarta-commons and 
/home/cvs/jakarta-commons but there are no CVSROOT directories in them.

Questions:
1) is cvs.apache.org:home/cvs/jakarta-commons the correct location for 
the cvs repository?
2) why are there no CVSROOT entries?
   


Hi Jeff,

I use eclipse regularly to access cvs.

host: cvs.apache.org
cvsroot: /home/cvs (if logging in with your apache id) or /home/cvspublic 
(if anoncvs'ing)

Then expand HEAD

 

BTW: I'm a hardcore command line vim/ant type, but Eclipse is SO 
impressive that its no fun working at the command line anymore :-(
   

--
dIon Gillard, Multitask Consulting
Work:  http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers




--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>


 





--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>

Re: CVSROOT and Eclipse

[Jeffrey Dever]

No sooner did I post this than I realized that I was trying one 
directory too deep.  The repository path should just be /home/cvs.


Jeffrey Dever wrote:

Is anyone using Eclipse to access the CVS repository?  I have able to 
add a CVS location for cvs.apache.org, but the repository location is 
unclear.  There is /x1/home/cvs/jakarta-commons and 
/home/cvs/jakarta-commons but there are no CVSROOT directories in them.

Questions:
1) is cvs.apache.org:home/cvs/jakarta-commons the correct location for 
the cvs repository?
2) why are there no CVSROOT entries?

BTW: I'm a hardcore command line vim/ant type, but Eclipse is SO 
impressive that its no fun working at the command line anymore :-(





--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>

CVSROOT and Eclipse

[Jeffrey Dever]

Is anyone using Eclipse to access the CVS repository?  I have able to 
add a CVS location for cvs.apache.org, but the repository location is 
unclear.  There is /x1/home/cvs/jakarta-commons and 
/home/cvs/jakarta-commons but there are no CVSROOT directories in them.

Questions:
1) is cvs.apache.org:home/cvs/jakarta-commons the correct location for 
the cvs repository?
2) why are there no CVSROOT entries?

BTW: I'm a hardcore command line vim/ant type, but Eclipse is SO 
impressive that its no fun working at the command line anymore :-(

-jsd


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[HttpClient] cvs messages

[Jeffrey Dever]

Currently the httpclient commit messages are still being sent to the 
commons cvs list.  I would like to have the commit messages moved to the 
httpclient list to keep everything httpclient in one place.  Rodney made 
a point that it would be nice to have people in commons exposed to the 
commit messages so that they still know what it going on.  I would 
suggest that people that want to keep in touch with httpclient just 
subscribe to the httpclient list, and not require:
a) people not interested to filter it out and pay for the bandwidth
b) force the httpclient only types to subscribe to the commons list

I'd like to get the cvs messages from httpclient moved to the httpclient 
mailing list.  Who do I ask to have this done?

BTW: I have not been paying too close attention on what is happening 
with the reorg, but I don't that should be a concern.

-jsd


Waldhoff, Rodney wrote:

I'm not sure that's what we (or at least I) really want to do (especially in light of some of the traffic on reorg@apache et al), although I'm not sure it isn't.  Arguably there is some value in the greater commons-dev community being able to see what's going on in the jakarta-commons/httpclient tree.

Can we discuss this on the main commons-dev list?

-Original Message-
From: Jeffrey Dever [mailto:jsdever@;sympatico.ca]
Sent: Tuesday, October 22, 2002 2:44 PM
To: Commons HttpClient Project
Subject: Re: Where are the CVS messages?


I have tried talking to several people to get that done but to no avail. 
Anyone know who can redirect the commit messages in httpclient to 
commons-httpclient-dev?  As well as add a commons-httpclient-dev user to 
bugzilla?


Martin Cooper wrote:

 



   

-Original Message-
From: Ortwin Glück [mailto:ortwin.glueck@;nose.ch]
Sent: Tuesday, October 22, 2002 11:36 AM
To: [EMAIL PROTECTED]
Subject: Where are the CVS messages?


I made quite a lot of commits during the last two days. But I 
didn't see 
a single commit message posted to the list. Is this broken or do they 
get sent to  commons-dev (which I do not read)?
  

 

They're apparently posted to [EMAIL PROTECTED] - I've been
seeing your commits there. ;-)

--
Martin Cooper




   





--
To unsubscribe, e-mail:   <mailto:commons-httpclient-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-httpclient-dev-help@;jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:commons-httpclient-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-httpclient-dev-help@;jakarta.apache.org>


 





--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>