ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Murray, Mike" <...@ptc.com>
Subject RE: Classpath Wildcards
Date Thu, 12 Mar 2009 12:14:49 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=46842

-----Original Message-----
From: Paul King [mailto:paulk@asert.com.au] 
Sent: Thursday, March 12, 2009 6:16 AM
To: user@ant.apache.org
Subject: RE: Classpath Wildcards


+1 for a bug report/enhancement requrest. I need this functionality too for
a customer stuck on windows. In any case, this is core Java functionality,
ant should support it simply for the simplifications it brings in some use
cases.

Cheers, Paul.


Murray, Mike wrote:
> 
> Yes, it happens in the creation of the task's path, in Path.addExisting().
> 
> If I change the first line of code in this block:
>   
> http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/types/Path.java?view=markup
> 
>             if (f.exists()){
>                 setLocation(f);
>             } else {
>                 log("dropping " + f + " from path as it doesn't exist",
>                     Project.MSG_VERBOSE);
>             }
> 
> to this:
>             if (f.exists() || (f.getParentFile().exists() &&
> "*".equals(f.getName()))) {
> 
> I get the behavior I desire.  Maybe this change would create problems for
> other usage scenarios, but it would seem unlikely.  If so, maybe an
> attribute to enable support for java classpath wildcards could be added.
> 
> I'll submit a bug report if I don't receive any feedback contrary to my
> analysis.
> 
> Thanks, Mike
> 
> PS - I'm looking for a solution for developers who do not want to use
> mapped drives.
> 
> -----Original Message-----
> From: David Weintraub [mailto:qazwart@gmail.com] 
> Sent: Thursday, February 26, 2009 11:26 AM
> To: Ant Users List
> Subject: Re: Classpath Wildcards
> 
> There's one solution: Don't use Windows!
> (The above statement was brought to you by Linux Geeks with no Social
> Life.)
> 
> You can't use <fileset> because it actually verifies your includes.
> That's no good as you pointed out.
> 
> I've tried <pathelement path="*/*"/> and that appears as a literal
> when I print it out. However, it could be that <javac> itself is
> expanding it before passing it off to the command line.
> 
> You may have to use <exec> to get around this issue.
> 
> <soapbox MS-mode="spewing">
> This is one of the things that really pisses me off about Windows. The
> NTFS filesystem can handle somewhere around 32K for the command and
> Windows itself can handle command paths that long too. However, the
> Windows shell doesn't (at least not as a default!). The actual limit
> for both is quite a bit less than 300 characters.
> 
> This is especially hard on Java developers who have large nested
> directory structures. Heck, the same issue is also found in Window's
> own C# environment too. Even worse, if you put your directories under
> your "HOME" directory, you are by default placing them under
> "C:\Documents and Settings\<userName>", and the user name is usually
> the full name of the user. Many developers like placing their working
> directories on their desktop which means that the default path for me
> is "C:\Documents and Settings\David Weintraub\Desktop" which is almost
> 50 characters long. That's 20% of the maximum file name size even
> before I create my first file.
> </soapbox>
> 
> When you use "${basedir}" like you're suppose to, you include that 50+
> character string in all of your paths!
> 
> The solution is to use the root of the drive as your development
> directory, or if you can't do that because that's locked down, see if
> you can use the DOS subst command to redefine your base directory. For
> example:
> 
> $ subst X: "C:\Documents and Settings\David Weintraub\Desktop\AntProject"
> 
> will now allow me to reference the AntProject directory as just "X:"
> Thus, "${basedir}" goes from over 60 character to just two. That may
> give you enough space to set the path the standard way.
> 
> 
> On Thu, Feb 26, 2009 at 10:49 AM, Murray, Mike <mbm@ptc.com> wrote:
>> I'm setting up a classpath for a forked <java>.  I understand how Ant
>> wildcards work.  I was previously using ant wildcards to define the
>> classpath, but the cmd line exceeds the windows limit when ${srclib} is
>> deep.
>>
>>      <fileset dir="${srclib}">
>>         <include name="*/*.jar"/>
>>
>> I want the classpath to include the literal string "wnc/*", which is a
>> valid java classpath element.  Since I used "pathelement path",
>> shouldn't it take this as a literal?  I think it does, except that it
>> appears to validating it, and throwing it out as non-existent.  I would
>> expect this validation with "pathelement location", but not "pathelement
>> path".
>>
>> Thanks, Mike
>>
>> -----Original Message-----
>> From: Jan.Materne@rzf.fin-nrw.de [mailto:Jan.Materne@rzf.fin-nrw.de]
>> Sent: Thursday, February 26, 2009 12:02 AM
>> To: user@ant.apache.org
>> Subject: AW: Classpath Wildcards
>>
>>>I'm trying to use Java's Classpath wildcards to limit the cmd length on
>>>forked java calls.
>>>
>>>   <pathelement path="${srclib}/wnc/*"/>
>>
>>
>> That's not a Java wildcard, it's an Ant wildcard.
>> Because <pathelement> is an Ant construct and Java wildcard can only be
>> used from the command line.
>>
>>
>>>But, Ant is throwing it out.
>>>  dropping L:\Windchill\srclib\wnc\* from path as it doesn't exist
>>>       [java] Executing 'D:\programs\jdk1.6.0_10\jre\bin\java.exe' with
>> arguments:
>>>Is there any way to do this?
>>
>>
>> Ant doesnt pass all found classfiles to the program - it sets up a
>> classloader. Therefore
>> it can handle large numbers of files itself.
>>
>> So use an Ant wildcard:
>>  <pathelement path="${srclib}/wnc/**"/>
>> (add one star ;)
>>
>>   '*'   every file in the directory
>>   '**'  every file somewhere under the directory
>>
>>
>> Jan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
>> For additional commands, e-mail: user-help@ant.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
>> For additional commands, e-mail: user-help@ant.apache.org
>>
>>
> 
> 
> 
> -- 
> --
> David Weintraub
> qazwart@gmail.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Classpath-Wildcards-tp22216583p22473177.html
Sent from the Ant - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org

Mime
View raw message