RE: [NB-EAP] Exposing CVS/Custom Actions from another module on D ataLoaders

["Edwards, Jayme" <JC...@software.rockwell.com>]

crossposting to ant-dev for apache help (if available)...

> [I am crossposting this because the APIs list is more appropriate for
> you...]
> 
> > I'm working on my module for Ant and finally figured out how 
> > to get the dataloader for ant project files to work 
> > irregardless of the repository type in which it was mounted 
> > (CVS, local, etc.) a few days ago.
> 
> Hmm...what were you doing before? If it was ever *not* 
> working on one kind
> of filesystem then you were probably doing something wrong, 
> since use of
> FileObject should simply gloss over these details for you.

I needed to determine the local filename from a filesystem for passing to Ant using Apache's API and was originally casting to LocalFileSystem.

> 
> > Right now one of the 
> > things I'm trying to do is allow execution of the CVS 
> > commands on my node if it has been mounted in a CVS 
> > repository. I know with things like the ToolsAction you can 
> > enable it's CookieAction and it will display only the 
> > contained commands that are enabled. I need a way to do this 
> > with CVS so I can check-in/check-out the project file while 
> > still getting access to my custom actions.
> 
> Use FileSystemAction in your DataNode's popup menu. (If you use API
> templates for a DataNode it will already be there.) If 
> FileSystemAction is
> there, then all the filesystem-specific commands (e.g. CVS commands)
> applicable to the file should be shown automatically. You need not and
> should not do anything else to support CVS.

Got CVS support working, thank you.

> > Also, I would like 
> > to do this for the XML module's "edit" function if it's 
> > available.
> 
> You can place EditAction in your popup if you have an 
> EditCookie. If you
> mean you wish to use the editing capabilities of XML files, 
> then that is a
> different matter. First, for text editing you can just make 
> sure you specify
> "text/xml" as the MIME type for the EditorSupport you add to your data
> object; if the XML module is installed and its syntax 
> coloring is working,
> then you will get XML-mode syntax coloring. For the structure 
> editing of the
> XML module, you would probably need to subclass the XML data 
> object class,
> which will allow Ant config files to be treated as general 
> XML files (plus
> your special additions) but makes your module dependent on 
> the XML support
> (which is in IE not CE), so I would probably not recommend this.

I've taken out the requirement for the XML module and have instead generically 
added EditorSupport for "text/xml" to delegate to the appropriate one if available.

> > I'm using module dependencies in the manifest for 
> > my module to check for the existence of the module, so that's 
> > not a problem.
> 
> Of the XML module? Again, this is technically correct but 
> remember that XML
> support is not freely available (in free beta now but it is 
> part of IE).
> 
> > I guess the biggest question is, is there an 
> > API from which the list of all /custom/ actions can be 
> > retrieved, and integrated with existing modules?
> 
> This could mean several things...FileSystemAction specifically handles
> actions pertaining to filesystems; ToolsAction is used for 
> general actions
> added by modules which could be applicable to nodes created by other
> modules. All actions should be placed into the Actions pool 
> but this is
> normally used for the user to be able to configure actions in various
> places, not for programmatic use. One note: you asked above to use the
> EditAction from the XML module; remember that EditAction itself is
> completely generic and in fact only asks for and runs an EditCookie.
> Similarly for OpenAction/OpenCookie, etc. What you really are 
> asking for is
> the cookie implementation from the XML module, not the action.

One more thing!!!! I want to add support for locating the files in which javac errors have occurred. I am going to write some code that will try to figure out the location of 
your source directories relative to wherever you mounted the directory containing the Ant project file(s). Then I am going to try to figure out how to catch the filename/line number of compiler errors to allow the user to bring up the source file by double-clicking on the error in the output window (or the tab I've created - I give the user the option of building targets with or without their own tab). Can you give me any hints on how to determine whether the text in the output window was generated by javac and how to catch events fired on it when the use clicks? Any help would be excellent.

Jayme

RE: Jikes file limit?

[Michael McCune <mc...@pop.peoplescape.com>]

It was suggested that I try and increase my NT environment size to try and
get around this problem.  I searched far and wide in order to see if this
was possible, but couldn't find any solution.

So, in response to this problem, I modified the Javac task to split up the
list of files sent to jikes in the doJikesCompile() method.  So if the
number of files to be compiled is over 300 (the magic number here for our NT
systems seemed to be 384 and above) it splits up the list, and calls
compiler.compile() on the separate lists.

This only runs on System.getProperty("os").startsWith("Windows").  I
attached the modified Javac.java file.

Is everyone opposed to this modification?  It took me quite a while to
figure out that jikes wasn't doing anything if the list of files was over
300+ members long, and I don't want anyone else to have to go through this.
We have been using this modification for over a week with no problems, and
we are able to compile our 500+ files without a hitch using Jikes.

Mike

-----Original Message-----
From: Michael McCune [mailto:mccune@pop.peoplescape.com]
Sent: Tuesday, April 25, 2000 1:54 PM
To: ant-dev@jakarta.apache.org
Subject: Jikes file limit?


Suddenly out of the blue, nothing was getting compiled in our project using
ant and jikes.  When we would do a clean build of all our class files, the
build directory would be created, but when the javac task was invoked
(build.compiler="jikes") nothing would happen.  We removed the
build.compiler property so the standard javac would be used and everything
worked just fine.

After confusion and floundering we took a guess that perhaps there was a
physical limit to the number of files that could be compiled by jikes.  We
started deleting files and found that we could compile at a maximum 383
files and nothing more.  If we added one more file up to 384 files, jikes
would appearantly error and not compile a single file in our tree.

I'm assuming this is a limitation of the fact that jikes gets invoked by
exec'ing a process through the command shell and perhaps NT doesn't like
300+ arguments to a command?  Our machines have 384megs of memory, which I'm
assuming is a funny coincidence between the number of files that can/can't
be compiled.

Has anyone seen this?  We've replicated it on a few machines here in our
development environment...  Any thoughts on a work around?  The ugly option
is to re-write the Jikes task to split up the file list and arguments into
multiple commands so this limit doesn't get hit.  My less ugly option is to
switch to JDK 1.3's new "fast" compiler but is not really what I want to do.

Thanks
Mike McCune

Jikes file limit?

[Michael McCune <mc...@pop.peoplescape.com>]

Suddenly out of the blue, nothing was getting compiled in our project using
ant and jikes.  When we would do a clean build of all our class files, the
build directory would be created, but when the javac task was invoked
(build.compiler="jikes") nothing would happen.  We removed the
build.compiler property so the standard javac would be used and everything
worked just fine.

After confusion and floundering we took a guess that perhaps there was a
physical limit to the number of files that could be compiled by jikes.  We
started deleting files and found that we could compile at a maximum 383
files and nothing more.  If we added one more file up to 384 files, jikes
would appearantly error and not compile a single file in our tree.

I'm assuming this is a limitation of the fact that jikes gets invoked by
exec'ing a process through the command shell and perhaps NT doesn't like
300+ arguments to a command?  Our machines have 384megs of memory, which I'm
assuming is a funny coincidence between the number of files that can/can't
be compiled.

Has anyone seen this?  We've replicated it on a few machines here in our
development environment...  Any thoughts on a work around?  The ugly option
is to re-write the Jikes task to split up the file list and arguments into
multiple commands so this limit doesn't get hit.  My less ugly option is to
switch to JDK 1.3's new "fast" compiler but is not really what I want to do.

Thanks
Mike McCune