DO NOT REPLY [Bug 34942] - [VFS] no vfs_cache cleanup after ant task completed

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=34942





--- Additional Comments From [EMAIL PROTECTED]  2005-05-21 08:45 ---
I ran the code you suggested in a unit test under Ant.  It succeeded in deleting
the "vfs_cache" directory after it finished!  BTW, why the need to cast to a
StandardFileSystemManager?  The only reason I see for needing to reference
classes in the vfs.impl package is for the close() method which does the
cleanup.  If I remove that method, nothing is cleaned up.  Shouldn't that be on
the interface to allow for triggering cleanup without having to reference the
implementation?

Also, when do the Ant tasks call close()?  If they don't, I guess it makes sense
why things aren't getting cleaned up.


Jake

-- 
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: [jelly] SOLVED: Maven issue with Hans memory leak patch

[Hans Gilde]

Wait... strike this new patch. My old one should be fine. Now I'm jumping to
conclusions because I haven't looked at it for so long.

Brett, what's being reused where it wasn't before? I would not expect this
behavior.

-Original Message-
From: Hans Gilde [mailto:[EMAIL PROTECTED] 
Sent: Saturday, May 21, 2005 1:48 AM
To: 'Jakarta Commons Developers List'
Subject: RE: [jelly] SOLVED: Maven issue with Hans memory leak patch

Sorry not to be around so much any more. I got laid off and had to find a
new job.

I'm so sorry to say that my memory leak patch has a big flaw in it. It
should not have caused the tag to be improperly reused.

I'm happy to say that I have a fix (replacement), which is attached. This
patch should work without the fix to Maven.

I didn't like the tag cache for two reasons: (1) it practically guarantees
leaks for applications that use the current jelly and aren't expecting it
and (2) I thought I had a good solution, which has now taken much longer to
implement than I expected.

Paul, you probably know, but you can't disable caching in the current code,
because some kinds of tags rely on it. This is a big issue with Jelly.
However, in the next version (should we actually get there :), I agree that
the whole life cycle should be separated.

-Original Message-
From: Paul Libbrecht [mailto:[EMAIL PROTECTED] 
Sent: Sunday, May 01, 2005 2:32 PM
To: Jakarta Commons Developers List
Subject: Re: [jelly] SOLVED: Maven issue with Hans memory leak patch

Le 1 mai 05, à 19:36, peter royal a écrit :
> On May 1, 2005, at 9:09 AM, Brett Porter wrote:
>> I've solved this problem. One of the jelly tags was relying on a new
>> instance being created, but the instance is now being reused. Note 
>> that
>> the tag is the same call from the same script, so I assume that this 
>> is
>> valid, so I have made the tag not be stateful and it fixed the Maven
>> problem.
>> Does anyone know if this is correct behaviour?
> Sounds correct to me :)

Yes, this sounds also correct to me...
I think the assumption that a new instance of tag-objects be created 
was correct if one would set not to "cache" tags (using the formerly 
available setCacheTags method); this was probably the default.
SInce the thread-local fixes, all tags are cached and...

I am wondering wether there would be wish to bring back the method 
setCacheTags and actually disable caching in some circumstances. I 
would rather say it's better to keep it out as it makes life-cycle 
easier to write for tags (and one can still clear the contexts).

Brett, I'm really looking forward to your commit (which will include 
Hans' patch, then, correct?).
 From there on we should hunt for 1.0!

paul


-
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] SOLVED: Maven issue with Hans memory leak patch

[Hans Gilde]

Ok, things have moved on somewhat from when I did my patch from CSV, and my
SVN stuff isn't working right. So, that last parch was from the really old
CVS.

