You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Both DateHelper classes will need to be available to the user. The problem is the current workspace setup is based on a 1-to-1 relation of .class files to actual resource classes. So depending on the ZIP entry iteration order, only one will be chosen.
Some ideas for addressing this:
Attach a Collection<ClassInfo> to resource class entries, which also get updated when the base is updated.
This can occur in jars that have version-specific implementations.
Consider multi-release jars:
Both
DateHelper
classes will need to be available to the user. The problem is the current workspace setup is based on a 1-to-1 relation of.class
files to actual resource classes. So depending on the ZIP entry iteration order, only one will be chosen.Some ideas for addressing this:
Attach a
Collection<ClassInfo>
to resource class entries, which also get updated when the base is updated.On load detect duplicates and let users choose which they want to keep
Rework the resource entries so instead of
ItemInfo
it will haveItemFamily
ItemInfo
values, such as multi-versioned classesThings to consider about any one fix:
The text was updated successfully, but these errors were encountered: