Re: [all] Commons Manual
I am +1 (in the sense of will help :-) for anything involving improving docs. My one request would be that we start with the docs that already exist and target the main commons web site to house this stuff, rather than creating ever more scattered and incomplete Wiki pages. The following items are already covered on the commons and apache/dev pages: * Subversion information. How to check code out. * Maven information. How to build. * Site information. How to generate the site. How to upload your changes. * Releasing. How to release. If the existing pages are not complete or clear enough, then we should start by updating them. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Together, and bricks apart
On 12/1/05, Martin van den Bemt [EMAIL PROTECTED] wrote: snip To reask the question in this thread : what is broken with crlf ? I use both windows and linux (and mix zips and tgz on both platforms) and never had a single issue with this. It could be the way I work though :) That is a good question to ask - do we care if the line endings in distributions are consistent or meet any kind of standard? Most tools (other than NotePad on Windows and maybe some others) hide the difference, so maybe we should not care. One thing that we might want to care about is if eol=native implies that all line endings in files like this end up CRLF when we create distros from Windows (likely, but I have not personally confirmed this), that could add needlessly to the size of the src distributions. IIRC, we used to essentially require lf line endings on source files, but that was before svn arrived with eol=native possible. The [poll] did not get much response, so maybe there is no interest in making things uniform. *) And I dont know why we should fix all bugs, its not very productive to mark all bugs as later and after the release revert the status again. You don't have to fix all bugs, but the number and kind of bugs solved / still open can be a good indicator of how the project is doing. Mvgr, Martin - 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: [jelly] Gump failures
Do i not understand Gump or the fact that we stick Jaxen head is something that could be changed ? Indeed, no-one really wishes to work with the latest jaxen currently. thanks paul Dion Gillard wrote: It's a break in how Jaxen works. Unless we upgrade all of Jelly to work with the code changes in Jaxen, the failures will continue. Personally, I'd rather stick where we are with jaxen in Jelly and stop Gump from nagging us. On 12/2/05, Henri Yandell [EMAIL PROTECTED] wrote: These seem to have been going on for months. Any chance they can be fixed and stop spamming us? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Together, and bricks apart
On 11/30/05, Mario Ivankovits [EMAIL PROTECTED] wrote: Phil Steitz wrote: For me +1 means pretty much what Martin describes above. I check the release contents, make sure required elements are there and in jars, make sure there is nothing funny included. I test the builds, validate sigs, etc and inspect the web site and, if present, clirr/jdiff and look carefully at the release notes. I also review the javadoc, maven reports and POM. I do try to learn a little more with each release that I review; Thats true, I'll learn with every release review too, but can do this only if another one complains about this and that. If I read the stuff you do to check a release I am shocked, damn much work to do. At least one of you release checkers ;-) should setup a wiki to describe every step to do, this helps the release manager and those checking it. Especially if you are a newbie in the release cycle it might be a great start AND it defines standards. That was the intention of the releases pages: http://jakarta.apache.org/commons/releases/index.html When I get out from under water, I will add a final checklist type section, or someone else can. That is a good idea. One thing which drives me crazy is that I dont know what to do to make a project ready for a release. I have to wait if anyone complains on an RC and even then, in case of [vfs] the real release blocker were uncovered while voting for 1.0 - after we have had a couple of month one RC after another! I agree that this is frustrating and don't have a great answer. See comments at end below. The same thing just happened to me in [math]. After a couple of RCs a major issue that was really a problem with 1.0 was raised and it took a while to get it fixed. To me, this is a consequence of not wanting to release with significant known issues, which is sort of an unwritten rule which we tend to follow in commons. See Martin's response below on fix later. My view, shared by (I think) most others is that there has to be a very good reason to do that. At least on the components that I have worked on (see list below), we tend to get the real issues closed before release and to stop releases when they show up during the vote or RC testing. And e.g. we started to discuss if we have to convert line-endings - after years (!) of commons releases - and we were not able to have a vital discussion about this little topic. In the old days we kept lf line endings on all the source files in cvs and hand-rolled ant scripts were used to put crlf on the .txt files in the zips. Between maven and svn's eol=native, that is no longer possible or at least immediate. The real question (see other response) is do we care about this? From lack of response to [poll] thread, could be the answer is no. These are really demotivating things! Agreed and sorry if we seem to be making things harder rather than easier. Patches - or direct commits to - the releases page and any other suggestions to make things easier are most welcome. One other comment that I have on the issue of voting on releases is that the core problem here is lack of component-committed volunteers, IMHO. I remember a couple of years back when we discussed whose votes were binding on component releases. Hen made the interesting comment that he felt that committers not working on the component should vote and their votes were as important / even more important than those of the project team. We have now devolved to the point where without these votes, we will in some cases not be able to get 3 binding +1's. This is not good. Somehow we have to reengage as Rahul pointed out at the top of this thread. It might be a good idea for each of us to take stock of the components that we can really +1 releases for (in Neil's sense) and then see where the gaps are. By us I mean the whole community. Anyone who is willing to review releases, respond to bug reports, answer user questions, submit patches, or improve docs is encouraged to step up. We need help! I will start. All I can really support right now are [math], [lang], [collections] in commons proper and [id] in sandbox. One day when I have more time and courage, I would like to jump into [beanutils] to help save it from drowning under unresolved bugs and both [functor] and [graph2] in the sandbox (possibly absorbing one or both into [math]), but for now the four above are all I can really stay on top of. To record this kind of info, we might add a list of active volunteers to the Wiki page for each component. Does this sound like a good idea? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] Using Templates for Mail Message
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Herak Sen wrote:
Hi,
A very common method which I use for setting messages is by loading from an
external file and replace some tokens with desired values.
For e.g.
--
AUTO-GENERATED MESSAGE FOLLOWS. PLEASE DO NOT REPLY TO THIS EMAIL.
---
Hello,
You have been successfully registered.
Login Detail
login :@LOGIN@
pwd :@PWD@
-
After reading this file, I replace @LOGIN@ and @PWD@ with the appropriate
values and then send the contents.
I was wondering whether such feature could be incorporated in API.
There could be a class something like the following
public class Template{
private String template;
public Template(InputStream in){
template=loadTemplate(in);
}
public String replaceTokens(Map map){
//Replace all string within @@
return template;
}
}
May be have a more sophisticated implementation for various data sources.
Please share your views.
Thanks
Herak
This appears to me to be outside the realm of [email] itself. Not
discounting the number of times this type of templating is performed -
just seems outside the scope of the email project.
My .02
Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFDkAz1aCoPKRow/gARAq5WAKDQvyPU9FXdAusX9Df82AWYhJNt6ACg6hdD
dKPEW13aHtCdPcuHKGuK6Hw=
=kcL3
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] Using Templates for Mail Message
Hi!
Thanks for writing back
I agree that it won't be part of the core Email project,but as helpers or
utils.
Please comment.
Thanks
Herak
Brian K. Wallace [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Herak Sen wrote:
Hi,
A very common method which I use for setting messages is by loading from an
external file and replace some tokens with desired values.
For e.g.
--
AUTO-GENERATED MESSAGE FOLLOWS. PLEASE DO NOT REPLY TO THIS EMAIL.
---
Hello,
You have been successfully registered.
Login Detail
login :@LOGIN@
pwd :@PWD@
-
After reading this file, I replace @LOGIN@ and @PWD@ with the appropriate
values and then send the contents.
I was wondering whether such feature could be incorporated in API.
There could be a class something like the following
public class Template{
private String template;
public Template(InputStream in){
template=loadTemplate(in);
}
public String replaceTokens(Map map){
//Replace all string within @@
return template;
}
}
May be have a more sophisticated implementation for various data sources.
Please share your views.
Thanks
Herak
This appears to me to be outside the realm of [email] itself. Not
discounting the number of times this type of templating is performed -
just seems outside the scope of the email project.
My .02
Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFDkAz1aCoPKRow/gARAq5WAKDQvyPU9FXdAusX9Df82AWYhJNt6ACg6hdD
dKPEW13aHtCdPcuHKGuK6Hw=
=kcL3
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Yahoo! Personals
Let fate take it's course directly to your email.
See who's waiting for you Yahoo! Personals
Re: [all] Commons Manual
Maybe this is of interest: * Programming guidelines: do's and don'ts Chris Phil Steitz wrote: I am +1 (in the sense of will help :-) for anything involving improving docs. My one request would be that we start with the docs that already exist and target the main commons web site to house this stuff, rather than creating ever more scattered and incomplete Wiki pages. The following items are already covered on the commons and apache/dev pages: * Subversion information. How to check code out. * Maven information. How to build. * Site information. How to generate the site. How to upload your changes. * Releasing. How to release. If the existing pages are not complete or clear enough, then we should start by updating them. Phil - 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: [all] Commons Manual
Henri Yandell wrote: Apache-Committer-Manual (imagine that exists too). I would buy the mannings printed edition ;-) --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JELLY-224) The parser always try to load the DTD even if validate = false
[ http://issues.apache.org/jira/browse/JELLY-224?page=all ] Paul Libbrecht resolved JELLY-224: -- Resolution: Invalid This has nothing to do with Jelly... All XML parsers have to load the DTD when it's referenced since a DTD can indicate default values to attributes (which can also mean namespaces). hope it helps. paul The parser always try to load the DTD even if validate = false -- Key: JELLY-224 URL: http://issues.apache.org/jira/browse/JELLY-224 Project: jelly Type: Bug Components: taglib.xml Environment: Working of line or behind a proxy Reporter: Philippe Kernevez The tag ixml:parse/i always try to load the DTD even if the attribut ivalidate=false/i is used. This cause an error when we use this tag without connection. See: the linked issue http://jira.codehaus.org/browse/MPDASHBOARD-34 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] Using Templates for Mail Message
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The problem I would see with having this in email, even as a utility, is
that it isn't e-mail specific.
While your use case deals with the file system and (presumably?) a
bean-type substitution (e.g., @@LOGIN@@, user.getLogin()), there is a
broader scope of retrieval of information from other sources (database,
property files, etc). The use cases (and dependencies to match) could
get well out of control for a simple project aimed at making e-mail
easier to use.
Perhaps a utility class for your use case could simply deal with
String's replace/replaceAll?
Brian
Herak Sen wrote:
Hi!
Thanks for writing back
I agree that it won't be part of the core Email project,but as helpers or
utils.
Please comment.
Thanks
Herak
Brian K. Wallace [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Herak Sen wrote:
Hi,
A very common method which I use for setting messages is by loading from an
external file and replace some tokens with desired values.
For e.g.
--
AUTO-GENERATED MESSAGE FOLLOWS. PLEASE DO NOT REPLY TO THIS EMAIL.
---
Hello,
You have been successfully registered.
Login Detail
login :@LOGIN@
pwd :@PWD@
-
After reading this file, I replace @LOGIN@ and @PWD@ with the appropriate
values and then send the contents.
I was wondering whether such feature could be incorporated in API.
There could be a class something like the following
public class Template{
private String template;
public Template(InputStream in){
template=loadTemplate(in);
}
public String replaceTokens(Map map){
//Replace all string within @@
return template;
}
}
May be have a more sophisticated implementation for various data sources.
Please share your views.
Thanks
Herak
This appears to me to be outside the realm of [email] itself. Not
discounting the number of times this type of templating is performed -
just seems outside the scope of the email project.
My .02
Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFDkBabaCoPKRow/gARAu9TAKDlpgsI+ifuml0mvXdLTwGo440ckwCdHKK7
0wRZN2bjetPh2whN/8K+eNk=
=/ART
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-224) The parser always try to load the DTD even if validate = false
[ http://issues.apache.org/jira/browse/JELLY-224?page=comments#action_12359135 ] Simon Kitching commented on JELLY-224: -- As Paul says, loading the DTD is required, for things like entity definitions or default attribute definitions. See the xml specs for attribute standalone. However there should be some mechanism for registering a local copy of DTD to use rather than fetching the URL specified in the SYSTEM attribute. If this doesn't exist in Jelly then it should do... The parser always try to load the DTD even if validate = false -- Key: JELLY-224 URL: http://issues.apache.org/jira/browse/JELLY-224 Project: jelly Type: Bug Components: taglib.xml Environment: Working of line or behind a proxy Reporter: Philippe Kernevez The tag ixml:parse/i always try to load the DTD even if the attribut ivalidate=false/i is used. This cause an error when we use this tag without connection. See: the linked issue http://jira.codehaus.org/browse/MPDASHBOARD-34 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Together, and bricks apart
Phil Steitz wrote: In the old days we kept lf line endings on all the source files in cvs and hand-rolled ant scripts were used to put crlf on the .txt files in the zips. Between maven and svn's eol=native, that is no longer possible or at least immediate. The real question (see other response) is do we care about this? From lack of response to [poll] thread, could be the answer is no. +1 it think we shouldnt care too much about the eol thing too, never ever one of my [vfs] users complained about them nor I've seen such an issue on the mailing list. Though, having a standard in commons would look professional and thus we should find consens, even if we say we use lf ;-) only These are really demotivating things! greed and sorry if we seem to be making things harder rather than easier. Yes, things are hard, but in the end I like it that way as I hope (and think) this really increase the quality. Its just seems the current throughput time in commons (regarding releases or communication) is a little bit hughe. The current [all] threads are an exeption. And I wonder if this has something to do with who started them. Henri is a well known and respected person. But even if someone else try to kick off a [all] discussion it would be great if there are at least negative responses if there is disapprove. In concret I talk about the crlf [poll]. If you think its not necessary then give me 10 -1 and all is well ;-) I remember a couple of years back when we discussed whose votes were binding on component releases. Hen made the interesting comment that he felt that committers not working on the component should vote and their votes were as important / even more important than those of the project team. We have now devolved to the point where without these votes, we will in some cases not be able to get 3 binding +1's. This is not good. This is true, even more with [VFS]. But the alternative is to leave apache. Every project with less than 3 active committers for a specific period should be treated as dormant or at least as unable to move in the context of jakarta/commons. I really dont like this idea!!! It might be a good idea for each of us to take stock of the components that we can really +1 releases for This is a good idea. And it should be somehow binding. Even if it take a week until one find time to check a release, we should attend our duty. On the other hand then other commons projects might loose important persons. e.g. Simon and Stephen made good work when they checked the VFS release. I cant talk in their names, but they cant subscribe to every commons project if its that binding - they have other OS projects too. The same for me, I can support [vfs], [net], [compress] in the context of such a binding, which doesnt mean I cant support other too if there is time, but this cant be planned. So all in all it isnt that bad as it currently is, maybe we are just too busy with other work. And we should take concerns from developer-newbies seriously too ;-) --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Together, and bricks apart
On 12/2/05, Phil Steitz [EMAIL PROTECTED] wrote: One other comment that I have on the issue of voting on releases is that the core problem here is lack of component-committed volunteers, IMHO. I remember a couple of years back when we discussed whose votes were binding on component releases. Hen made the interesting comment that he felt that committers not working on the component should vote and their votes were as important / even more important than those of the project team. We have now devolved to the point where without these votes, we will in some cases not be able to get 3 binding +1's. This is not good. Somehow we have to reengage as Rahul pointed out at the top of this thread. It might be a good idea for each of us to take stock of the components that we can really +1 releases for (in Neil's sense) and then see where the gaps are. By us I mean the whole community. Anyone who is willing to review releases, respond to bug reports, answer user questions, submit patches, or improve docs is encouraged to step up. We need help! I agree and I have sympathy where theres one or two active developers working hard and keen to put something out, but short of a +1. That was the case for me on Validator recently - luckily Stephen Colebourne pitched in to check out the release and throw in a +1. I'm prepared to add one more to my list and adopt a component (in the new year) - not to develop, but just to get to know the code and offer opionions and release review (maybe support). I will start. All I can really support right now are [math], [lang], [collections] in commons proper and [id] in sandbox. One day when I have more time and courage, I would like to jump into [beanutils] to help save it from drowning under unresolved bugs and both [functor] and [graph2] in the sandbox (possibly absorbing one or both into [math]), but for now the four above are all I can really stay on top of. Currently I'm a commiter for validator, resources and beanutils. I monitor (and know) chain and would pitch in readily, if needed. Theres a couple of others I'm a user of and keep an eye on (fileupload, digester, logging). To record this kind of info, we might add a list of active volunteers to the Wiki page for each component. Does this sound like a good idea? +1 maybe with a level people are prepared to do, including adopted. Although how about one wiki page for all components - that would make it easy to see where the gaps are for components that need additional support. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction] FileNotFoundException during commitTransaction()
Hi Oliver! Sorry for not continuing the thread, i'm navigating currently on apache's mail-archives... 1. i'll check the HEAD version for updates, thanx. 2. On Linux we use ReiserFS, on Solaris (i think) JFS, will check. Either way, long (64byte+) file names are supported on Reiser. And another thing: before this exception, the TxFS created ~5 files of the SAME filename length :) As you may see, the filename format is always same, it is just formatted timestamp with some extras... Don't have a faintest idea about the creation failure's reason... ~t~ Hi Tamas! This looks as if the directory (or the file) has not been created. Commons transaction should throw an exception in that case. Not quite sure where that should be, though. Anyway, just committed a change that adds a check at the suspectedly right position. Please try that. Another question is: Why does the creation fail? Are you sure your file system supports file names longer than 64 bytes (yours is). AFAIK at least NTFS does not... Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-test (in module commons-jelly) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-jelly-test has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 2 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-test : Commons Jelly
Full details are available at:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for
property maven.jar.servletapi.
-DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for
property maven.jar.jstl.
-DEBUG- Dependency on xml-xerces exists, no need to add for property
maven.jar.xerces.
-WARNING- Overriding Maven properties:
[/usr/local/gump/public/workspace/commons-jelly/build.properties]
-DEBUG- (Gump generated) Maven Properties in:
/usr/local/gump/public/workspace/commons-jelly/build.properties
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/usr/local/gump/public/workspace/commons-jelly/project.xml
-DEBUG- Maven project properties in:
/usr/local/gump/public/workspace/commons-jelly/project.properties
-INFO- Project Reports in:
/usr/local/gump/public/workspace/commons-jelly/target/test-reports
The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/gump_work/build_commons-jelly_commons-jelly-test.html
Work Name: build_commons-jelly_commons-jelly-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 55 secs
Command Line: maven --offline jar
[Working Directory: /usr/local/gump/public/workspace/commons-jelly]
CLASSPATH:
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-02122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/forehead/forehead-1.0-beta-5.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar
-
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File:
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
At tag test:assertEquals: line: 359 column: 75
[junit] org.apache.commons.jelly.JellyTagException:
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly:359:75:
test:assertEquals expected:[22] but was:[22]
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File:
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
At tag test:assertEquals: line: 359 column: 75
[junit] at
org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:712)
[junit] at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:282)
[junit] at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] Caused by:
org.apache.commons.jelly.tags.junit.JellyAssertionFailedError: expected:[22]
but was:[22]
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File:
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
At tag test:assertEquals: line: 359 column: 75
[junit] at
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:39)
[junit] at
org.apache.commons.jelly.tags.junit.AssertTagSupport.failNotEquals(AssertTagSupport.java:62)
[junit] at
org.apache.commons.jelly.tags.junit.AssertEqualsTag.doTag(AssertEqualsTag.java:55)
[junit] at
[EMAIL PROTECTED]: Project commons-jelly-test (in module commons-jelly) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-jelly-test has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 2 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-test : Commons Jelly
Full details are available at:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for
property maven.jar.servletapi.
-DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for
property maven.jar.jstl.
-DEBUG- Dependency on xml-xerces exists, no need to add for property
maven.jar.xerces.
-WARNING- Overriding Maven properties:
[/usr/local/gump/public/workspace/commons-jelly/build.properties]
-DEBUG- (Gump generated) Maven Properties in:
/usr/local/gump/public/workspace/commons-jelly/build.properties
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/usr/local/gump/public/workspace/commons-jelly/project.xml
-DEBUG- Maven project properties in:
/usr/local/gump/public/workspace/commons-jelly/project.properties
-INFO- Project Reports in:
/usr/local/gump/public/workspace/commons-jelly/target/test-reports
The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/gump_work/build_commons-jelly_commons-jelly-test.html
Work Name: build_commons-jelly_commons-jelly-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 55 secs
Command Line: maven --offline jar
[Working Directory: /usr/local/gump/public/workspace/commons-jelly]
CLASSPATH:
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-02122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/forehead/forehead-1.0-beta-5.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar
-
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File:
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
At tag test:assertEquals: line: 359 column: 75
[junit] org.apache.commons.jelly.JellyTagException:
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly:359:75:
test:assertEquals expected:[22] but was:[22]
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File:
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
At tag test:assertEquals: line: 359 column: 75
[junit] at
org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:712)
[junit] at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:282)
[junit] at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] Caused by:
org.apache.commons.jelly.tags.junit.JellyAssertionFailedError: expected:[22]
but was:[22]
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File:
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
At tag test:assertEquals: line: 359 column: 75
[junit] at
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:39)
[junit] at
org.apache.commons.jelly.tags.junit.AssertTagSupport.failNotEquals(AssertTagSupport.java:62)
[junit] at
org.apache.commons.jelly.tags.junit.AssertEqualsTag.doTag(AssertEqualsTag.java:55)
[junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-xml-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-xml-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-xml-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/gump_work/build_commons-jelly_commons-jelly-tags-xml-test.html Work Name: build_commons-jelly_commons-jelly-tags-xml-test (Type: Build) Work ended in a state of : Failed Elapsed: 41 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-02122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar - [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testSetSingleNodeAndAsString(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81: x:set You must define an attribute called 'select' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81: x:set You must define an attribute called 'select' for this tag. [junit] at org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testSetStringLists(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82: x:set You must define an attribute called 'select' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82: x:set You must define an attribute called 'select' for this tag. [junit] at org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testEntities(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit]
[EMAIL PROTECTED]: Project commons-jelly-tags-xml-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-xml-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-xml-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/gump_work/build_commons-jelly_commons-jelly-tags-xml-test.html Work Name: build_commons-jelly_commons-jelly-tags-xml-test (Type: Build) Work ended in a state of : Failed Elapsed: 41 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-02122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar - [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testSetSingleNodeAndAsString(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81: x:set You must define an attribute called 'select' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81: x:set You must define an attribute called 'select' for this tag. [junit] at org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testSetStringLists(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82: x:set You must define an attribute called 'select' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82: x:set You must define an attribute called 'select' for this tag. [junit] at org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testEntities(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit]
[EMAIL PROTECTED]: Project commons-jelly-tags-swing (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-swing has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-swing : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-swing/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-swing-02122005.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/target/test-reports -WARNING- No directory [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/target/test-reports] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-swing/gump_work/build_commons-jelly_commons-jelly-tags-swing.html Work Name: build_commons-jelly_commons-jelly-tags-swing (Type: Build) Work ended in a state of : Failed Elapsed: 3 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/commons-jelly-tags-define-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/interaction/target/commons-jelly-tags-interaction-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-02122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar - at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at java.lang.Class.newInstance0(Class.java:308) at java.lang.Class.newInstance(Class.java:261) at org.apache.commons.jelly.JellyContext.getTagLibrary(JellyContext.java:432) at org.apache.maven.jelly.MavenJellyContext.getTagLibrary(MavenJellyContext.java:171) at org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java:1033) at org.apache.commons.jelly.parser.XMLParser.startElement(XMLParser.java:647) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown
[EMAIL PROTECTED]: Project commons-jelly-tags-define-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-define-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-define-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/gump_work/build_commons-jelly_commons-jelly-tags-define-test.html Work Name: build_commons-jelly_commons-jelly-tags-define-test (Type: Build) Work ended in a state of : Failed Elapsed: 14 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/dynabean/target/commons-jelly-tags-dynabean-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-02122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar - [junit] at org.jaxen.saxpath.base.XPathReader.unionExpr(XPathReader.java:1129) [junit] at org.jaxen.saxpath.base.XPathReader.unaryExpr(XPathReader.java:1117) [junit] at org.jaxen.saxpath.base.XPathReader.multiplicativeExpr(XPathReader.java:1039) [junit] at org.jaxen.saxpath.base.XPathReader.additiveExpr(XPathReader.java:982) [junit] at org.jaxen.saxpath.base.XPathReader.relationalExpr(XPathReader.java:902) [junit] at org.jaxen.saxpath.base.XPathReader.equalityExpr(XPathReader.java:850) [junit] at org.jaxen.saxpath.base.XPathReader.andExpr(XPathReader.java:826) [junit] at org.jaxen.saxpath.base.XPathReader.orExpr(XPathReader.java:804) [junit] at org.jaxen.saxpath.base.XPathReader.expr(XPathReader.java:797) [junit] at org.jaxen.saxpath.base.XPathReader.parse(XPathReader.java:105) [junit] at org.jaxen.BaseXPath.init(BaseXPath.java:126) [junit] at org.jaxen.BaseXPath.init(BaseXPath.java:152) [junit] at org.jaxen.dom4j.Dom4jXPath.init(Dom4jXPath.java:101) [junit] at org.apache.commons.jelly.expression.xpath.XPathExpression.evaluate(XPathExpression.java:78) [junit] at org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:256) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] at junit.framework.TestCase.runBare(TestCase.java:127) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-define-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-define-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-define-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/gump_work/build_commons-jelly_commons-jelly-tags-define-test.html Work Name: build_commons-jelly_commons-jelly-tags-define-test (Type: Build) Work ended in a state of : Failed Elapsed: 14 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/dynabean/target/commons-jelly-tags-dynabean-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-02122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar - [junit] at org.jaxen.saxpath.base.XPathReader.unionExpr(XPathReader.java:1129) [junit] at org.jaxen.saxpath.base.XPathReader.unaryExpr(XPathReader.java:1117) [junit] at org.jaxen.saxpath.base.XPathReader.multiplicativeExpr(XPathReader.java:1039) [junit] at org.jaxen.saxpath.base.XPathReader.additiveExpr(XPathReader.java:982) [junit] at org.jaxen.saxpath.base.XPathReader.relationalExpr(XPathReader.java:902) [junit] at org.jaxen.saxpath.base.XPathReader.equalityExpr(XPathReader.java:850) [junit] at org.jaxen.saxpath.base.XPathReader.andExpr(XPathReader.java:826) [junit] at org.jaxen.saxpath.base.XPathReader.orExpr(XPathReader.java:804) [junit] at org.jaxen.saxpath.base.XPathReader.expr(XPathReader.java:797) [junit] at org.jaxen.saxpath.base.XPathReader.parse(XPathReader.java:105) [junit] at org.jaxen.BaseXPath.init(BaseXPath.java:126) [junit] at org.jaxen.BaseXPath.init(BaseXPath.java:152) [junit] at org.jaxen.dom4j.Dom4jXPath.init(Dom4jXPath.java:101) [junit] at org.apache.commons.jelly.expression.xpath.XPathExpression.evaluate(XPathExpression.java:78) [junit] at org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:256) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] at junit.framework.TestCase.runBare(TestCase.java:127) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 17 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-02122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar - [junit] at org.apache.commons.jelly.tags.xml.ExprTag.doTag(ExprTag.java:46) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234) [junit] at org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:90) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:58) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:79) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:58) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 17 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-02122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar - [junit] at org.apache.commons.jelly.tags.xml.ExprTag.doTag(ExprTag.java:46) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234) [junit] at org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:90) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:58) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:79) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:58) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at
[jira] Commented: (JELLY-224) The parser always try to load the DTD even if validate = false
[ http://issues.apache.org/jira/browse/JELLY-224?page=comments#action_12359148 ] Paul Libbrecht commented on JELLY-224: -- You mean like a catalog based on public-identifiers, right ? That could be considered, indeed, within the core tags... but we need to rephrase such a wish! Does anyone have pointer to Xerces support for something like catalogs ? Sorry to have been a bit rude... paul The parser always try to load the DTD even if validate = false -- Key: JELLY-224 URL: http://issues.apache.org/jira/browse/JELLY-224 Project: jelly Type: Bug Components: taglib.xml Environment: Working of line or behind a proxy Reporter: Philippe Kernevez The tag ixml:parse/i always try to load the DTD even if the attribut ivalidate=false/i is used. This cause an error when we use this tag without connection. See: the linked issue http://jira.codehaus.org/browse/MPDASHBOARD-34 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote][net] Release commons-net 1.4.1?
Mario Ivankovits wrote: Steve Cohen wrote: The thread Robert refers to has the subject Re: Does Apache have agreement to use other open source code outside of Apache? Has this something to do with an email from IBM in the last few days asking me if I am really was the creator of my contributions? Not that I made any mistake (I guess this was a mail to all commons-net developers), but I was a little bit irritated. Hmm. Sounds like it. Although I got no such email myself, I only saw it on the PMC Mailing List. Which is just as well. Because I have another issue. I don't understand the maven.compile.target property. Working from the net 1.4.0 tag, I change only project.properties to set maven.compile.target back to 1.2. Since there are a few places in 1.4.0 that depend on jdk 1.4, my expectation was that changing the project properties would cause the compile to break on those places. But it did not. It compiled successfully. The jdk1.4 compiler creates a class file suitable to run under an earlier JVM, this works as long as you do not use any new api. Then you'll get the NoSuchMethod Exception. Of course, we did use new APIs, so for the purpose I had in mind, this property is useless. This is the reason why we should use the least possible compiler and not only the target attribute. You didnt notice if you use any new api call at compile time. I'll have to dig out a 1.3.1 compiler then. I don't even think 1.2.x is available anymore. --- Mario - 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][net] Release commons-net 1.4.1?
I got one of those emails as wellwhat is the class that the question is over? Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: Mario Ivankovits wrote: Steve Cohen wrote: The thread Robert refers to has the subject Re: Does Apache have agreement to use other open source code outside of Apache? Has this something to do with an email from IBM in the last few days asking me if I am really was the creator of my contributions? Not that I made any mistake (I guess this was a mail to all commons-net developers), but I was a little bit irritated. Hmm. Sounds like it. Although I got no such email myself, I only saw it on the PMC Mailing List. Which is just as well. Because I have another issue. I don't understand the maven.compile.target property. Working from the net 1.4.0 tag, I change only project.properties to set maven.compile.target back to 1.2. Since there are a few places in 1.4.0 that depend on jdk 1.4, my expectation was that changing the project properties would cause the compile to break on those places. But it did not. It compiled successfully. The jdk1.4 compiler creates a class file suitable to run under an earlier JVM, this works as long as you do not use any new api. Then you'll get the NoSuchMethod Exception. Of course, we did use new APIs, so for the purpose I had in mind, this property is useless. This is the reason why we should use the least possible compiler and not only the target attribute. You didnt notice if you use any new api call at compile time. I'll have to dig out a 1.3.1 compiler then. I don't even think 1.2.x is available anymore. --- Mario - 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] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote][net] Release commons-net 1.4.1?
I got one of those emails as wellwhat is the class that the question is over? Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: Mario Ivankovits wrote: Steve Cohen wrote: The thread Robert refers to has the subject Re: Does Apache have agreement to use other open source code outside of Apache? Has this something to do with an email from IBM in the last few days asking me if I am really was the creator of my contributions? Not that I made any mistake (I guess this was a mail to all commons-net developers), but I was a little bit irritated. Hmm. Sounds like it. Although I got no such email myself, I only saw it on the PMC Mailing List. Which is just as well. Because I have another issue. I don't understand the maven.compile.target property. Working from the net 1.4.0 tag, I change only project.properties to set maven.compile.target back to 1.2. Since there are a few places in 1.4.0 that depend on jdk 1.4, my expectation was that changing the project properties would cause the compile to break on those places. But it did not. It compiled successfully. The jdk1.4 compiler creates a class file suitable to run under an earlier JVM, this works as long as you do not use any new api. Then you'll get the NoSuchMethod Exception. Of course, we did use new APIs, so for the purpose I had in mind, this property is useless. This is the reason why we should use the least possible compiler and not only the target attribute. You didnt notice if you use any new api call at compile time. I'll have to dig out a 1.3.1 compiler then. I don't even think 1.2.x is available anymore. --- Mario - 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] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-224) The parser always try to load the DTD even if validate = false
[ http://issues.apache.org/jira/browse/JELLY-224?page=comments#action_12359149 ] Thomas Dudziak commented on JELLY-224: -- Perhaps xml-commons can help ? http://xml.apache.org/commons/components/resolver/index.html The parser always try to load the DTD even if validate = false -- Key: JELLY-224 URL: http://issues.apache.org/jira/browse/JELLY-224 Project: jelly Type: Bug Components: taglib.xml Environment: Working of line or behind a proxy Reporter: Philippe Kernevez The tag ixml:parse/i always try to load the DTD even if the attribut ivalidate=false/i is used. This cause an error when we use this tag without connection. See: the linked issue http://jira.codehaus.org/browse/MPDASHBOARD-34 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-html (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-html has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-html : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-html-02122005.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html Work Name: build_commons-jelly_commons-jelly-tags-html (Type: Build) Work ended in a state of : Failed Elapsed: 15 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-02122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar - [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testMixedCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48: test:assert You must define an attribute called 'test' for this tag. [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-html (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-html has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-html : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-html-02122005.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html Work Name: build_commons-jelly_commons-jelly-tags-html (Type: Build) Work ended in a state of : Failed Elapsed: 15 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-02122005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-02122005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-02122005.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar - [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testMixedCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48: test:assert You must define an attribute called 'test' for this tag. [junit] at
DO NOT REPLY [Bug 37755] New: - [validator]javascript date validation failure
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37755. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37755 Summary: [validator]javascript date validation failure Product: Commons Version: unspecified Platform: Other OS/Version: other Status: NEW Severity: major Priority: P2 Component: Validator AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] if neither datePattern nor datePatternStrict is specified in validation.xml, the validation should use the short date pattern of user's locale or default locale. The client side validation always fails (javascript error occurs) when no date pattern is specified for the field. Javascript error in function validateDate(form) : datePattern has no properties on line : if ((field.type == 'hidden' || field.type == 'text' || field.type == 'textarea') (value.length 0) (datePattern.length 0) I suggest that function is modified so it tests whether datePattern is null after instruction datePattern = oDate[x][2](datePattern); and if so initializes it to a global javascript variable that would be dynamically generated with a value based on the locale : ((SimpleDateFormat) DateFormat.getDateInstance(DateFormat.SHORT, theUsersLocale)).toPattern -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net][Fwd: Author of Jakarta commons-net-1.4.0]
Hi! Attach you will find the e-mail I got from IBM. I am not on the PMC mailing list so I dont know every detail about the current [net] issues, but I am a little bit angry about IBM as the told me they would integrate commons-net into on of their project and I answered them best of my knowledge! Now I have the feeling this was a lie. I am a little bit angry on IBM now, so could someone please clarify what happens here? Thanks! --- Mario ---BeginMessage--- Hello Mario, We are looking into using Jakarta Commons Net Package for a project and notice you are one of the contributors. If you do not mind, could you please let me know the following ASAP? 1) Did you sign or are you willing to sign the Apache Contributor's Agreement? 2) Were you employed when you made the contribution? and if you were, have your employer released all rights in your contributions? 3) Were you the sole authors of the contribution, or did you incorporate the contributions of others? Your prompt response is greatly appreciated. Thanks! Best Regards, Jane Dong IBM Silicon Valley Lab [EMAIL PROTECTED] Tie/Line: 543-2316 External: 1-408-463-2316---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net][Fwd: Author of Jakarta commons-net-1.4.0]
--- Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Attach you will find the e-mail I got from IBM. I am not on the PMC mailing list so I dont know every detail about the current [net] issues, but I am a little bit angry about IBM as the told me they would integrate commons-net into on of their project and I answered them best of my knowledge! Now I have the feeling this was a lie. I am a little bit angry on IBM now, so could someone please clarify what happens here? Legal departmen of IBM does his work. They try to avoid any posible copyright issue after incorporating commons-net into their product. (for example If you were employed, then it would be possible that your employer has copyright on your stuff in certain jurisdictions ) Insetad of JBoss inc they take copyright issues seriosly ( you surely heard about JB copyright / licensing issues lately - it could cost marketshare for them ) So IBM just tries to cover their and their customers ass. regards, [ Konstantin Pribluda http://www.pribluda.de ] Still using XDoclet 1.x? XDoclet 2 is released and of production quality. check it out: http://xdoclet.codehaus.org __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net][Fwd: Author of Jakarta commons-net-1.4.0]
Hi Konstantin! Legal departmen of IBM does his work. They try to avoid any posible copyright issue after incorporating commons-net into their product. Ok, so please can one clarify why the question Re: Does Apache have agreement to use other open source code outside of Apache? avoids a new commons-net release. Which part of [net] violations our current ASF rules? --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net][Fwd: Author of Jakarta commons-net-1.4.0]
Attach you will find the e-mail I got from IBM. I am not on the PMC mailing list so I dont know every detail about the current [net] issues, but I am a little bit angry about IBM as the told me they would integrate commons-net into on of their project and I answered them best of my knowledge! Now I have the feeling this was a lie. I am a little bit angry on IBM now, so could someone please clarify what happens here? What was a lie? And why does it make you angry they want to cover their asses? cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: [net][Fwd: Author of Jakarta commons-net-1.4.0]
Torsten Curdt wrote: Attach you will find the e-mail I got from IBM. I am not on the PMC mailing list so I dont know every detail about the current [net] issues, but I am a little bit angry about IBM as the told me they would integrate commons-net into on of their project and I answered them best of my knowledge! Now I have the feeling this was a lie. I am a little bit angry on IBM now, so could someone please clarify what happens here? What was a lie? And why does it make you angry they want to cover their asses? Maybe only a communication problem. For a short period I thought IBM searches the bad man (see http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200512.mbox/[EMAIL PROTECTED] ) Now that it looks like this is not the case I would excuse me. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net][Fwd: Author of Jakarta commons-net-1.4.0]
I suspect it may be a genuine request on IBM's behalf. I am more concerned as to exactly what people feel may be a potential copyright issue, whatever it is. Unfortunately without access to the pmc list, a good deal of us are none the wiser. Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: Torsten Curdt wrote: Attach you will find the e-mail I got from IBM. I am not on the PMC mailing list so I dont know every detail about the current [net] issues, but I am a little bit angry about IBM as the told me they would integrate commons-net into on of their project and I answered them best of my knowledge! Now I have the feeling this was a lie. I am a little bit angry on IBM now, so could someone please clarify what happens here? What was a lie? And why does it make you angry they want to cover their asses? Maybe only a communication problem. For a short period I thought IBM searches the bad man (see http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200512.mbox/[EMAIL PROTECTED] ) Now that it looks like this is not the case I would excuse me. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net][Fwd: Author of Jakarta commons-net-1.4.0]
I suspect it may be a genuine request on IBM's behalf. I am more concerned as to exactly what people feel may be a potential copyright issue, whatever it is. Unfortunately without access to the pmc list, a good deal of us are none the wiser. Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: Torsten Curdt wrote: Attach you will find the e-mail I got from IBM. I am not on the PMC mailing list so I dont know every detail about the current [net] issues, but I am a little bit angry about IBM as the told me they would integrate commons-net into on of their project and I answered them best of my knowledge! Now I have the feeling this was a lie. I am a little bit angry on IBM now, so could someone please clarify what happens here? What was a lie? And why does it make you angry they want to cover their asses? Maybe only a communication problem. For a short period I thought IBM searches the bad man (see http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200512.mbox/[EMAIL PROTECTED] ) Now that it looks like this is not the case I would excuse me. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net][Fwd: Author of Jakarta commons-net-1.4.0]
--- Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Konstantin! Ok, so please can one clarify why the question Re: Does Apache have agreement to use other open source code outside of Apache? avoids a new commons-net release. how would I know? :) Which part of [net] violations our current ASF rules? the same :) Copyright is a funny field. Just imagine that ibm incorporates / distributes commons-net with their product, and then it comes out that somebody of contributors was on employ of some company. thus company has copyright on this code. so technically IBM and ( much worse ) their customers are commiting copyright infringement. this company lawyers switch their phasors on sue and start major assault. any similarity with SCO/Linux issue is not intentional :) regards, [ Konstantin Pribluda http://www.pribluda.de ] Still using XDoclet 1.x? XDoclet 2 is released and of production quality. check it out: http://xdoclet.codehaus.org __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Commons Manual
I definitely intend to use the docs that are already there. In fact I'm expecting that most of these are written, but I don't want to ask that question until I have a ToC. What I'm intending to do is to organize the scattered docs into a centralized manual so that people don't have to search as much for information. Plus I can then throw an editor at it and have a PDF version for printing. Hen On 12/2/05, Phil Steitz [EMAIL PROTECTED] wrote: I am +1 (in the sense of will help :-) for anything involving improving docs. My one request would be that we start with the docs that already exist and target the main commons web site to house this stuff, rather than creating ever more scattered and incomplete Wiki pages. The following items are already covered on the commons and apache/dev pages: * Subversion information. How to check code out. * Maven information. How to build. * Site information. How to generate the site. How to upload your changes. * Releasing. How to release. If the existing pages are not complete or clear enough, then we should start by updating them. Phil - 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: [email] Using Templates for Mail Message
Herak,
Why wouldn't you use something like Velocity for this? Velocity is very
well equipped to handle these sorts of tasks and that's exactly what I use
for generating system emails. Commons email doesn't need any utility for
this. The body of an email is (for the most part) simply a string and you
can easily generate that using Velocity. If you'd like a copy of a class I
wrote (VelocityUtils) which makes it easy to turn a velocity template into a
String, let me know. I'll mail it to you directly. It works quite well.
James
-Original Message-
From: Herak Sen [mailto:[EMAIL PROTECTED]
Sent: Friday, December 02, 2005 2:25 AM
To: Jakarta Commons Developers List
Subject: [email] Using Templates for Mail Message
Hi,
A very common method which I use for setting messages is by loading from an
external file and replace some tokens with desired values.
For e.g.
--
AUTO-GENERATED MESSAGE FOLLOWS. PLEASE DO NOT REPLY TO THIS EMAIL.
---
Hello,
You have been successfully registered.
Login Detail
login :@LOGIN@
pwd :@PWD@
-
After reading this file, I replace @LOGIN@ and @PWD@ with the appropriate
values and then send the contents.
I was wondering whether such feature could be incorporated in API.
There could be a class something like the following
public class Template{
private String template;
public Template(InputStream in){
template=loadTemplate(in);
}
public String replaceTokens(Map map){
//Replace all string within @@
return template;
}
}
May be have a more sophisticated implementation for various data sources.
Please share your views.
Thanks
Herak
-
Yahoo! Personals
Let fate take it's course directly to your email.
See who's waiting for you Yahoo! Personals
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 37667] - [configuration] BaseConfiguration.addProperty() and MapConfiguration.addProperty() do not behave the same
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37667.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=37667
--- Additional Comments From [EMAIL PROTECTED] 2005-12-02 15:40 ---
I created the same test as you (copy/paste) and the assertion failed: size()
returns 1. As I tried to explain it in the bug description, adding properties to
existing values simply overwrites the preceeding ones.
I had a look at the code: AbstractConfiguration defines addProperty() which
calls the abstract addPropertyDirect(), which in turn is implemented in
MapConfiguration as follows:
protected void addPropertyDirect(String key, Object obj)
{
map.put(key, obj);
}
As Map.put() overwrites any existing values, the contract of addProperty is not
respected.
I downloaded the binaries and sources from the apache website, current the
version is 1.1.
So as it is working for you, I decided to look at the SVN version. The code for
addPropertyDirect seems to be better up there:
protected void addPropertyDirect(String key, Object value)
{
Object previousValue = getProperty(key);
if (previousValue == null)
{
map.put(key, value);
}
else if (previousValue instanceof List)
{
// the value is added to the existing list
((List) previousValue).add(value);
}
else
{
// the previous value is replaced by a list containing the previous
value and the new value
List list = new ArrayList();
list.add(previousValue);
list.add(value);
map.put(key, list);
}
}
So I think the bug I'm describing has been fixed, but is not currently available
in the latest release... When is the next release planned for?
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 37667] - [configuration] BaseConfiguration.addProperty() and MapConfiguration.addProperty() do not behave the same
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37667. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37667 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2005-12-02 16:30 --- We are in the process of getting the next release out. You can find the latest release candidate here: http://people.apache.org/~oheger/commons-configuration-1.2RC2/ (Your issue should have been fixed in this version.) If there are no unexpected issues, commons-configuration 1.2 final should be available really soon now. There won't be much difference to the release candidate mentioned above. Okay, I am closing this ticket now. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Committer cleanup
On 12/2/05, Mario Ivankovits [EMAIL PROTECTED] wrote: Henri Yandell wrote: I'd like to go ahead and remove all the committers from subversion for commons, and then add back anyone who has committed in the last 6 months. 1 year - and if possible take the user/dev mailinglist for this project into account. A commiter active in the mailinglist is also a valuable part of a project and for the community. 1 year shouldn't be a problem. Mailing lists will be a pain as people don't use their @apache.org addresses all the time. Easy solution there is to post the list of people I'll end up removing to the list and anyone can request to be re-added with no fuss. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Together, and bricks apart
On 12/2/05, Niall Pemberton [EMAIL PROTECTED] wrote: On 12/2/05, Phil Steitz [EMAIL PROTECTED] wrote: I will start. All I can really support right now are [math], [lang], [collections] in commons proper and [id] in sandbox. One day when I have more time and courage, I would like to jump into [beanutils] to help save it from drowning under unresolved bugs and both [functor] and [graph2] in the sandbox (possibly absorbing one or both into [math]), but for now the four above are all I can really stay on top of. I vaguely support [lang] right now, and do generic Commons things from time to time. I intend to do a lot more in terms of recording and encouraging activity, and somewhat more in terms of developing. To record this kind of info, we might add a list of active volunteers to the Wiki page for each component. Does this sound like a good idea? +1 maybe with a level people are prepared to do, including adopted. Although how about one wiki page for all components - that would make it easy to see where the gaps are for components that need additional support. I'd be tempted to put it in Commons SVN instead. I suggested the same kind of thing over at the ASF Infra area, and people pointed out that it'll lead to users mailing the people who are listed as being in charge of that product instead of the list. I think that's a fair point, so we put the file in SVN. Something I want to make myself do is keep on eye on such information and keep it up to date. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Committer cleanup
On 12/1/05, Martin Cooper [EMAIL PROTECTED] wrote: On 12/1/05, Henri Yandell [EMAIL PROTECTED] wrote: I'd like to go ahead and remove all the committers from subversion for commons, and then add back anyone who has committed in the last 6 months. We have 105 commons committers, and 36 additional sandbox committers. We've had 43 committers committing to proper, and 7 extra committing to sandbox in the last 6 months. Then we'd add back anyone else on request if need be. Anyone against the idea? 6 months seems quite short if you're only counting commits. Would the numbers be significantly different if we use 1 year instead? I'll find out. Probably not. Where do you plan on keeping the list of people removed? It will need to be somewhere that we can get at, so that we know who can be added back without question. I'll start a file in the Jakarta PMC area in the committers module. I'm aiming to do this for all of Jakarta, so it'll be the start of that. It'll list each svn module, and who's commit karma has been removed. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] short critique of site
On 12/1/05, Martin Cooper [EMAIL PROTECTED] wrote: On 12/1/05, Henri Yandell [EMAIL PROTECTED] wrote: Some thoughts on the site. A] Looking at the front page. 1) Jakarta link on the bar is redundant. We already have a huge logo in the top left. 2) No need to include the direct svn link, just use viewcvs. Simpler for the user. Perhaps, but AIUI viewcvs puts a significantly higher load on our infrastructure, and the infra@ folks have specifically stated that they would prefer people to use direct links to the SVN repo. Not sure that holds true anymore, but I don't think the user clicking through the site to browse source is the major problem with the load. I'll get confirmation from them before suggesting it be removed. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] short critique of site
Might I add: 8) The bug database link should point to a page where an user is advised to look in the sites of the single components instead of pointing to http://jakarta.apache.org/site/bugs.html Henri Yandell wrote: Some thoughts on the site. A] Looking at the front page. 1) Jakarta link on the bar is redundant. We already have a huge logo in the top left. 2) No need to include the direct svn link, just use viewcvs. Simpler for the user. 3) Korea translation link is dead. 4) Japanese translation link is out of date. 5) While the wiki is unofficial documentation, it is an official resource. 6) DB Commons is empty. 7) Contributor page. Is this worth the effort of the maintenance? B] Clicking on sandbox. 1) There are many projects which have become dormant. How should we be changing the site? 2) Corresponding Wiki page needs changing [my fault :) ] Okay, onto something else next. - 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] Release Configuration 1.2
Sorry Oliver I was on vacation this week. Here is my +1 Emmanuel Bourg Oliver Heger wrote: There has been no reaction on this vote thread so far. Will I have to cancel this release because of lack of interest? :-( Oliver Oliver Heger wrote: Since the 1.1 release of Configuration we have implemented a couple of fixes and added some new features. To make these enhancements available for the public we are heading for a 1.2 release. The second release candidate for Configuration 1.2 has been available for a while now and no issues have been reported (after a minor issue in RC1 had been fixed). So this is the call for the vote. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Find the distros of the RC at http://people.apache.org/~oheger/commons-configuration-1.2RC2/ The web site can be found here: http://people.apache.org/~oheger/commons-configuration-1.2RC2-docs/ Oliver for the Commons Configuration team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] short critique of site
Henri Yandell wrote: 7) Contributor page. Is this worth the effort of the maintenance? I don't know how this page is maintained currently, but maybe it could be built automatically from the POMs with a script ? Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedparser
1 dec 2005 kl. 23.35 skrev robert burrell donkin: On Thu, 2005-12-01 at 22:44 +0100, karl wettin wrote: Is the sandbox project feed parser abandoned? I have updated the source to work with the new jdom and would like to commit my updates as I presume they are wanted. Sent an e-mail to Kevin a few days ago, but there is no reply. The whole repository is somewhat a mess too. Maven dependencies are bad will not build, et.c. It's a shame on such a nice project. I would be happy to fix it up. good question: i'm not sure. hopefully some folks who know more will jump in now... IIRC feedparser had been elected to the commons proper and was being moved there. IIRC? would you mind checking out proper, taking a look around and reporting back what you find? The last activity I found was from march on this list, when Kevin was voting for 0.5rc. He was also talking about 0.6rc and 1.0, but did not get the +3. I'll wait another week for his reply. -- karl silvertejp.tirgris.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote][net] Release commons-net 1.4.1?
On Thu, 2005-12-01 at 21:02 -0500, Henri Yandell wrote: For the thread's info; Robert's cc'd Rory on the pmc email. This is legal shit and irritatingly it seems there are increased liability issues when you talk publically. +1 for some folks, copyright is a criminal matter (not just civil). please respect the need for some confidentially in these matters. Any active committer should be on the PMC, unless they've only recently joined, so if you're active kick away and one of us will gladly nominate you. +1 - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Together, and bricks apart
On 12/2/05, Phil Steitz [EMAIL PROTECTED] wrote: On 11/30/05, Mario Ivankovits [EMAIL PROTECTED] wrote: Phil Steitz wrote: For me +1 means pretty much what Martin describes above. I check the release contents, make sure required elements are there and in jars, make sure there is nothing funny included. I test the builds, validate sigs, etc and inspect the web site and, if present, clirr/jdiff and look carefully at the release notes. I also review the javadoc, maven reports and POM. I do try to learn a little more with each release that I review; Thats true, I'll learn with every release review too, but can do this only if another one complains about this and that. If I read the stuff you do to check a release I am shocked, damn much work to do. At least one of you release checkers ;-) should setup a wiki to describe every step to do, this helps the release manager and those checking it. Especially if you are a newbie in the release cycle it might be a great start AND it defines standards. That was the intention of the releases pages: http://jakarta.apache.org/commons/releases/index.html When I get out from under water, I will add a final checklist type section, or someone else can. That is a good idea. One thing which drives me crazy is that I dont know what to do to make a project ready for a release. I have to wait if anyone complains on an RC and even then, in case of [vfs] the real release blocker were uncovered while voting for 1.0 - after we have had a couple of month one RC after another! I agree that this is frustrating and don't have a great answer. See comments at end below. The same thing just happened to me in [math]. After a couple of RCs a major issue that was really a problem with 1.0 was raised and it took a while to get it fixed. To me, this is a consequence of not wanting to release with significant known issues, which is sort of an unwritten rule which we tend to follow in commons. See Martin's response below on fix later. My view, shared by (I think) most others is that there has to be a very good reason to do that. At least on the components that I have worked on (see list below), we tend to get the real issues closed before release and to stop releases when they show up during the vote or RC testing. And e.g. we started to discuss if we have to convert line-endings - after years (!) of commons releases - and we were not able to have a vital discussion about this little topic. In the old days we kept lf line endings on all the source files in cvs and hand-rolled ant scripts were used to put crlf on the .txt files in the zips. Between maven and svn's eol=native, that is no longer possible or at least immediate. The real question (see other response) is do we care about this? From lack of response to [poll] thread, could be the answer is no. This is an interesting comment, and indicates that we haven't done things consistently across Commons components (which isn't altogether surprising). All along - including in the old days of CVS - I've worked with CR-LF line ends, and that includes quite a few releases of several different components. So with the change to SVN, I haven't been doing anything differently... These are really demotivating things! Agreed and sorry if we seem to be making things harder rather than easier. Patches - or direct commits to - the releases page and any other suggestions to make things easier are most welcome. One other comment that I have on the issue of voting on releases is that the core problem here is lack of component-committed volunteers, IMHO. I remember a couple of years back when we discussed whose votes were binding on component releases. Hen made the interesting comment that he felt that committers not working on the component should vote and their votes were as important / even more important than those of the project team. We have now devolved to the point where without these votes, we will in some cases not be able to get 3 binding +1's. This is not good. Somehow we have to reengage as Rahul pointed out at the top of this thread. IMO, what this tells us is the Commons isn't scaling, and that doesn't surprise me at all. In the old days, there were a *lot* fewer components. Right now, I count 35 components in Proper and 9 more active components in the Sandbox (excluding the ones Henri is about to make dormant). That is a lot of stuff! Very few people, if any, are going to keep tabs on all of it, and most are likely to only track a handful, if that. When Commons was much smaller, the community was much more integrated, in that there was more overlap between the pieces (people-wise, not code-wise), and so we all watched each others' backs. We're no longer in that state. The inability to scale, is, in my opinion, an issue the ASF as a whole is also facing. Unfortunately, as with Commons, I don't have any good ideas.
Re: [vote][net] Release commons-net 1.4.1?
On Fri, 2005-12-02 at 08:08 +0100, Mario Ivankovits wrote: Hi! Any active committer should be on the PMC, unless they've only recently joined, so if you're active kick away and one of us will gladly nominate you. I wasnt aware that we (the committers) are allowed to be on the PMC list. they aren't but all active committers should really be nominated for the pmc. i didn't realise before that you and rory were not or i would have nominated you before :-/ only those on the pmc are legally entitled to cast binding votes for official ASF decisions and the ASF cannot help those who are not on the pmc. so, it's crucially important that committers who make any sort of sustained contribution are nominated for the pmc. I thought it need some time until a committer can become a PMC. this culture needs to change: there are still too few people nominating new pmc'ers. IMHO it is an important part of the responsibility that comes with nominating someone as a committer that you will guide them through the first few weeks or months as a committer and (when they are ready) nominate them for the pmc. the progression from committers to pmc'er should be natural and relatively quick. definitely, all release managers should be pmc'ers. anyone who knows enough about apache to manage a release should be on the pmc. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 37761] New: - [collections] [PATCH] add insertion capability to ListOrderedMap
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37761. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37761 Summary: [collections] [PATCH] add insertion capability to ListOrderedMap Product: Commons Version: Nightly Builds Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Collections AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Most cases of list-like functionality are now covered in the svn version of LOM. There is, however, no (sensible) way to insert a mapping at an arbitrary ordinal position in the map. This patch addresses the issue; please consider it for inclusion. -Matt -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 37761] - [collections] [PATCH] add insertion capability to ListOrderedMap
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37761. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37761 --- Additional Comments From [EMAIL PROTECTED] 2005-12-02 19:48 --- Created an attachment (id=17123) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17123action=view) changes to ListOrderedMap and TestListOrderedMap adds insert(int index, Object key, Object value) method. TESTCASE included! ;) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Together, and bricks apart
On 12/2/05, Martin Cooper [EMAIL PROTECTED] wrote: IMO, what this tells us is the Commons isn't scaling, and that doesn't surprise me at all. In the old days, there were a *lot* fewer components. Right now, I count 35 components in Proper and 9 more active components in the Sandbox (excluding the ones Henri is about to make dormant). That is a lot of stuff! Very few people, if any, are going to keep tabs on all of it, and most are likely to only track a handful, if that. When Commons was much smaller, the community was much more integrated, in that there was more overlap between the pieces (people-wise, not code-wise), and so we all watched each others' backs. We're no longer in that state. The inability to scale, is, in my opinion, an issue the ASF as a whole is also facing. Unfortunately, as with Commons, I don't have any good ideas. Other than to consciously stop growing, that is, but that doesn't appear to be a popular direction. [long reply...sorry] Yep. It's my belief that Commons represents the ASF in microcosm, so trying to find solutions in Commons is a) easier than the whole ASF and b) useful to finding the whole ASF problem. I see two directions: 1) Hope a few more projects move out of Jakarta, then promote every Commons component to Jakarta subprojects and revolutionise Jakarta with some Commons concepts. It doesn't solve the problems, but it does accept that the components are increasingly being held up on the shoulders of 1 committer each, and makes us solve it at a Jakarta level, not a Commons level. 2) Reinvigorate ourselves as a community. The lip service is that we're all Commons committers and not individual component committers, but the reality is that not one of us is interested in 43+ components. We need to accept that and adapt. So I think we'd end up at 2) eventually even if 1) happens :) -- So how can we rejuvenate a community without the mantra that we don't have focus? a) Work together. I don't mean that in a hippy peacenik way. I mean actually work together. We need to get a plan for the future of each component and then form groups attacking each target, but not at the same time. So Lang 2.2 might be held up because 3 of us need to work on Collections 2.2. Etc. b) Increase ease of bringing people into the community. Three problems to hit. 1) Encouraging people to get involved (it's hard). 2) Educating people. 3) Communication noise. b-1) is always hard. We encourage this mostly by being open and by broadcasting a sense of enjoyment. Another trick is to leave the easy jobs; don't gobble up easy fun bits (which is hard, they're fun :) ). b-2) is about making the information easier to find. We've a lot of it on the site etc, but we need to take the water more to the horse's mouth. So collating it into a single document etc is my aim. b-3) The mailing list is noisy. There are noisier out there, and it's nowhere near as noisy as it used to be, but increased components, and increased committers will mean it'll be noisier than ever. It's hard to see solutions here. SVN commit messages and Bugzilla messages are important, but so is not being accused of denial-of-service attacks :) One thought I had is to have a commons-sandbox-dev@ as well (Robert -1'd it when we talked on IRC :) ). c) Martin said it above. Very few are going to keep tabs on it. We need a few people to keep tabs on it :) Either by having very few who look at it all, or by using a hierarchy (ie grouping components). The board do this now, individual board members are tasked with following up on a project's report. d) Homogeneity. We may find we should decrease the independence of the components. They're pretty similar already, but I'm thinking that we could simplify the website a lot by moving away from Maven and having a Commons site, instead of individual Commons Xxx sites. This has a few advantages. It brings us together as a community more, it simplifies deploys that change the site, and it should make things a fair bit easier for readers of the site too. --- To make it all fun, we have to do this without turning it into a monotonous workplace. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Committer cleanup
Two reasons. 1) Oversight. So it's much more obvious when a project is inactive and low on committers. 2) Tidyness. I hate the thought of the long committer lists just growing longer and more inaccurate. I'm looking for a way to represent the active community of a subproject, and while there might be active individuals who just deal with answers on the mailing list etc, largely the svn commit lists are the best way to record this. Hen On 12/2/05, Eric Pugh [EMAIL PROTECTED] wrote: I agree with the 1 year mark. I know that there are projects that I haven't worked on for six months until the itch came back and I had to scratch it! Is there any reason to remove committers? Performance? Security? It seems to raise a barrier to reentry for dormant committers. Eric On Dec 2, 2005, at 1:58 AM, Mario Ivankovits wrote: Henri Yandell wrote: I'd like to go ahead and remove all the committers from subversion for commons, and then add back anyone who has committed in the last 6 months. 1 year - and if possible take the user/dev mailinglist for this project into account. A commiter active in the mailinglist is also a valuable part of a project and for the community. --- Mario - 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][net] Release commons-net 1.4.1?
On 12/2/05, robert burrell donkin [EMAIL PROTECTED] wrote: this culture needs to change: there are still too few people nominating new pmc'ers. IMHO it is an important part of the responsibility that comes with nominating someone as a committer that you will guide them through the first few weeks or months as a committer and (when they are ready) nominate them for the pmc. the progression from committers to pmc'er should be natural and relatively quick. definitely, all release managers should be pmc'ers. anyone who knows enough about apache to manage a release should be on the pmc. It's the wrong list, ie) should be on general@, but I'm thinking that we should just set in stone a date at which point a new committer is listed on the pmc list and asked if they should be on the pmc (to the person nominating them as committers). So let's say Robert becomes a committer today. This would be noted in a file. In 6-9 months time (ie when the chair does the report), any 6 month old committers would involve a question to the person nominating them as committers as to why they shouldn't be nominated. So culture change. One in which people are challenged to exclude, not expected to remember to include. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote][net] Release commons-net 1.4.1?
Henri Yandell wrote: On 12/2/05, robert burrell donkin [EMAIL PROTECTED] wrote: this culture needs to change: there are still too few people nominating new pmc'ers. IMHO it is an important part of the responsibility that comes with nominating someone as a committer that you will guide them through the first few weeks or months as a committer and (when they are ready) nominate them for the pmc. the progression from committers to pmc'er should be natural and relatively quick. definitely, all release managers should be pmc'ers. anyone who knows enough about apache to manage a release should be on the pmc. It's the wrong list, ie) should be on general@, but I'm thinking that we should just set in stone a date at which point a new committer is listed on the pmc list and asked if they should be on the pmc (to the person nominating them as committers). So let's say Robert becomes a committer today. This would be noted in a file. In 6-9 months time (ie when the chair does the report), any 6 month old committers would involve a question to the person nominating them as committers as to why they shouldn't be nominated. So culture change. One in which people are challenged to exclude, not expected to remember to include. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hen: This is a valuable discussion but perhaps we need a different subject for the thread? To get back to the original subject matter: It looks as though Rory was pretty well able to resolve the questions about the provenance of his code, although, I understand the lawyers may still want to look a little closer. Do you have any idea when this cloudlet might be lifted and we can contemplate a release? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote][net] Release commons-net 1.4.1?
On 12/2/05, Steve Cohen [EMAIL PROTECTED] wrote: To get back to the original subject matter: It looks as though Rory was pretty well able to resolve the questions about the provenance of his code, although, I understand the lawyers may still want to look a little closer. Do you have any idea when this cloudlet might be lifted and we can contemplate a release? Has the code already been in a release? As long as it has, I don't see any harm in continuing. It just adds another distributable in which we'd have to fix the problem; which is just to make sure we get the original author's official permission, instead of the unofficial permission. If it hasn't been in a release, we should hold off until we can. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of FrontPage by HenriYandell
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by HenriYandell: http://wiki.apache.org/jakarta-commons/FrontPage The comment on the change is: Added CommonsManual link. -- == Developer Documentation == + * A CommonsManual. + * MovingFromSandboxToProper * [:MovingFromSandboxToProperSVN] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of CommonsManual by HenriYandell
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by HenriYandell: http://wiki.apache.org/jakarta-commons/CommonsManual The comment on the change is: A proposal for a one-stop shop for education on Commons New page: = A Manual for new Commons committers = Idea being that we bring the various how-to's and guides into one centralised document/book/site/thing. It should be both easily viewable online, and printable so you can sit on the toilet and read about our goings on. == Table of Contents == * Introduction to Commons - What it's all about. * Communication. How to use the mailing lists. Voting. * Subversion information. How to check code out. * Maven information. How to build. * Site information. How to generate the site. How to upload your changes. * Releasing. How to release. * PMC. What it's there for. * Legal. How to not screw-up. * How the sandbox works / how components get promoted / how components get made dormant/active/dead. * Programming guidelines. The following links contain material to fill the above with: * JakartaCommonsEtiquette * GettingInvolved * UsingSVN * ProposalSandboxPruning * MovingFromSandboxToProper * MovingFromSandboxToProperSVN * CreatingStandardWebPresence * GettingInvolved * SigningReleases * http://jakarta.apache.org/commons/charter.html * http://jakarta.apache.org/commons/volunteering.html * http://jakarta.apache.org/commons/patches.html * http://jakarta.apache.org/commons/building.html * http://jakarta.apache.org/commons/releases/index.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta-commons Wiki] Update of CommonsManual by HenriYandell
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by HenriYandell: http://wiki.apache.org/jakarta-commons/CommonsManual The comment on the change is: Fixing 2 links. -- * JakartaCommonsEtiquette * GettingInvolved - * UsingSVN + * [UsingSVN] * ProposalSandboxPruning * MovingFromSandboxToProper - * MovingFromSandboxToProperSVN + * [MovingFromSandboxToProperSVN] * CreatingStandardWebPresence * GettingInvolved * SigningReleases - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Committer cleanup
On 12/1/05, Martin Cooper [EMAIL PROTECTED] wrote: On 12/1/05, Henri Yandell [EMAIL PROTECTED] wrote: I'd like to go ahead and remove all the committers from subversion for commons, and then add back anyone who has committed in the last 6 months. We have 105 commons committers, and 36 additional sandbox committers. We've had 43 committers committing to proper, and 7 extra committing to sandbox in the last 6 months. Then we'd add back anyone else on request if need be. Anyone against the idea? 6 months seems quite short if you're only counting commits. Would the numbers be significantly different if we use 1 year instead? FYI, In the last year, 53 committers committing to proper, and 8 extra committing to the sandbox. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r351899 - /jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
Author: martinc
Date: Fri Dec 2 22:01:02 2005
New Revision: 351899
URL: http://svn.apache.org/viewcvs?rev=351899view=rev
Log:
Make inner exception classes static, which they should have been all along.
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
Modified:
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java?rev=351899r1=351898r2=351899view=diff
==
---
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
(original)
+++
jakarta/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/MultipartStream.java
Fri Dec 2 22:01:02 2005
@@ -721,7 +721,7 @@
* Thrown to indicate that the input stream fails to follow the
* required syntax.
*/
-public class MalformedStreamException
+public static class MalformedStreamException
extends IOException {
/**
* Constructs a codeMalformedStreamException/code with no
@@ -746,7 +746,7 @@
/**
* Thrown upon attempt of setting an invalid boundary token.
*/
-public class IllegalBoundaryException
+public static class IllegalBoundaryException
extends IOException {
/**
* Constructs an codeIllegalBoundaryException/code with no
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
