svn commit: r816076 - /tomcat/tc6.0.x/trunk/STATUS.txt

2009-09-17 Thread jfclere
Author: jfclere
Date: Thu Sep 17 07:05:22 2009
New Revision: 816076

URL: http://svn.apache.org/viewvc?rev=816076&view=rev
Log:
My vote.

Modified:
tomcat/tc6.0.x/trunk/STATUS.txt

Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=816076&r1=816075&r2=816076&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Sep 17 07:05:22 2009
@@ -319,7 +319,7 @@
   Note: Patch cannot be applied until tc-native 1.1.17 has been released
 since it depends on a new native method
   http://svn.apache.org/viewvc?rev=815418&view=rev
-  +1: markt
+  +1: markt, jfclere
   -1: 
 
 * Fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=47161



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 47760] Ant deploy task's config attribute not working

2009-09-17 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=47760

--- Comment #2 from Uwe Günther  2009-09-17 08:53:26 PDT ---
I did a bit of investigation in this one.:

1) It seems to me this isn't a bug.
2) It seems to me you are mixing up two different deployment methods. 

But let me explain it:

>From my point of view there is 

a) a local  deployment functionality and
b) a remote deployment functionality  

In a) you can deploy a war file or a webapp directory to a local installed
tomcat with or without a context fragment. Note: You have here a hard
precondition: All files are local to the tomcat you want to deploy to.

In this case your ant target should look like this:

  

present:${present}

  


In b) you can only deploy a war file via HTTP PUT to your remote tomcat
installation via the manager servlet. In this case you have to put your context
fragment (pr.xml in your case) in META-INF/context.xml in your *.war file. You
have to do this because it is not possible to upload a config file (context
fragment aka context.xml) to a remote server via the  manager webapp which gets
used by the deploy task.

In this case your ant target should look like this:

  

present:${present}

  


Note: In b) Your context fragment from build/pr.xml has to be in
${app.name}.war!/META-INF/context.xml. While the deployment it gets copied to
$CATALINA_BASE/conf/[engine]/[host]/[context].xml. In your case this would be
$CATALINA_BASE/conf/Catalina/localhost/pr.xml.


For more information you can consult the following two links:







If you lock in the execute methode of the AntDeploy Task your observations
become really obvious:

// line 182
if ((war == null) && (config != null)) {
sb.append("&config=");
sb.append(URLEncoder.encode(config, getCharset()));
}
if ((war == null) && (localWar != null)) {
sb.append("&war=");
sb.append(URLEncoder.encode(localWar, getCharset()));
}
// to 189


-- 
Kind Regards
Uwe Günther

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 47760] Ant deploy task's config attribute not working

2009-09-17 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=47760

Uwe Günther  changed:

   What|Removed |Added

 CC||u...@cscc.de

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



svn commit: r816252 - /tomcat/trunk/java/org/apache/juli/FileHandler.java

2009-09-17 Thread fhanik
Author: fhanik
Date: Thu Sep 17 16:07:13 2009
New Revision: 816252

URL: http://svn.apache.org/viewvc?rev=816252&view=rev
Log:
Enable the ability to disable the buffered writer. This does bunch of copying 
when writing using an async thread there is no need for such a thing

Modified:
tomcat/trunk/java/org/apache/juli/FileHandler.java

Modified: tomcat/trunk/java/org/apache/juli/FileHandler.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/juli/FileHandler.java?rev=816252&r1=816251&r2=816252&view=diff
==
--- tomcat/trunk/java/org/apache/juli/FileHandler.java (original)
+++ tomcat/trunk/java/org/apache/juli/FileHandler.java Thu Sep 17 16:07:13 2009
@@ -292,11 +292,11 @@
 String pathname = dir.getAbsolutePath() + File.separator +
 prefix + date + suffix;
 String encoding = getEncoding();
-OutputStream os = new BufferedOutputStream(new FileOutputStream(
-pathname, true),bufferSize);
+FileOutputStream fos = new FileOutputStream(pathname, true);
+OutputStream os = bufferSize>0?new 
BufferedOutputStream(fos,bufferSize):fos;
 writer = new PrintWriter(
 (encoding != null) ? new OutputStreamWriter(os, encoding)
-: new OutputStreamWriter(os), true);
+   : new OutputStreamWriter(os), true);
 writer.write(getFormatter().getHead(this));
 } catch (Exception e) {
 reportError(null, e, ErrorManager.OPEN_FAILURE);



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



svn commit: r816254 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java

2009-09-17 Thread markt
Author: markt
Date: Thu Sep 17 16:10:05 2009
New Revision: 816254

URL: http://svn.apache.org/viewvc?rev=816254&view=rev
Log:
Replace parseException instance field

Modified:
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java

Modified: tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java?rev=816254&r1=816253&r2=816254&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Thu Sep 17 
16:10:05 2009
@@ -115,12 +115,6 @@
 
 
 /**
- * Any parse error which occurred while parsing XML descriptors.
- */
-protected SAXParseException parseException = null;
-
-
-/**
  * Original docBase.
  */
 protected String originalDocBase = null;
@@ -351,7 +345,8 @@
 ((StandardContext) 
context).setReplaceWelcomeFiles(true);
 }
 webDigester.push(context);
-webDigester.setErrorHandler(new ContextErrorHandler());
+ContextErrorHandler errorHandler = new 
ContextErrorHandler();
+webDigester.setErrorHandler(errorHandler);
 
 if(log.isDebugEnabled()) {
 log.debug("Parsing application web.xml file at " + 
url.toExternalForm());
@@ -359,7 +354,7 @@
 
 webDigester.parse(is);
 
-if (parseException != null) {
+if (errorHandler.getParseException() != null) {
 ok = false;
 }
 } else {
@@ -376,7 +371,6 @@
 ok = false;
 } finally {
 webDigester.reset();
-parseException = null;
 try {
 stream.close();
 } catch (IOException e) {
@@ -688,9 +682,10 @@
 digester.setClassLoader(this.getClass().getClassLoader());
 digester.setUseContextClassLoader(false);
 digester.push(context);
-digester.setErrorHandler(new ContextErrorHandler());
+ContextErrorHandler errorHandler = new ContextErrorHandler();
+digester.setErrorHandler(errorHandler);
 digester.parse(source);
-if (parseException != null) {
+if (errorHandler.getParseException() != null) {
 ok = false;
 }
 } catch (SAXParseException e) {
@@ -704,7 +699,6 @@
 ok = false;
 } finally {
 digester.reset();
-parseException = null;
 try {
 if (stream != null) {
 stream.close();
@@ -790,9 +784,10 @@
 contextDigester.setUseContextClassLoader(false);
 contextDigester.push(context.getParent());
 contextDigester.push(context);
-contextDigester.setErrorHandler(new ContextErrorHandler());
+ContextErrorHandler errorHandler = new ContextErrorHandler();
+contextDigester.setErrorHandler(errorHandler);
 contextDigester.parse(source);
-if (parseException != null) {
+if (errorHandler.parseException != null) {
 ok = false;
 }
 if (log.isDebugEnabled())
@@ -811,7 +806,6 @@
 ok = false;
 } finally {
 contextDigester.reset();
-parseException = null;
 try {
 if (stream != null) {
 stream.close();
@@ -1366,9 +1360,11 @@
 }
 
 
-protected class ContextErrorHandler
+protected static class ContextErrorHandler
 implements ErrorHandler {
 
+private SAXParseException parseException = null;
+
 public void error(SAXParseException exception) {
 parseException = exception;
 }
@@ -1381,6 +1377,9 @@
 parseException = exception;
 }
 
+public SAXParseException getParseException() {
+return parseException;
+}
 }
 
 



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Bug workflow

2009-09-17 Thread Uwe Günther
How does this work, if someone identifies a bug as NO BUG, does somebody 
set the status to "Resolved" in Bugzilla or better: How is the work flow 
here and who can close/resolve a bug?


In my case, I did some research in 47760 and IMO it isn't a bug. I but a 
comment there, CC-ed myself but what is the next step?


--
Kind Regards
Uwe Günther

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: Bug workflow

2009-09-17 Thread Tim Funk
Anyone can change a bug to any status. (Much like in wikipedia - anyone 
can edit any page) Then the community would police people who dont 
behave. Which doesn't happen often.


-Tim

Uwe Günther wrote:
How does this work, if someone identifies a bug as NO BUG, does somebody 
set the status to "Resolved" in Bugzilla or better: How is the work flow 
here and who can close/resolve a bug?


In my case, I did some research in 47760 and IMO it isn't a bug. I but a 
comment there, CC-ed myself but what is the next step?




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: Bug workflow

2009-09-17 Thread Uwe Günther

So I could set this one to resolved! Thanks Tim.

Some other questions are popping up in my head right now:

- How do you guys to choose which bugs to fix first?

  OK there are priorities, you are able to fix some bugs,
  others are more difficult to you, some are security
  relevant, 

- If you pick up a bug for fixing, do you flag that up
  somewhere in Bugzilla?

--
Kind Regards
Uwe Günther

Tim Funk wrote:
Anyone can change a bug to any status. (Much like in wikipedia - anyone 
can edit any page) Then the community would police people who dont 
behave. Which doesn't happen often.


-Tim

Uwe Günther wrote:
How does this work, if someone identifies a bug as NO BUG, does 
somebody set the status to "Resolved" in Bugzilla or better: How is 
the work flow here and who can close/resolve a bug?


In my case, I did some research in 47760 and IMO it isn't a bug. I but 
a comment there, CC-ed myself but what is the next step?




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DO NOT REPLY [Bug 47760] Ant deploy task's config attribute not working

2009-09-17 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=47760

Uwe Günther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: How do I get hold of Tomcat JDBC pool lib

2009-09-17 Thread Filip Hanik - Dev Lists

http://people.apache.org/~fhanik/jdbc-pool/

On 09/16/2009 08:57 AM, Gaurav Lohiya wrote:

Hi,

Not sure if this is the right forum to post this question.

I recently heard about the new Tomcat JDBC library, an alternative for the
DBCP lib. We see concurrency issues with the DBCP lib and are desperately
looking for a lib which can work in a highly concurrent application.

Had some questions about this lib...
1. Can this library be used with Tomcat 5.0.25. (ya I know this version was
used in the stone age :)) )
2. Is there a general release available
3. Where can I get binaries / src for the latest build (GA or beta)

Thanks in advance for your help.

- Gaurav

   



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: Bug workflow

2009-09-17 Thread Tim Funk

It differs by the person. So here is a wild guess ..

But I would guess bugs are usually fixed 1st by interest. For example: 
Crap that bug affects my stuff too, I should look at that.


Other bugs are fixed by how interesting they. For example: hmmm .. that 
seems odd - I think I'll look at that.


Other bugs are fixed because they are there and its a good thing to do.

I'm not sure about everyone else, but I think the general concensus is 
priority is useful in distinguishing enhancement vs bug. But high 
priority vs low seems ignored.


Security fixes typically don't go into bugzilla. They are reported 
privately to the security list.


-Tim

Uwe Günther wrote:

So I could set this one to resolved! Thanks Tim.

Some other questions are popping up in my head right now:

- How do you guys to choose which bugs to fix first?

  OK there are priorities, you are able to fix some bugs,
  others are more difficult to you, some are security
  relevant, 

- If you pick up a bug for fixing, do you flag that up
  somewhere in Bugzilla?



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: Bug workflow

2009-09-17 Thread Mark Thomas
Uwe Günther wrote:
> So I could set this one to resolved! Thanks Tim.

Thank you. Help closing bugs is always much appreciated.

> Some other questions are popping up in my head right now:
> 
> - How do you guys to choose which bugs to fix first?
As we say at the ASF - you scratch you own itch. We don't have a
community wide priority - each developer will prioritise them their own
my. My personal priority list is something like:
- security bugs (handled on a private list)
- regressions
- things I (or my employer*) care about
- oldest open 5.5.x or 6.0.x bug without a patch
- enhancements

* This only applies during work hours :)

There are, of course, some exceptions to my rules:
- A bug/enhancement with a patch and a good explanation (or better yet a
test case, including source code, that runs without any hassle) is
likely to get committed as soon as I see it.
- I am trying to balance bug fixing and Servlet 3 development so doing a
bit of each

> - If you pick up a bug for fixing, do you flag that up
>   somewhere in Bugzilla?

Normally no. Mainly, I think, because we rarely get clashes. Most bugs
don't take that long to fix so the likelihood of clashes is small. As
the number of open bugs decreases (there are now less than 50 open bugs
against tc5 and tc6 without patches) the chances of a clash increase.
I'd suggest if you find yourself spending more than an hour on a bug it
is worth noting it. I'd also suggest you include a rough time frame for
when you expect to have an update so other folks can tell if a bug is
being worked on or not.

Mark




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: Bug workflow

2009-09-17 Thread Uwe Günther
So I wasn't so wrong with the first one. Unfortunately there was nothing 
to code at all.


So I am gonna go for some odd ones and go on with the good things to do.

How does this work for non commiters; if they have a patch? Ok, 1st 
attach the patch to the bug, 2nd...?


--
Kind Regards
Uwe Günther

Tim Funk wrote:

It differs by the person. So here is a wild guess ..

But I would guess bugs are usually fixed 1st by interest. For example: 
Crap that bug affects my stuff too, I should look at that.


Other bugs are fixed by how interesting they. For example: hmmm .. that 
seems odd - I think I'll look at that.


Other bugs are fixed because they are there and its a good thing to do.

I'm not sure about everyone else, but I think the general concensus is 
priority is useful in distinguishing enhancement vs bug. But high 
priority vs low seems ignored.


Security fixes typically don't go into bugzilla. They are reported 
privately to the security list.


-Tim

Uwe Günther wrote:

So I could set this one to resolved! Thanks Tim.

Some other questions are popping up in my head right now:

- How do you guys to choose which bugs to fix first?

  OK there are priorities, you are able to fix some bugs,
  others are more difficult to you, some are security
  relevant, 

- If you pick up a bug for fixing, do you flag that up
  somewhere in Bugzilla?



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: Bug workflow

2009-09-17 Thread William A. Rowe, Jr.
Uwe Günther wrote:
> So I wasn't so wrong with the first one. Unfortunately there was nothing
> to code at all.
> 
> So I am gonna go for some odd ones and go on with the good things to do.
> 
> How does this work for non commiters; if they have a patch? Ok, 1st
> attach the patch to the bug, 2nd...?

Bugzilla keywords we added for httpd include PatchAvailable (and FAQ and
a few other obvious ones).  At httpd, we encourage people to mark the bug
as PatchAvailable as soon as the patch is apparently worth applying.  This
provides a quick search for committers who are looking for low-hanging
fruit :)

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: Bug workflow

2009-09-17 Thread Mark Thomas
Uwe Günther wrote:
> So I wasn't so wrong with the first one. Unfortunately there was nothing
> to code at all.
> 
> So I am gonna go for some odd ones and go on with the good things to do.
> 
> How does this work for non commiters; if they have a patch? Ok, 1st
> attach the patch to the bug, 2nd...?

Give the committers a couple of days or so to look at it. Drop a note to
the dev list of it looks like it has been missed. It will either be
applied and/or proposed as appropriate or you'll get some feedback on
what needs improving.

A couple of tips:
- provide patches against trunk unless trunk isn't affected
- provide patches in diff -u format
- avoid having cosmetic changes and functional changes in the same patch

Mark



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: Bug workflow

2009-09-17 Thread Uwe Günther

Mark Thomas wrote:

Thank you. Help closing bugs is always much appreciated.


Thank you too.


- security bugs (handled on a private list)
- regressions
- things I (or my employer*) care about
- oldest open 5.5.x or 6.0.x bug without a patch
- enhancements

* This only applies during work hours :)


I am gonna pin this on my wall. :-)


Normally no. Mainly, I think, because we rarely get clashes. Most bugs
don't take that long to fix so the likelihood of clashes is small. As
the number of open bugs decreases (there are now less than 50 open bugs
against tc5 and tc6 without patches) the chances of a clash increase.
I'd suggest if you find yourself spending more than an hour on a bug it
is worth noting it. I'd also suggest you include a rough time frame for
when you expect to have an update so other folks can tell if a bug is
being worked on or not.


Thanks for pointing that out and makes sense to me. So we will see how 
ti goes. :-)


