Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement support for WebJars and LESS as assets pipeline #132

Closed
wants to merge 1 commit into from

Conversation

fushar
Copy link
Contributor

@fushar fushar commented Mar 13, 2020

@JLLeitschuh
Copy link
Contributor

This is an impressive bit of work. Thanks for your contribution!

@JLLeitschuh
Copy link
Contributor

Looks like the docs test are failing, which is abnormal as they aren't failing on master. Could you take a look and let me know why?

@fushar
Copy link
Contributor Author

fushar commented Jun 16, 2020

@JLLeitschuh Oops. I forgot to add declare the new less plugin in a build.gradle in docs. I've pushed the fix. Here is the diff: https://github.com/gradle/playframework/compare/ecb94d550f6c50a8cfe39c4aa9761efc46092e85..cba5cb53f80b3c4a01b81268a38e03fb637c02f9

But now somehow it does not trigger Travis build now 😅 what is going on?

@fushar
Copy link
Contributor Author

fushar commented Jun 17, 2020

@JLLeitschuh the CI test has run now. Doc test is green :)

@JLLeitschuh
Copy link
Contributor

Before merging this, I'd like to see master fixed. See #136

@fushar
Copy link
Contributor Author

fushar commented Sep 27, 2020

@JLLeitschuh I've rebased to latest master, now everything is green, could you take a look again?

Copy link
Contributor

@JLLeitschuh JLLeitschuh left a comment

Choose a reason for hiding this comment

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

Looks good so far! A few changes I'd appreciate. I'm trying to get someone else to take a look as well.

