Project

General

Profile

Bug #6082

automatically add to conversion list all non-skeleton .cls dependencies

Added by Constantin Asofiei over 4 years ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

Related issues

Related to Conversion Tools - Feature #5630: add missing classes referenced during parsing to the conversion list in file list mode Closed
Related to Conversion Tools - Feature #7169: drive conversion order using user-specified dependencies WIP
Related to Conversion Tools - Feature #7180: create a centralized manager for the conversion list and per-file/project status and logging Closed
Related to Conversion Tools - Feature #8849: Automatic dependencies conversion New
Related to Conversion Tools - Bug #7255: FWD resolves a OO file not included in conversion, if it exists on disk and on PROPATH Test

History

#1 Updated by Constantin Asofiei over 4 years ago

During conversion, if a .cls or a .p has dependencies to non-skeleton classes which are not included in the initial conversion list, the conversion will fail at some point in the annotations or main conversion phase.

The parsing phase can be improved to recursively include all .cls files (loaded during parsing phase and which are not part of the conversion list), until no more new .cls files are loaded.

#2 Updated by Greg Shah over 4 years ago

  • Related to Feature #5630: add missing classes referenced during parsing to the conversion list in file list mode added

#3 Updated by Greg Shah over 4 years ago

This may be a duplicate of #5630.

#4 Updated by Constantin Asofiei about 4 years ago

In #6351-10 Greg Shah wrote:

Sub-classes should be re-converted every time a parent class is converted.

This is a real issue, as the converted Java method name in sub-classes must match the one in the parent class.

Of course, on each step this will require to go back and check for all references/sub-classes/etc until none are left.

#6 Updated by Constantin Asofiei about 3 years ago

Greg, the changes which helped me get through the 62k files for #7199 are in 6082a rev 14553 (created from trunk rev 14552). I don't really like the approach (and SymbolResolver.parseHierarchy may lose .cls dependencies), but I just wanted to archive these changes, so they do not get lost. It also breaks (again) concurrent conversion or parsing.

#7 Updated by Greg Shah about 3 years ago

  • Related to Feature #7169: drive conversion order using user-specified dependencies added

#8 Updated by Greg Shah about 3 years ago

  • Related to Feature #7180: create a centralized manager for the conversion list and per-file/project status and logging added

#9 Updated by Greg Shah about 3 years ago

I've looked at the changes. Yes, you are right that they are not something we could pull into trunk as is. I had similar code to this and had to remove it because it did not result in the correct list. I went in favor of the current wa.processed approach used during pre-scan which was also nasty but I did get it working reliably.

This area really needs to be reworked with #7169 and #7180.

#10 Updated by Greg Shah about 2 years ago

  • Related to Feature #8849: Automatic dependencies conversion added

#11 Updated by Greg Shah over 1 year ago

  • Related to Bug #7255: FWD resolves a OO file not included in conversion, if it exists on disk and on PROPATH added

#12 Updated by Greg Shah about 1 year ago

Does trunk rev 15852 (changes from #7255) resolve this task?

#13 Updated by Eduard Soltan about 1 year ago

Greg Shah wrote:

Does trunk rev 15852 (changes from #7255) resolve this task?

If the scope of this task is strictly related to the scenario described in #6082-1 note, then indeed trunk rev. 15852 will resolve this task.

#14 Updated by Greg Shah about 1 year ago

What other related features are still not complete? The intention here is to resolve the problem that explciitly or implicitly referenced classes should be added to the conversion list in any case where we would depend upon them being there.

#15 Updated by Eduard Soltan about 1 year ago

Greg Shah wrote:

What other related features are still not complete? The intention here is to resolve the problem that explciitly or implicitly referenced classes should be added to the conversion list in any case where we would depend upon them being there.

Got it, then this case is handled.

#16 Updated by Greg Shah about 1 year ago

  • Status changed from New to Closed

#17 Updated by Greg Shah about 1 year ago

  • % Done changed from 0 to 100

Also available in: Atom PDF