-Original Message-
From: Hans Gilde [mailto:[EMAIL PROTECTED] 
Sent: Saturday, May 21, 2005 1:48 AM
To: 'Jakarta Commons Developers List'
Subject: RE: [jelly] SOLVED: Maven issue with Hans memory leak patch

Sorry not to be around so much any more. I got laid off and had to find a
new job.

I'm so sorry to say that my memory leak patch has a big flaw in it. It
should not have caused the tag to be improperly reused.

I'm happy to say that I have a fix (replacement), which is attached. This
patch should work without the fix to Maven.

I didn't like the tag cache for two reasons: (1) it practically guarantees
leaks for applications that use the current jelly and aren't expecting it
and (2) I thought I had a good solution, which has now taken much longer to
implement than I expected.

Paul, you probably know, but you can't disable caching in the current code,
because some kinds of tags rely on it. This is a big issue with Jelly.
However, in the next version (should we actually get there :), I agree that
the whole life cycle should be separated.

-Original Message-
From: Paul Libbrecht [mailto:[EMAIL PROTECTED] 
Sent: Sunday, May 01, 2005 2:32 PM
To: Jakarta Commons Developers List
Subject: Re: [jelly] SOLVED: Maven issue with Hans memory leak patch

Le 1 mai 05, à 19:36, peter royal a écrit :
> On May 1, 2005, at 9:09 AM, Brett Porter wrote:
>> I've solved this problem. One of the jelly tags was relying on a new
>> instance being created, but the instance is now being reused. Note 
>> that
>> the tag is the same call from the same script, so I assume that this 
>> is
>> valid, so I have made the tag not be stateful and it fixed the Maven
>> problem.
>> Does anyone know if this is correct behaviour?
> Sounds correct to me :)

Yes, this sounds also correct to me...
I think the assumption that a new instance of tag-objects be created 
was correct if one would set not to "cache" tags (using the formerly 
available setCacheTags method); this was probably the default.
SInce the thread-local fixes, all tags are cached and...

I am wondering wether there would be wish to bring back the method 
setCacheTags and actually disable caching in some circumstances. I 
would rather say it's better to keep it out as it makes life-cycle 
easier to write for tags (and one can still clear the contexts).

Brett, I'm really looking forward to your commit (which will include 
Hans' patch, then, correct?).
 From there on we should hunt for 1.0!

paul


-
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] SOLVED: Maven issue with Hans memory leak patch

[Hans Gilde]

Sorry not to be around so much any more. I got laid off and had to find a
new job.

I'm so sorry to say that my memory leak patch has a big flaw in it. It
should not have caused the tag to be improperly reused.

I'm happy to say that I have a fix (replacement), which is attached. This
patch should work without the fix to Maven.

I didn't like the tag cache for two reasons: (1) it practically guarantees
leaks for applications that use the current jelly and aren't expecting it
and (2) I thought I had a good solution, which has now taken much longer to
implement than I expected.

Paul, you probably know, but you can't disable caching in the current code,
because some kinds of tags rely on it. This is a big issue with Jelly.
However, in the next version (should we actually get there :), I agree that
the whole life cycle should be separated.

-Original Message-
From: Paul Libbrecht [mailto:[EMAIL PROTECTED] 
Sent: Sunday, May 01, 2005 2:32 PM
To: Jakarta Commons Developers List
Subject: Re: [jelly] SOLVED: Maven issue with Hans memory leak patch

Le 1 mai 05, à 19:36, peter royal a écrit :
> On May 1, 2005, at 9:09 AM, Brett Porter wrote:
>> I've solved this problem. One of the jelly tags was relying on a new
>> instance being created, but the instance is now being reused. Note 
>> that
>> the tag is the same call from the same script, so I assume that this 
>> is
>> valid, so I have made the tag not be stateful and it fixed the Maven
>> problem.
>> Does anyone know if this is correct behaviour?
> Sounds correct to me :)

Yes, this sounds also correct to me...
I think the assumption that a new instance of tag-objects be created 
was correct if one would set not to "cache" tags (using the formerly 
available setCacheTags method); this was probably the default.
SInce the thread-local fixes, all tags are cached and...

I am wondering wether there would be wish to bring back the method 
setCacheTags and actually disable caching in some circumstances. I 
would rather say it's better to keep it out as it makes life-cycle 
easier to write for tags (and one can still clear the contexts).

Brett, I'm really looking forward to your commit (which will include 
Hans' patch, then, correct?).
 From there on we should hunt for 1.0!

paul


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: src/java/org/apache/commons/jelly/JellyContext.java
===
RCS file: 
/home/cvs/jakarta-commons/jelly/src/java/org/apache/commons/jelly/JellyContext.java,v
retrieving revision 1.66
diff -u -r1.66 JellyContext.java
--- src/java/org/apache/commons/jelly/JellyContext.java 27 Jan 2005 05:52:27 
-  1.66
+++ src/java/org/apache/commons/jelly/JellyContext.java 21 May 2005 05:40:54 
-
@@ -92,20 +92,6 @@
 /** Should we export tag libraries to our parents context */
 private boolean exportLibraries = true;
 
-/** Maps a Thread to its local Script data cache. It's 
- * like a ThreadLocal, but it reclaims memory better
- * when the JellyCointext goes out of scope.
- * This isn't a ThreadLocal because of the typical usage scenario of
- * JellyContext. ThreadLocal is meant to be sued as a static variable,
- * we were using it as a local variable.
- * [EMAIL PROTECTED] #setThreadLocalScriptData(Script,Object)}
-  */
-private Map threadLocalScriptData = Collections.synchronizedMap(new 
WeakHashMap());
-// THINKME: Script objects are like Object (for equals and hashCode) I 
think.
-//  It should be asy to optimize hash-map distribution, e.g. by
-//  shifting the hashcode return value (presuming Object.hashcode()
-//  is something like an address)
-
 /**
  * Create a new context with the currentURL set to the rootURL
  */
@@ -390,93 +376,20 @@
 return createChildContext();
 }
 
-
-/** Gets the Script data item that may have previously been stored
- * by the script, in this context, for the current thread.
- *  
- * @return the tag associated with the current context and thread
-  */
-public Object getThreadScriptData(Script script) {
-if( script == null )
-return null;
-Tag tag = (Tag) getThreadScriptDataMap().get(script);
-   if( tag == null && getParent() != null) {
-   return getParent().getThreadScriptData(script);
-   } else {
-   return tag;
-   }
-}
-   
-   /** Gets a per-thread (thread local) Map of data for use by
- * Scripts.
- * @return the thread local Map of Script data */
-   public Map getThreadScriptDataMap() {
-Map rv;
-Thread t = Thread.currentThread();
-Map data = (Map) threadLocalScriptData.get(t);
-if (data == null) {
-rv = new HashMap();

Fw: [Fwd: [commons-email] RFC about improving the code ....]

[James Mitchell]

Re: [Fwd: [commons-email] RFC about improving the code ...FYI...This was 
hung in moderation.


--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM:   jmitchtx
Yahoo: jmitchtx
MSN:   [EMAIL PROTECTED]

- Original Message - 
From: Joe Germuska
To: Jakarta Commons Developers List
Sent: Thursday, May 19, 2005 2:56 PM
Subject: Re: [Fwd: [commons-email] RFC about improving the code ]

This is interesting; I've just recently been thinking about asking the 
community if there would be interest in adjusting commons-email so that 
there was a "Sender" API.  I'm not quite sure how we would re-engineer it in 
a backwards compatible way, but I'm interested in an architecture which 
prevents my development team from accidentally thinking that it's OK to send 
a message directly in an app; instead, they'd have to use the Sender 
Implementation.

This would then enable dropping in an implementation which didn't actually 
send the message, as in for example a test or development environment.

If there's interest in this, does anyone have a strategy for doing it?  It 
is a little late to remove the "send()" method, although I suppose it could 
be deprecated.

Joe

At 7:13 PM +0200 5/19/05, Siegfried Goeschl wrote:
FYI
Siegfried Goeschl
 Original Message 
Subject: [commons-email] RFC about improving the code  Date: Thu, 19 May 
2005 19:10:17 +0200 From: Siegfried Goeschl <[EMAIL PROTECTED]> 
Reply-To: [EMAIL PROTECTED] Organization: IT20one GmbH To: Eric 
Pugh <[EMAIL PROTECTED]>


Hi Eric,
long story - since I'm in the middle of migrating my old Turbine
application to CVS HEAD I stumbled across commons-email and I'm
currently migrating a very old Turbine service for sending emails to use
commons-email to a Fulcrum service and having a few problems, and .
Since the mailing list does not respond to my subscription and you are
the main committer  I need to patch the existing code to fulfill
some basic requirements
1) having a few getters for basic properties of EMail would be nice
(subject, fromAddress) to enable some diagnostic ouptut if anything goes
wrong while creating the MimeMessage. Having said that a toString()
implementation would not be bad either.
2) more significant I need to seperate the creation of the underlying
MimeMessage from actually sending it, e.g. I do a lot of stuff with
SMIME signature where you build the MimeMessage and then sign it.
Building the MimeMessage (the hard part) is already done by
commons-email but it would be useful to intercept the actual sending to
provide more flexibility. I think of
public final MimeMessage getMimeMessage();
public void buildMimeMessage() throws EmailException;
public void sendMimeMessage() throws EmailException;
public void send() throws EmailException
{
  this.buildMimeMessage();
  // now it is possible to call getMimeMessage()
  this.sendMimeMessage();
}
3) access to the MimeMessage allows to retrieve the message id - the
only way to keep track of message sent by the SMPT server
I hope my comments make sense - could you forward the message to the
mailing list  ... as always I have little time to wait for the outcome
of lenghty discussion so I start doing the work tommorrow ... :-)
Cheers,
Siegfried Goeschl

--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex 


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

[lang] Interpolation

[Oliver Heger]

Hi,
a while ago there was a discussion about adding support for variable 
substitution/interpolation to lang. IIRC Simon Kitching proposed to 
extract the interpolation engine of digester. I'd like to know the 
current state of this project. Has there already been some work in this 
direction?

Background is that I would need such a feature for [configuration] where 
we plan to enhance our interpolation features. (ATM we have a dependency 
on [digester], but this will probably be removed in the future.)

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

Re: [logging] test cases 1 to 4

[Ceki Gülcü]

At 03:05 5/19/2005, Simon Kitching wrote:
On Wed, 2005-05-18 at 17:58 +0200, Ceki Gülcü wrote:
> Robert et al.,
>
> Your test cases are self-describing and easy to follow. One can hardly
> appreciate the work gone into putting in place something as delicate
> and tedious as these test cases. Well done!
Yes, I think so to.
>
> At first I was a bit puzzled that the static branch failed, and
> initially suspected the correctness of the test cases. However, given their
> construction, it is only normal for the static branch of tests 1 to 4
> to fail. It actually goes to prove that the test framework is doing
> its job correctly.
>
> However, if the intention was to compare dynamic binding versus
> static-binding, the setup of tests 1 to 4 is unrepresentative of the
> static-binding case, unless I am missing the point. For tests 1-4, you
> are demonstrating the fact that a parent class loader cannot see
> resources available to its children. Isn't this kind of obvious?
I think it's more a complete table of all combinations of 4 or 5
different factors. Not all of them are sensible, but it means that the
combinations are all complete.
In  static  binding,  the  facade  and the  implementation  are  bound
together at compile  time. So it's totally impossible  for client code
to find the facade but  not the implementation. Actually, if that were
not  the  case,  that  is  if   the  facade  was  found  and  not  the
implementation, or if the implementation was found but not the facade,
it would mean that something seriously wrong had gone within the JVM.
If the intent is to permute through all the possible combinations,
then that's a different matter. Wouldn't it be actually better to test
combinations that make sense?
As I note here, scenarios 17 and 21 (plus a few others) are simply not
reasonable ones, and can be ignored from any reasonable assessment of
whether a particular logging setup works or not.
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=111578975603542&w=2
It would be nice to note in the associated document which are scenarios
that can be ignored as not reasonable.
My document here
   http://people.apache.org/~skitching/jcl-req.txt
describes a specific scenario where I think static binding doesn't work
(see b4) - and it is quite a reasonable requirement I think. Of course
there are many scenarios where static binding is a very good solution.
I'm thinking that the best solution is one where the user can select
static binding for the majority of cases (ie deploy a simple jar that is
statically bound), but drop in a more dynamic factory class in the
problem scenario.
Selecting static binding for the majority of cases but having a way to 
dynamically select factory sounds very promising.

 Essentially, this results in merging of the current
SLF4J and JCL approaches, and I think it's entirely feasable (and even
without breaking existing code). This should give performance and
simplicity for most users (static) with the ability to use a more
dynamic approach in situation b4. See my post coming soon...
Regards,
Simon
--
Ceki Gülcü
  The complete log4j manual: http://www.qos.ch/log4j/

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

