Please do not have plugin run if it project type is "pom"
Closed this issue · 8 comments
If you do a
if (project.getType().equals("pom")) return;
on the execute, this means we can force the plugin to run on child projects. Otherwise we can only put it in pluginManagement and then its a "suggestion".
Sounds like a great pull request.
You really want a pull request for one line of code? I'm happy to do it :-)
@rvowles , @mp911de , I'm missing something about this. How did skipping non-existing folders in Pull #45 address not having the plugin run if project is of type "pom"?
I'm also missing this on a more superficial level: I don't get it, why do I want to make the change to the implementation of "execute" described in this issue to return for projects of type "pom"?
Skipping for type pom allows you to specify this plugin in instead of . We declare this project in our web project parent pom (which is just a pom), putting it in means it runs without needing to respecify it in the individual project. However, because it thinks it should always run, it tries to run in a pom only project which of course has nothing in it. Perhaps this is why the patch fixes it? If the folder does not exist, it skips it. For a pom only project, the folder will not exist.
Disabling it for pom projects could cause problems for someone who was using the assembly plugin to put stuff together.
e.g. We've got a project where we have a bunch of common javascript/css stuff that gets reused by different projects. Because it is all static content, we produce a zip file instead of a war/jar (and serve it straight from httpd). To do that we use the pom packaging type, and the assembly plugin.
I think a better solution for people wanting to avoid running this plugin for parent or non-web modules would be to use a maven profile activated on the existence of whatever folder they keep their sass files in. No change needed to this plugin, and it still lets people who want to run sass in a 'pom' module do so.
If this feature is introduced, then I think it should only skip for pom projects in the presence of a configuration flag.
You are however, using a pom precisely for what it is not intended to be used for (aka - a hack).
Is there a reason you don't simply use the Servlet 3 specification and put your resources in src/main/resources/META-INF/resources as defined by that? Its just a suggestion - thats exactly what we do with our common javascript/css stuff. It is how webjars.org is able to bundle stuff up and create dependencies for common js/etc libraries.
I'm happy however with a config flag. The logical thing however would be to do the reverse (process the pom) as that reflects that you are generating directly consumable artifacts in a project that is not expected to have any.
I don't think that would be any help if you don't want to create a jar.
Perhaps things have changed since I looked at it last, but my experience is
that if your main artifact is going to be a zip file, tarball, etc. then
you end up having to use the pom packaging to stop it creating an
unnecessary jar file, and the assembly plugin to create the zip file.
bits and peace
Nicholas Daley
On 20 September 2014 09:25, Richard Vowles notifications@github.com wrote:
You are however, using a pom precisely for what it is not intended to be
used for (aka - a hack).Is there a reason you don't simply use the Servlet 3 specification and put
your resources in src/main/resources/META-INF/resources as defined by that?
Its just a suggestion - thats exactly what we do with our common
javascript/css stuff. It is how webjars.org is able to bundle stuff up
and create dependencies for common js/etc libraries.I'm happy however with a config flag. The logical thing however would be
to do the reverse (process the pom) as that reflects that you are
generating directly consumable artifacts in a project that is not expected
to have any.—
Reply to this email directly or view it on GitHub
#38 (comment)
.
This version is no longer maintained. Refer to more recent forks at https://github.com/Jasig/sass-maven-plugin/network for more up to date versions.