--
Kind Regards
Uwe Günther

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: Bug workflow

2009-09-17 Thread Uwe Günther

William A. Rowe, Jr. wrote:


Bugzilla keywords we added for httpd include PatchAvailable (and FAQ and
a few other obvious ones).  At httpd, we encourage people to mark the bug
as PatchAvailable as soon as the patch is apparently worth applying.  This
provides a quick search for committers who are looking for low-hanging
fruit :)


Thanks for the pointer William, found the keywords explained in Bugzilla 
right now:


https://issues.apache.org/bugzilla/describekeywords.cgi

--
Kind Regards
Uwe Günther

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



svn commit: r816441 - /tomcat/taglibs/taglibs-parent/trunk/src/site/site.xml

2009-09-17 Thread bayard
Author: bayard
Date: Fri Sep 18 02:32:18 2009
New Revision: 816441

URL: http://svn.apache.org/viewvc?rev=816441&view=rev
Log:
Commenting out the list of taglibs. Changing urls to be tomcat.apache.org 
except for the Download one which we'll handle later. Hope this doesn't hurt 
RDC Rahul. 

Modified:
tomcat/taglibs/taglibs-parent/trunk/src/site/site.xml

Modified: tomcat/taglibs/taglibs-parent/trunk/src/site/site.xml
URL: 
http://svn.apache.org/viewvc/tomcat/taglibs/taglibs-parent/trunk/src/site/site.xml?rev=816441&r1=816440&r2=816441&view=diff
==
--- tomcat/taglibs/taglibs-parent/trunk/src/site/site.xml (original)
+++ tomcat/taglibs/taglibs-parent/trunk/src/site/site.xml Fri Sep 18 02:32:18 
2009
@@ -1,16 +1,14 @@
 
 
-  
   
 Tomcat