Re: [chain] Pre-conditions

[Joe Germuska]

While I've used an "checkPreconditions" type approach in some of my 
Command implementations, I'm not sure I feel like I've got anything 
I'd want to codify as "best practices" in formal interfaces in 
commons-chain.

However, when you suggest annotations, I think that sounds pretty 
interesting and like the right general approach, except that I'm not 
ready to bind commons-chain to Java 5.0 yet.  As you describe it, 
though, one could simply create a deluxe version of a Catalog and/or 
a Chain which enforced those checks.  That seems pretty interesting.

Since we're talking about Chain and futures, here are the two things 
I'm seeing as most interesting directions for improvement:
1) make sure that there are no dependencies on the Digester-based 
bootstrapping.  The more I use the Spring framework, the more I want 
my chains to be able to have their dependencies injected.  I recently 
made some commits that rearrange all calls to 
"CatalogFactory.getInstance()" so that they are only used as a 
fallback, but that there's always a way to set the CatalogFactory as 
a bean property (for example, for a LookupCommand).  There may not be 
a whole lot more work to do here, except for one thing -- as much as 
I like Spring, I find the XML syntax verbose compared to Digester 
based syntax.  I've spent a little time trying to figure out how to 
make a Spring BeanFactory which could somehow read from Digester but 
also handle dependency injection, but I haven't had a whole lot of 
time to get into it.  However, verbose or not, it's entirely possible 
to make commands, chains, and even catalogs in a Spring beans XML 
file, which is a nice alternative.

2) Figure out a way to decorate chains without copying their 
configuration.  Most of my chain work is in the context of Struts, 
where there's a "standard" chain included in the distribution for 1.3 
(as yet unreleased).  However, I am always making a few changes to 
that chain -- it would be nice to be able to apply commands in the 
way that you can apply "preGoal" and "postGoal" behavior in Maven. 
(You could also think of it as an "aspect-oriented" problem.)  I 
haven't spent too much time thinking about this, but partly because I 
haven't had any ideas that seemed promising to pursue.

Sorry to hijack your thread, but now that Chain is pretty stable, it 
seems like a decent time to solicit more ideas for the next steps.

Joe
At 2:25 PM +0200 5/13/05, Mattias J wrote:
I have just started using Jakarta Chains to refactor and evolve an 
existing project. I've had thoughts around this for a long time, and 
finally got around to it. When actually working with this 
API/pattern, a few questions come to mind, mostly related to the 
dependencies between different Commands in a Chain.

The post-conditions of a Command should of course be checked using 
unit tests. But what is the best practice for handling 
pre-conditions (i.e. context must be of type MyContext, context must 
contain value for key "myKey", value for "myKey" must be of type 
MyClass)?

Naturally pre-conditions should be documented in the JavaDoc of the 
Command implementation, but this is not always the best for 
mainainability and debugging.

- Should all possible Chain combinations be unit tested?
- Or would it be an idea to create a sub interface to Command to 
add, say, checkPreConditions()?
This could of course done using AOP and configuring aspects via 
annotations, for example
  @ContextType(MyContext.class)
  @RequiredKey("myKey")
  @ValueType("myKey", MyClass.class)

- Or maybe one could elaborate this even further, creating rule 
object sets returned by Commands as pre-conditions and 
post-conditions, so that a Chain would be responsible of making sure 
the different Commands are compatible when added using 
addCommand()...?

Does anyone else have any thoughts about this?

--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

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

DO NOT REPLY [Bug 32380] - [beanutils] Indexed property inside a mapped property cannot be accessed

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32380