project.getTasks().named(PLAY_RUN_TASK_NAME, PlayRun.class, task -> {
task.getAssetsDirs().from(webJarsExtractTaskProvider.get().getOutputDirectory());
});
project.getTasks().matching(task -> task.getName().equals(LESS_COMPILE_TASK_NAME)).forEach(task -> {
Copy link
Contributor

Choose a reason for hiding this comment

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

This forces the realization of all tasks. Can you use a type constraint instead of a name constraint?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, just realized this. Changed this to:

Optional.ofNullable(project.getTasks().findByName(LESS_COMPILE_TASK_NAME)).ifPresent(task -> {

Can't find any method which accepts type constraint but does not fail if the task is not found :(

Copy link
Contributor

Choose a reason for hiding this comment

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

Asking internally about this. I think that findByName is still forcing some task configuration & realization?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

To be honest, I'm not really sure about this. The thing is I cannot use .named() because it will throw if the less plugin is not applied. Most of the methods I found is doing the similar thing (throwing when task is not found).

Could you advise the correct method? I could not find anything by browsing the Task javadoc / documentation :(

Copy link
Contributor

Choose a reason for hiding this comment

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

After asking internally, the answer I got was tasks.matching { ... }.configureEach { ... } This may be what you already had (sorry). But supposedly, this is what you want to use here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see. No worries, I added it back!

@fushar
Copy link
Contributor Author

fushar commented Oct 13, 2020

@JLLeitschuh Thanks for reviewing; I have addressed/answered all your comments.

* }
* </pre>
*/
public interface LessSourceSet {
Copy link
Contributor

Choose a reason for hiding this comment

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

Out of curiosity, does this become accessible via the Kotlin DSL as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Honestly I am not using Kotlin DSL so I cannot verify. But I believe it should because it follows exactly the same pattern as the other source sets in the existing codebase.

return lessCompilerClasspath;
}

public List<File> getIncludePaths() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this an input or an output?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, interesting, this could be @InputFiles. Added!

return outputDirectory;
}

@Classpath
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this infer an input/output or does it need to be explicit?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually I was just following existing JavaScriptMinify task here: https://github.com/gradle/playframework/blob/master/src/main/java/org/gradle/playframework/tasks/JavaScriptMinify.java#L67

But it seems that according to the docs here: https://docs.gradle.org/current/userguide/more_about_tasks.html I should also add @InputFiles to be compatible with some older Gradle versions, which I do not actually use. Should I still add it?

Copy link
Contributor

@JLLeitschuh JLLeitschuh left a comment

Choose a reason for hiding this comment

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

I know I continue to be nitpicky. This is just a large change. This should hopefully be the last review pass I need to take on this.

@JLLeitschuh
Copy link
Contributor

@fushar are you willing to own this change a bit after it is merged and help manage issues/bugs that are associated with it moving forward?

@fushar
Copy link
Contributor Author

fushar commented Oct 15, 2020

@fushar are you willing to own this change a bit after it is merged and help manage issues/bugs that are associated with it moving forward?

Sure, I am still maintaining a project which heavily relies on these plugins, so I should be able to help on that.

@JLLeitschuh
Copy link
Contributor

Thanks @fushar! We just did a release, we're going to try to get this into the next one, hopefully later today, or tomorrow.

@fushar fushar force-pushed the assets-less-webjars branch 5 times, most recently from 00b3a64 to 2b905a2 Compare October 17, 2020 03:02
@JLLeitschuh
Copy link
Contributor

Hey @fushar,

Really sorry. I went on vacation the past two weeks and thought that someone would follow up here.

I had a discussion with @big-guy about this. We were wondering why the webjar component needed to be a part of this plugin and couldn't be a wholly-separate community maintained plugin? It doesn't seem like it's play specific.

@fushar
Copy link
Contributor Author

fushar commented Nov 12, 2020

Hi @JLLeitschuh sorry for late reply; was busy with work.

I was just trying to get feature parity with the original SBT plugin counterpart. As per the original docs, WebJars is a built-in feature, thus this PR.

I actually had tried writing 2 separate plugins for WebJars and LESS, based on the deprecated Gradle Software Model. However, the LESS plugins actually depends on WebJars output. That's also another reason why I put those two together in the same codebase.

What do you think? Should I still somehow separate those two?

@JLLeitschuh
Copy link
Contributor

@fushar I think that your rationale for why you're including it makes sense. Let me take another pass quickly.

Copy link
Contributor

@JLLeitschuh JLLeitschuh left a comment

Choose a reason for hiding this comment

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

I understand @big-guy's hesitation to add the web jar functionality to this plugin, but I think that it's a worthy addition. I'm giving this my LGTM approval.

I'm meeting with @big-guy later today, I'll make sure I run this by him one last time during that meeting

@fushar
Copy link
Contributor Author

fushar commented Nov 19, 2020

Thanks @JLLeitschuh, appreciate it 😄

Comment on lines +75 to +79
project.getTasks().matching(task -> task.getName().equals(LESS_COMPILE_TASK_NAME)).configureEach(task -> {
LessCompile lessCompileTask = (LessCompile) task;
lessCompileTask.dependsOn(webJarsExtractTaskProvider);
lessCompileTask.getIncludePaths().add(webJarsExtractTaskProvider.get().getOutputDirectory().get().getAsFile());
});
Copy link
Contributor

Choose a reason for hiding this comment

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

Instead of doing this, can you use named inside of a check to make sure that the less compile plugin is applied?

@JLLeitschuh
Copy link
Contributor

Hey @fushar,

So, after a long conversation with @big-guy we decided that we unfortunately don't want to include these plugins to this repo. However, we are more than willing to add tests to this repository to verify that an external plugin stays compatible with a plugin that adds this functionality and would be happy to link to an external plugin from our documentation.

As a part of this, this will give you the freedom to use some of the newer APIs and will keep that external plugin from being constrained to the same Gradle version support as this one.

Of note, some of the patterns and paradigms you mimicked from other code in this plugin was a carryover from the original port and extraction of this code from Gradle/Gradle. That extraction maintained some of the less-than-optimal patterns of the Gradle Software Model that is now deprecated. As a standalone plugin you can more easily adopt some of the newer provider based APIs that automatically track task dependencies without requiring the use of dependsOn.

We want to thank you for your contribution, and we hope you will contribute more to this plugin in the future.

@fushar
Copy link
Contributor Author

fushar commented Nov 20, 2020

Hi @JLLeitschuh & @big-guy,

Ah... I see. Understandable. Though most probably I don't really have the bandwidth in the near future to pick this up (make separate plugins, re-testing, rewriting the docs changes etc). So for now I'll close this PR and live with my own fork for the time being. Hopefully i can revisit this some time next year.

Thanks for your time reviewing this PR! 🙂

@fushar fushar closed this Nov 20, 2020
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.

3 participants