-http://jakarta.apache.org/tomcat/images/tomcat.gif
-http://jakarta.apache.org/tomcat/
+http://tomcat.apache.org/images/tomcat.gif
+http://tomcat.apache.org/
   
   
 Apache Taglibs
-http://jakarta.apache.org/tomcat/taglibs/images/taglibs.gif
-http://jakarta.apache.org/tomcat/taglibs/
+http://tomcat.apache.org/taglibs/images/taglibs.gif
+http://tomcat.apache.org/taglibs/
   
   
   
@@ -22,24 +20,30 @@
 
   http://www.apachecon.com/"/>
   http://www.apache.org"/>
-  http://jakarta.apache.org/tomcat"; />
+  http://tomcat.apache.org/"; />
 
-
 
-  http://jakarta.apache.org/taglibs/index.html"; />
+  http://tomcat.apache.org/taglibs/index.html"; />
   http://jakarta.apache.org/site/downloads/downloads_taglibs.html"; />
-  http://jakarta.apache.org/taglibs/site/using.html"; />
-  http://jakarta.apache.org/taglibs/site/tutorial.html"; />
-  http://jakarta.apache.org/taglibs/site/news.html"; />
+  http://tomcat.apache.org/taglibs/site/using.html"; />
+  http://tomcat.apache.org/taglibs/site/tutorial.html"; />
+  http://tomcat.apache.org/taglibs/site/news.html"; />
   http://wiki.apache.org/jakarta-taglibs/FrontPage"; />
 
 
