Skip to content

Conversation

protoism
Copy link
Contributor

Modified AbstractModule.getShortName and AbstractModule.getGWtMaven2ModuleName to return an empty string
when Module is not stored in an IFile

I'm just curing the symptoms, as I'm not clear what the code should do.

But it's better than nothing...

Fixes #452

* GWT Maven project will have a short name
* @return the short name for module
*/
private String getShortName() {
Copy link
Contributor Author

@protoism protoism Feb 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method fails when the plugin is scanning classpath for manifest files in dependencies, which are in jar files.
Returning an empty string should be the right thing to do, as there's some maven related logic which makes sense only for manifests contained in the source, and not in dependencies

@protoism protoism requested a review from niloc132 February 22, 2023 09:54
Copy link
Member

@niloc132 niloc132 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From what I can tell, there are two AbstractModule subtypes:

  • ModuleFile, which always uses an IFile storage (the "correct" case according to the old code)
  • ModuleJarResource, which is always an IJarEntryResource storage (presumably the "wrong" one, since it is the only other case, and doesn't inherit from IFile).

Each of these respective AbstractModule types limits what type it takes in its constructor, so we can be certain that storage is always the expected type. In turn, each type knows what storage it has, so can avoid an instanceof check. In fact, I'd go so far as to say that the storage instanceof IFile check is actually a this instanceof ModuleFile check..

As such, I think a better fix than branching on the type of storage is to make these methods abstract, and correctly implement them in their subtypes. That is, ModuleJarResource will return "" for each of these, and ModuleFile will return the old logic.

Note that we could also use isBinary() as a "is it a file" check, since that is overridden by each type in this way, to return true/false.

To make things a bit more bulletproof along the way, AbstractModule could be made generic on <S extends IStorage>, and then each type could avoid a cast to read its own storage (there are comments, such as ModuleFile.getFile() that would go away, since this would become obvious)...

return moduleName;
}

private String getGWtMaven2ModuleName() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fix typo in this method name while you're changing this?

Suggested change
private String getGWtMaven2ModuleName() {
private String getGwtMaven2ModuleName() {

}

}
/*******************************************************************************
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note that you're changing line endings

Image image = null;

IModule module = (IModule) element;
if (module instanceof ModuleFile) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, while technically true, is this better? I think it might be, but wanted your opinion.

The first thing each block does is to cast it, so that might be right.

Comment on lines 450 to 455
@Override
protected Comparator<?> getItemsComparator() {
return (Object o1, Object o2) -> {
Collator collator = Collator.getInstance();
IModule module1 = (IModule) o1;
IModule module2 = (IModule) o2;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While you're at it, change this to specify the right type, so a cast isn't even needed?

Suggested change
@Override
protected Comparator<?> getItemsComparator() {
return (Object o1, Object o2) -> {
Collator collator = Collator.getInstance();
IModule module1 = (IModule) o1;
IModule module2 = (IModule) o2;
@Override
protected Comparator<IModule> getItemsComparator() {
return (Object module1, Object module2) -> {
Collator collator = Collator.getInstance();

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok!

protected AbstractModule(IStorage storage) {
assert (storage != null);
this.storage = storage;
protected AbstractModule() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldnt even be necessary, the class is already abstract and has no other ctors

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok

* @return module name
*/
private String getGwtMaven2ModuleName() {
IFile file = storage;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is silly to have, and the moduleName variable isnt needed either. Probably should just inline it (but the code is so much better I'd be okay with leaving it).

niloc132
niloc132 previously approved these changes Feb 23, 2023
Copy link
Member

@niloc132 niloc132 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved, a few thoughts, up to you if we address now or not.

@protoism protoism requested a review from niloc132 February 23, 2023 11:43
gwtModuleDtd = "<!DOCTYPE module PUBLIC \"-//Google Inc.//DTD Google Web Toolkit " + versionNum
+ "//EN\" \"http://google-web-toolkit.googlecode.com/svn/tags/" + versionNum
+ "/distro-source/core/src/gwt-module.dtd\">";
+ "//EN\" \"http://gwtproject.org/doctype/" + versionNum
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Defer this to a followup patch, since it isn't related to this other work?

@protoism protoism requested a review from niloc132 February 24, 2023 10:33
Copy link
Member

@niloc132 niloc132 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixes the bug (and possibly other latent bugs), cleans up the code, net decrease in code, great work!

@protoism protoism merged commit 317bf57 into gwt-plugins:main Feb 24, 2023
@protoism protoism deleted the features/fix_module_creation branch February 24, 2023 17:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Module creation is broken
2 participants