It seems to me that the <rmic> task will not generate the files into another folder. <rmic base="${classes.rmi.dir} includes="**/*.class" classpath="${classes.dir}" /> when <rmic base="${classes.dir} includes="**/*.class" classpath="${classes.dir}" /> works perfectly. defining sourcebase doesn't seem to help either.
I'm not sure I'm following you here. rmic will generate .class or .idl files (what kind of files depends on the Java version and some attributes) and put them at the same place the .class file you are "rmicing". base says where <rmic> is going to find the .class files "to rmic". rmic has the optional ability to generate .java files as well, those will be placed into the directory specified by sourcebase. IIUC you want the generated .class or .idl files to end up in a different directory than the .class files they have been generated from, correct? If so, let's degrade it to an enhancement request 8-)
"and put them at the same place the .class file you are "rmicing" " the question then becomes: is it possible to generate the "rmicing" files into another folder?
You run rmic on a .class file that has been compiled by javac and written by you, you have the full control over its placement. Please help me to see what I'm missing.
I'm completely for this. I believe what we're looking for is a way to utilize rmic "-d <directory> argument, e.g. "rmic -d /bin/stubs Class1" etc... I found the problem after looking at the verbose output from ant. It already uses "-d", passing it the "base" argument as the value. That could be o.k., as long as I could specify an absolute path to the "includes" argument - but this is hardwired to only search underneath "base" as far as I can tell. My current workaround is to find any **/*_Stub.class files after rmic runs, and move them to the desired folder. NOT PRETTY, but it's the best I can come up with at the moment. I'm also not liking how the classpath is always sent to rmic on the command line - I'd like to be able to specify the entire path myself (or not at all) without ant appending the entire existing classpath to it. I'm thinking about writing my own rmic task implementation at the moment... :-)
I started digging into the source code for the RMIC task. I'd like to write a patch for this. We need to split things up so that the "base" property (baseDir instance variable) is not used for both the directory scanner, and for the "-d" argument within setupRmicCommand(String[]) in DefaultRmicAdapter. We should use a new property to do this properly. "base" is already clearly defined as "the location to store the compiled files". I'm thinking a property like "sourcebase" which would be used for the directory scanner, and would default to "base". Yes, "sourcebase" is already taken, though awkwardly- named. Maybe "includesBase"? Please let me know if something like this is something that would be considered for acceptance as a patch into the main version, or if I should just continue creating my own implementation...
Created attachment 16086 [details] Proposed patch to fix bug 20699. Adds "includesBase" field to allow for "base" to be used exclusively for the destination directory, as it is currently. "includesBase" will be used to provide the parent for any includes, includesFile, excludes, etc. arguments.
WFM without any problems. My build does output RMI stabs into a different folder.
... sorry. Actually I do not, the build script is copying **/*_Stub.class files after <rmic>.
That is also my ugly workaround for the moment. I don't like it, because rmic already provides the option to do this for us. (And as stated in comment #4, the current implementation even prevents us from using it.) Granted, this hopefully will never be a concern, but what if someone wrote a class called *_Stub.class that wasn't even a stub or generated by rmic? Unlikely, but always plan for the worst-case scenarios... To me, this seems like rather important functionality that's missing from RMIC, b/c the stubs are generated from the server for use on the client. Good code organization should probably have the interfaces, server, and client in 3 separate source trees. Alexey, is there any chance at getting this committed into at least HEAD, sooner than later? I’d really like to include this functionality into my build scripts, but it will cause problems for others using the code base. I’d rather have them use something directly from Ant, rather than everyone having to manually patch. Thanks!!
I would prefer an inner <fileset> approach.
... and "destdir" attribute
I completely agree, though I was working carefully to maintain 100% backwards compatibility... However, I really like “destDir” (can we capitalize the d?) – it’s much less ambiguous than “base”. The benefits of the FileSet are undisputed… How about requiring EITHER “base” OR (“destDir” and a <FileSet/>) ? This should maintain compatibility, and provide the additional functionality – is this what you were thinking? With my “includesBase” idea, I automatically added it to the classpath, as I understand it to be a requirement for the given use case. Should I do this with the FileSet as well? If you think that we could get this into HEAD in the next week or two, I’ll make the changes tonight! (Off-topic, but has anyone had any luck loading the ANT source into Eclipse as a project?) Thanks for your quick responses. With over 700+ open bugs on the project, I was worried if this would ever get any attention. Shame on me for doubting! :- )
"destdir" is everywhere in lower case.
Created attachment 16129 [details] Proposed patch to fix bug 20699, #2. Update to my previous patch. Complete list of changes: - Added "destDir" attribute and support for inner FileSet. - Added "sourcesOnClasspath" attribute to automatically include any source folders on the classpath. - Updated detection to see if _Skel.class files were created or not, as by default they are no longer created in JDK1.5. (This included additional functionality in JavaEnvUtils for future reusability, I hope.) - Fixed the compileList so that is is cleared at the beginning of execute(), not at the end, to fix bug #21089, and maybe #24359. - Updates to the Rmic.html manual page. - Everything should be 100% backwards compatible; I did a fair amount of testing with various scenarios, but any further checking would be appreciated. Note: The existing source files had the Rmic.html in Unix format, and all the other files in PC format, which can be seen in the diff. I'm not sure how it's going to upload as such into Bugzilla...
>- Updated detection to see if _Skel.class files were created or not, as by >default they are no longer created in JDK1.5. (This included additional >functionality in JavaEnvUtils for future reusability, I hope.) You need to be working with CVS_HEAD rmic. This changed the default to explicitly ask for _Skel files, and should have the JavaEnvUtils stuff to detect java1.5 already.
Will re-prepare once more. I looked at CVS_HEAD, and EnvUtils was unchanged. It already had 1.5 detection - I didn't add that - but there was no good way to test for less than /greater than. (The 1.5 check would fail for 1.6 (Mustang) for example.) I also want to check that JRMC 1.1 is still the default for JDK's <1.5 - I didn't see this to be in the head code at first glance, will look into it. Also, after reviewing your comments on bug #33862, I can get the "rmi 1.3" idea taken care of. Any ideas better than Float parsing to deal with the version #'s the user passes in? Thanks for reviewing this!
Do we really want to be explicitly creating the skeleton files, overriding the preference of the JDK, and forcing the user to add the "-v1.2" attribute otherwise? (Then if/when 1.3 does come out, the Ant buildfile will be responsible for downgrading to the 1.2 version, possibly against the user's preference.) Just let me know if I'm concerning myself with things I shouldn't be concerned with....
We stay with the original defaults for rmic for the same reason we dont enable the java1.5 language options on javac in Jaa1.5 - minimising the risk of shared build files breaking. If you write a project on java1.4, publish it and someone running java1.5 downloads and tries to rebuild your app, you dont want to end up fielding support calls saying "enum is now a reserved word" or "rmic doesnt generate stubs". you want to know that your build file works consistently across platforms, and that is what we deliver. Sun appear to have different goals, or a different view of the world; one of little self-contained projects where the developer/dev team can all move up to a new java version simultaneously. They also still think people build using the command line tools, not via IDE or ant/maven. Accordingly, sometimes they change things that they think are "best" for their imagined customer. We, with a focus more on consistency and backwards compability, have to change them back.
Created attachment 16183 [details] Proposed patch to fix bug 20699, #3. Update to my previous patch. Complete list of changes: - (NEW) Patched against snapshot of CVS HEAD (ant_20050823101201). - Added "destDir" attribute and support for inner FileSet. - Added "sourcesOnClasspath" attribute to automatically include any source folders on the classpath. - Fixed the compileList so that is is cleared at the beginning of execute(), not at the end, to fix bug #21089, and maybe #24359. - Updates to the Rmic.html manual page. - Everything should be 100% backwards compatible; I did a fair amount of testing with various scenarios, but any further checking would be appreciated.
svn revision 805320 contains the destdir part of the patch, which was the original request, hence closing it as fixed. I'll look into the other parts but won't commit on applying them (the fileset part would be a resource collection by now and may turn out to be a little too much work). The sourcesOnClasspath part contains too much magic for me.
I've opened a new enhancement request (bug #47702) for the resource collection stuff, all other parts of the patch should be in trunk by now.