--- Additional Comments From [EMAIL PROTECTED]  2005-05-20 14:20 ---
(In reply to comment #0)
Hi, I think the expression parser may be in cause. I feel a fix should go there.

Indeed, for JavaBean's simple properties (as well as for java.util.Map), the 
period '.' denotes the operator to dereference from one parent object's 
property to it's child object value.

Likewise, for indexed properties (as well as for java.util.List), the "[i]" 
syntax represent the derefenrencing of that element (the identifier is a 
number, not a name).

Therefore, getProperty(MYLIST, "5") should work, in analogy with getProperty
(MYMAP, "key"). It does not. In any case, the processing of "." or "[]" is left 
to the parser. 

Solving this would allow Maps of Lists, Lists of Lists, etc. I do not yet see a 
limitation, but I don't have enough knowledge of BeanUtils :-)

> Hi, guys.
> Suppose I have a Map, let's call it "building", inside that map I have an 
entry
> with key "rooms", which is a Collection. If I try to access room number 20 
like
> this:
> "building.rooms[20].type" it doesn't work (throws IllegalArgumentException).
> I made a custom implementation of "building" Map so that I can see what param 
is
> passed to the get() method. Surprisingly I see, that
> PropertyUtilsBean.getInstance().getProperty(bean, name) calls get() method on 
my
> Map with parameter "rooms[20]" (including index part). 
> This is definitely a bug, because getProperty() should recognize, that "rooms"
> is an indexed property (because it has []), so it should cut off "[20]", call
> get("rooms") and then obtain element with index 20 from the retrieved 
Collection.
> Please have a look.



-- 
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: [lang] VOTE 2.1 release (new vote based on RC5)

[Steven Caswell]

All,

The problem with generating the javadocs is indeed a bug in the maven 
javadoc plugin: 
http://marc.theaimsgroup.com/?l=turbine-maven-user&m=111654720406621&w=2 and 
http://jira.codehaus.org/browse/MPJAVADOC-59

I'll pull down the fix this weekend and generate a new release candidate.

Gary, I suspect you hadn't updated your local copy of project.xml when you 
got your clean copy of the javadoc since it was the recent addition of the 
source modification that seems to cause the problem. That is the only reason 
I can think of why yours worked and mine didn't.

On 5/19/05, Gary Gregory <[EMAIL PROTECTED]> wrote:
> 
> Steven:
> 
> If it helps, here is my Maven info:
> 
> C:\cvs-store\transidiom\deve\Java\Build>maven --info | find "javadoc"
> maven-javadoc-plugin-1.7
> 
> 
> and:
> 
> 
> C:\cvs-store\transidiom\deve\Java\Build>maven --info
> __ __
> | \/ |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
> |_| |_\__,_|\_/\___|_||_| v. 1.0.2
> 
> # BEGIN: Which report
> Which.version=Which.java:($Revision: 1.2 $) WhichJar.java:($Revision:
> 1.2 $)
> java.version=1.4.2_08
> file.encoding=Cp1252
> java.ext.dirs=c:\java\sun\1.4.2_08\jre\lib\ext
> java.class.path=C:\Program Files\Apache Software Foundation\Maven
> 1.0.2\lib\forehead-1.0-beta-5.jar
> os.name=Windows XP
> java.vendor=Sun Microsystems Inc.
> sun.boot.class.path=C:\Program Files\Apache Software Foundation\Maven
> 1.0.2\lib\endorsed\xerces-2.4.0.jar;C:\Program Files\Apache Software
> Foundation\Maven 1.0.2\lib\endo
> rsed\xml-apis-1.0.b2.jar;c:\java\sun\1.4.2_08\jre\lib\rt.jar;c:\java\sun
> \1.4.2_08\jre\lib\i18n.jar;c:\java\sun\1.4.2_08\jre\lib\sunrsasign.jar;c
> :\java\sun\1.4.2_08\jre\li
> b\jsse.jar;c:\java\sun\1.4.2_08\jre\lib\jce.jar;c:\java\sun\1.4.2_08\jre
> \lib\charsets.jar;c:\java\sun\1.4.2_08\jre\classes
> java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition
> # END: Which report
> 
> Installed plugins:
> maven-abbot-plugin-1.1
> maven-announcement-plugin-1.3
> maven-ant-plugin-1.8.1
> maven-antlr-plugin-1.2.1
> maven-appserver-plugin-2.0
> maven-artifact-plugin-1.4.1
> maven-ashkelon-plugin-1.2
> maven-aspectj-plugin-3.2
> maven-aspectwerkz-plugin-1.2
> maven-caller-plugin-1.1
> maven-castor-plugin-1.2
> maven-changelog-plugin-1.7.1
> maven-changes-plugin-1.5.1
> maven-checkstyle-plugin-2.5
> maven-clean-plugin-1.3
> maven-clover-plugin-1.6
> maven-console-plugin-1.1
> maven-cruisecontrol-plugin-1.6
> maven-dashboard-plugin-1.6
> maven-developer-activity-plugin-1.5.1
> maven-dist-plugin-1.6.1
> maven-docbook-plugin-1.2
> maven-ear-plugin-1.6
> maven-eclipse-plugin-1.9
> maven-ejb-plugin-1.5
> maven-faq-plugin-1.4
> maven-file-activity-plugin-1.5.1
> maven-genapp-plugin-2.2
> maven-gump-plugin-1.4
> maven-hibernate-plugin-1.2
> maven-html2xdoc-plugin-1.3.1
> maven-idea-plugin-1.5
> maven-j2ee-plugin-1.5.1
> maven-jalopy-plugin-1.3.1
> maven-jar-plugin-1.6.1
> maven-java-plugin-1.5
> maven-javacc-plugin-1.1
> maven-javadoc-plugin-1.7
> maven-jboss-plugin-1.5
> maven-jbuilder-plugin-1.5
> maven-jcoverage-plugin-1.0.9
> maven-jdee-plugin-1.1
> maven-jdepend-plugin-1.5
> maven-jdeveloper-plugin-1.4
> maven-jdiff-plugin-1.4
> maven-jellydoc-plugin-1.3.1
> maven-jetty-plugin-1.1
> maven-jira-plugin-1.1.2
> maven-jnlp-plugin-1.4.1
> maven-junit-doclet-plugin-1.2
> maven-junit-report-plugin-1.5
> maven-jxr-plugin-1.4.2
> maven-latex-plugin-1.4.1
> maven-latka-plugin-1.4.1
> maven-license-plugin-1.2
> maven-linkcheck-plugin-1.3.4
> maven-multichanges-plugin-1.1
> maven-multiproject-plugin-1.3.1
> maven-native-plugin-1.1
> maven-nsis-plugin-1.1
> maven-pdf-plugin-2.2.1
> maven-plugin-plugin-1.5.2
> maven-pmd-plugin-1.6
> maven-pom-plugin-1.4.1
> maven-rar-plugin-1.0
> maven-release-plugin-1.4.1
> maven-repository-plugin-1.2
> maven-scm-plugin-1.4.1
> maven-shell-plugin-1.1
> maven-simian-plugin-1.4
> maven-site-plugin-1.5.2
> maven-struts-plugin-1.3
> maven-tasklist-plugin-2.3
> maven-test-plugin-1.6.2
> maven-tjdo-plugin-1.0.0
> maven-uberjar-plugin-1.2
> maven-vdoclet-plugin-1.2
> maven-war-plugin-1.6.1
> maven-webserver-plugin-2.0
> maven-wizard-plugin-1.1
> maven-xdoc-plugin-1.8
> Home Build properties:
> {junit.jar=C:\cvs-store\thirdparty\JUnit\3.8.1\junit.jar}
> 
> Gary
> 
> -Original Message-
> From: Steven Caswell [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 18, 2005 2:38 PM
> To: Gary Gregory
> Cc: Jakarta Commons Developers List
> Subject: Re: [lang] VOTE 2.1 release (new vote based on RC5)
> 
> I think I found the problem. I need to do some more investigation, but
> it
> looks like an issue with the version of the maven javadoc plugin I am
> using.
> 
> It looks like the maven-javadoc-plugin version 1.7 copies the source
> files
> to a separate area when there are source modifications in project.xml,
> and
> uses this area to remove the source modifications and then builds the
> javadoc from the remaining source. Apparently it doesn't drag the .html
> files along with the .java fi

DO NOT REPLY [Bug 32801] - [collections] Provide maps with direct indexed access to the entries

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32801





--- Additional Comments From [EMAIL PROTECTED]  2005-05-20 11:07 ---
A better example code would be:

ListOrderedMap lom = new ListOrderedMap();
lom.put("3", "33");
lom.put("1", "11");
lom.put("2", "22");
for (int i = 0; i < lom.size(); i++) {
System.out.println("Key: " + lom.get(i) + "; Value: " + lom
.getValue(i));
}
System.out.println("---");
SortedArrayMap sam = new SortedArrayMap();
sam.put("3", "33");
sam.put("1", "11");
sam.put("2", "22");
for (int i = 0; i < sam.size(); i++) {
System.out.println("Key: " + sam.getKey(i) + "; Value: " + sam
.getValue(i));
}

The output is the same as in the example above.

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

[RESULT][VOTE][VFS] Promote commons-vfs to commons proper

[Mario Ivankovits]

Hello!
After one week here is the positive result of the voting:
Move out of sandbox:

+1 Simon Kitching
+1 Stephen Colebourne
+1 Dion Gillard
+0 Mark Diggory
+0 Phil Steitz
+1 Mario Ivankovits
User votes:
+1 Filip
Cut Release 1.0:

+0 Stephen Colebourne
+1 Dion Gillard
+0 Mark Diggory
+0 Phil Steitz
+1 Mario Ivankovits
User votes:
+1 Filip
So I will start to move VFS out of the sandbox, but maybe I havent 
enough spare time until Monday next week. I have to paint my living room 
this weekend :-)
Simon already reviewed the required documents and made some of them svn 
aware, I will pick them up and see what happens.

It would be nice if someone could check if my (imario) svn access rights 
for commons-proper are correctly setup and if needed adjust them.
And if one could add VFS to the bugzilla components list I would be 
thankful too.

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

[doc] release procedure

[Simon Kitching]

Hi,

Section #15 of the "release" page has me puzzled:
  http://jakarta.apache.org/commons/releases/release.html

What's the point of the first "update links" bits, and how does this
interact with how maven generates the component's website?

Thanks,

Simon


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

Re: [PGP] choose another name?

[Stefan Bodewig]

On Thu, 19 May 2005, Matt Benson <[EMAIL PROTECTED]> wrote:

> I _want_ en/decryption support as well.  Also, I see
> no reason not to provide a backing library that calls
> a gpg executable.

Or any other OpenPGP compatible suite, right.

> This is GPL-kosher AFAIK (right?).

Executing as an external process is fine, otherwise Ant would need to
remove the support for gcj or Kaffe in various places.

Stefan

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

[i18n] Basic architecture/component usage

[Mattias J]

[was "Re: [i18n PATCH] Adding provider qualifying"]
At 2005-05-19 16:41, you wrote:
But, to be honest, I'm a bit disappointed at how this project is being 
developed.  I feel that i18n would benefit tremendously by reusing instead 
of reinventing.
Since Commons Resources and i18n seems to basically solve the same problem, 
my very first post to this list a month ago included the question whether 
i18n and Resources were going to continue to co-exist, and what was the 
relationship between them. After getting the impression they would continue 
to co-exist i18n was the natural choice because of our prerequisites.

In our project we store the language specific texts in a database. Among 
60+ tables there are a few that contain several columns to provide - for 
example - text, abbreviated text and detailed description for a single ID + 
language/locale entry. So supporting multiple texts per ID is a basic 
requirement for us.

As was pointed out months ago, there's just too much you get for free by 
leveraging other components and communities.

With all do respect to those of you working on i18n, I'm not currently 
using this component in my own work, but I plan to in the near future.  At 
that time I'll most likely fork the code, strip out the bottom half 
(dealing with message retrieval) and plug in commons-resources.
To be honest I haven't really considered building i18n *on top of* 
commons-resources before. But - even though I have not studied the 
Resources API in details - I must disapprove since I do not see an 
obvious/useful way to handle the above scenario using Resources.
For this to be supported by Resources in a useful manner, Resources needs 
to be extended. And if Resources is extended in such a way, we might just 
as well move what is left in i18n into the Resources component as well.

I have no interest in trying to redo my work from Commons Resources or 
reimplement the 3 Database-based impls of such.

And what about the hundreds of JUnit tests. One thing I've been working on 
lately is getting Resources to 100% test coverage.  I would hate to ask 
someone to redo their work because I "didn't want to depend on another 
project".
Another idea would be to add a CommonsResourcesProvider wich you could opt 
to use with i18n.

FYI, I have assured i18n has 100% test coverage.
The coverage report is not currently included in the build, but if somebody 
would add emma.jar and emma_ant.jar to the lib dir, I could provide an 
updated build.xml.

 /Mattias Jiderhamn 

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