-  http://jakarta.apache.org/taglibs/mail-lists.html"; />
-  http://jakarta.apache.org/taglibs/issue-tracking.html"; />
-  http://jakarta.apache.org/taglibs/site/building.html"; />
-  http://jakarta.apache.org/taglibs/integration.html"; />
+  http://tomcat.apache.org/taglibs/mail-lists.html"; />
+  http://tomcat.apache.org/taglibs/issue-tracking.html"; />
+  http://tomcat.apache.org/taglibs/site/building.html"; />
+  http://tomcat.apache.org/taglibs/integration.html"; />
 
+
+http://tomcat.apache.org/taglibs/rdc/"; />
+http://tomcat.apache.org/taglibs/standard/"; />
+
+
+
 
   http://www.apache.org/foundation/sponsorship.html"; />
   http://www.apache.org/foundation/thanks.html"; />



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



svn commit: r816442 - /tomcat/taglibs/site/src/site/xdoc/site/using.xml

2009-09-17 Thread bayard
Author: bayard
Date: Fri Sep 18 02:32:49 2009
New Revision: 816442

URL: http://svn.apache.org/viewvc?rev=816442&view=rev
Log:
Minor update to text as part of Jakarta->Tomcat

Modified:
tomcat/taglibs/site/src/site/xdoc/site/using.xml

Modified: tomcat/taglibs/site/src/site/xdoc/site/using.xml
URL: 
http://svn.apache.org/viewvc/tomcat/taglibs/site/src/site/xdoc/site/using.xml?rev=816442&r1=816441&r2=816442&view=diff
==
--- tomcat/taglibs/site/src/site/xdoc/site/using.xml (original)
+++ tomcat/taglibs/site/src/site/xdoc/site/using.xml Fri Sep 18 02:32:49 2009
@@ -10,11 +10,13 @@
 
 
 
-Binary downloads of nightly builds and released versions of the 
JAKARTA-TAGLIBS
-distribution, as with all other Jakarta projects, are available from the 
Jakarta web site,
+Binary downloads of released versions of the Apache Taglibs
+distributions are available via the download link - 
 at http://jakarta.apache.org/site/downloads/downloads_taglibs.html";>http://jakarta.apache.org/site/downloads/downloads_taglibs.html.
 Download and unpack the distribution archive into a convenient subdirectory.
 
+Note that for now, these distributions are legacy versions from the Jakarta 
Taglibs days. While current development is built 
+using Maven, the binary builds were created, and the source builds require, an 
Ant build system. 
 
 
 
@@ -33,8 +35,8 @@
 
 Using the JAKARTA-TAGLIBS Binary
 Distribution (this document)
-Using the JAKARTA-TAGLIBS Source
-Distribution
+Building the old JAKARTA-TAGLIBS Source
+Distributions
 Taglib Developer Guidelines
 
 



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: Testing new website sync process

2009-09-17 Thread Henri Yandell
Did this go through Mark?

Where do I commit the Taglibs site?

Hen

On Thu, Sep 3, 2009 at 3:59 AM, Mark Thomas  wrote:
> Folks,
>
> As part of the response to the recent compromise of ASF servers [1] the
> infrastructure team are introducing a new way to sync web sites from svn
> and are looking for PMS to volunteer to test the new process.
>
> I'd like to volunteer the Tomcat website. Any objections? I'm happy to
> take on fixing any teething problems.
>
> The advantage is that commits to svn will be reflected on the live site
> within a few seconds.
>
> If we want we can also have a staging site tomcat.staging.a.o where we
> could preview stuff [2]
>
> My own view is that a staging site isn't necessary. Our site is simple.
> We can test locally before committing and with commits affecting the
> live site within a few seconds, fixing any snafus should be easy.
>
> Cheers,
>
> Mark
>
> [1] http://blogs.apache.org/infra/
>
> [2] This require a separate svn location to sync from. Something like:
> http://svn.apache.org/repos/asf/tomcat/site/branches/live
> would sync to
> http://tomcat.apache.org/
> and
> http://svn.apache.org/repos/asf/tomcat/site/trunk
> would sync to
> http://tomcat.staging.apache.org/
> and we would have to svn merge changes from trunk to live.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org