Yup, Importscrubber has problems with Strings that look vaguely like class
names. Actually, Marcus Dahm, the author of BCEL, had some suggestions on
differentiating String constants from class references - apparently I can
just check to see if the item I'm looking at is referenced from a
ConstantString.
So I'll try to take a look at that and see how that helps....
Thanks,
Tom Copeland
[EMAIL PROTECTED]
703-317-5193
Jon Stevens
<jon@latchkey To: "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]>
.com> cc: <[EMAIL PROTECTED]>
Subject: Re: ImportScrubberTask
10/22/2001
01:04 PM
on 10/22/01 6:22 AM, "Jason van Zyl" <[EMAIL PROTECTED]> wrote:
> It works fine, but there is a problem with the imports being placed in
the
> wrong place when there is text right after the package declaration. I
asked
> Tom Copeland to fix this for me and he said he would get to it today. It
> does the job correctly, it just doesn't put the imports in the right
place.
Run the ant target that I pasted here against Scarab and you will see that
it does NOT work fine at all. I pasted it here so that I wouldn't get a
response like you just gave me.
Here is an example of some imports it f*cked up:
[196][ src/org/tigris/scarab/om ]% more Attachment.java
package org.tigris.scarab.om;
import text.plain;
import org.apache.fulcrum.upload.FileItem;
import org.apache.torque.om.NumberKey;
import org.apache.torque.om.Persistent;
I never knew that text.plain is a proper import. :-)
Here is another one:
[197][ src/org/tigris/scarab/om ]% more IssueTemplateInfo.java
package org.tigris.scarab.om;
import email.RequireApproval.vm;
import org.apache.turbine.Turbine;
import org.apache.fulcrum.template.TemplateContext;
import org.apache.torque.om.NumberKey;
import org.apache.torque.om.UnsecurePersistent;
import org.tigris.scarab.security.ScarabSecurity;
import org.tigris.scarab.security.SecurityFactory;
import org.tigris.scarab.tools.Email;
import org.tigris.scarab.util.ScarabException;
import org.tigris.scarab.services.module.ModuleEntity;
Wow. When did Velocity files become ok to import? :-)
It appears that in its search through files, it finds any mention of a
"foo.bar" and sticks it into an import. That does not seem like a very good
assumption.
Another problem I noticed is that it imports java.util.Set when it doesn't
need to as well.
Yes, I compiled with debugging on.
I'm starting to think that post processing JAD (the java decompiler) output
would be a better idea.
-jon
--------------------------------------------------------------------------
This email may contain confidential and proprietary information which is
for the sole use of the intended recipient. If you received this email in
error, please notify the sender and delete this email from your computer.
Any review, distribution or retransmission of or reliance on this email by
anyone other than the intended recipient is forbidden.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
