Patch attached.

The patch is somewhat polluted with reformats, but I'll take a look.

Uh... OK, perhaps I used an incorrect code style in the IDE.
Sorry about that; however, the patch is rather small [essentially a single if statement + an IT], so I hope it should be decently simple to reformat and commit.

Fixed in r17320

Is this really what we want? I think for the majority it does matter that the sourceDirectory exists, why would you otherwise create a schema? Now it silently ignores it and there's no way to let it fail anymore. How about a property failOnMissingSources (default true)?

One possible scenario is that there are more than one source directory defined and one of them doesn't exist (like the IT mjaxb-71 depicts). I'm kind of thinking this is a workaround for bad Maven project configuration or a bug in some other plugin.

What we possibly could do is verify that at least one source directory exists.

Maven promotes creating a commonly used build definition (such as AspectJ + JAXB2 to
weave and create XSD for entity class definition projects) in a parent pom.

The Maven person in me has to object here. Maven does not encourage this type of solutions IMHO and this is what I meant by "bad Maven project configuration".

Still, I think that this improvement to the plugin doesn't do any harm. At least if we check that there is at least one valid source directory (or rather, there is at least one source file, which I think there is check for already).

If a module shouldn't use AspectJ or Jaxb, the parent should define the plugins in the pluginManagement and specify it as plugin in the modules requiring it.
You could also question if these other plugins should have added these source-directories. Maybe it should be fixed there instead of making the jaxb2-m-p super defensive (like Anders suggests too).
IMO it's better to focus on the smaller/simpler projects for the defaults and give enough control on more complex projects to work around issues like this.

I'm struggling here. I think that any plugin adding a non-existing source directory is just plain bad and should be banned. But, on the other hand, I don't see any harm with the check here. If schemagen would have quietly ignored any specified non-existing source dir I think we wouldn't argue about if that was a wrong behavior.

The logging about ignoring a non-existing source dir is currently at info level (not warn as the patch). I changed that to comply with how the m-resources-p logs non-existing resource directory. We could bump that to warn if it would make it more clear to the user (but most users just ignores warnings anyways as long as the build passed, in my experience).

The scenario is more complex than that, Robert.
I believe that the majority of cases would mind that at least one - but not all - sourceDirectories exist.

Let me exemplify: Some plugins - such as the AspectJ Maven Plugin - add sourceDirectories to the project they are provided in.
In the case of the AspectJ plugin, src/main/aspect and src/test/aspect are added as sourceDirectories by default.
Maven promotes creating a commonly used build definition (such as AspectJ weaving many projects in a multimodule build and jaxb2 to
create schema for entity class definitions) in a parent pom.

So ... a parent pom with AspectJ and JAXB2 plugin definitions will always fail the build due to the implementation of the JAXB2 plugin
and the fact that a parent pom project frequently will not contain a src/main/aspect directory and src/test/aspect. Heck, even all
child projects might not contain these directories - and we should really avoid forcing developers to check in dummy files to ensure
that the src/main/aspect directory exists for all projects which are children to our example parent.
This is simply poor operation of the JAXB2 plugin.

While both the attached patch and your idea about a property failOnMissingSources could handle the scenario above, I would argue
that the default value should be false - so that the example above should work without having to provide extra configuration to
the JAXB2 plugin. We should use sensible default values to promote the spirit of maven's usage.

The scenario is more complex than that, Robert.
I agree with Anders; I believe that the majority of cases would mind that at least one sourceDirectories exist.

Example: Some plugins - such as the AspectJ Maven Plugin - add sourceDirectories to the project they are provided in,
and all project children. In the case of the AspectJ plugin, src/main/aspect and src/test/aspect are added as
sourceDirectories by default. Maven promotes creating a commonly used build definition (such as AspectJ + JAXB2 to
weave and create XSD for entity class definition projects) in a parent pom.

However, our example parent pom will always fail the build if it does not contain directories src/main/aspect and src/test/aspect.
Heck, even all child projects might not contain these directories - and we should really avoid forcing developers to check
in dummy files to ensure that the src/main/aspect directory exists for all child projects to our example parent.
This is simply poor operation of the JAXB2 plugin.

While both the attached patch and your idea about a property failOnMissingSources could handle the scenario above, I would argue
that the default value for the property should be false - so that the example above should work without having to provide extra
configuration to the JAXB2 plugin. We should use sensible default values to promote the spirit of maven's usage.

<at> Anders, I'm glad you picked up this issue
Here are some other cases:

• There must be a way to keep the plugin strict. Maven is all about stable builds, don't force developers to gamble with the existence of directories or not.
• Newbies should have the plugin up and running asap. What would happen, if the wrong source-directories were added, due to typos in the configuration? Would the build succeed?
• Experienced users should now how to finetune the plugin.
  So I still think we need an extra parameter, the default behavior is up to you.

I still think you are oversimplifying the problem. I took the AspectJ example to highlight
generic cross-cutting behaviour which all projects in a multimodule build should use,
such as weaving custom-defined aspects into bytecode classes.

This implies that the AspectJ plugin must be defined within a parent and that it may or may
not be executed in any project in the reactor, depending on regexp matching for one of the
Pointcuts. Such matching can be nontrivial, so it could be difficult or highly impractical
for a developer to figure out if the aspectj plugin should be enabled for a particular leaf
project. Hence the practicality of actually inserting the plugin in the stereotype parent.

Also ... Given a fairly big reactor of some 400 maven projects, where some [around 60]
contain JAXB-annotated entities I certainly would not want to delegate the <plugin ...>
definition to all the leaf projects. What a nightmare to maintain, not to mention the added
and completely unnecessary complexity! In those cases, it seems much more efficient to
define the full build cycle (for a stereotype of project) in its parent pom, rather than
have 60 projects with extra plugin definitions in their poms. Reducing complexity and
not repeating yourself should constitute good maven configuration.

Having said that, I agree that I consider a plugin adding nonexistent sourceDirectories flawed or buggy.
I have placed an issue on the AspectJ maven plugin - but in the meantime I suggest that the JAXB2
plugin should check sanity.

After doing some thinking, this is my call on this ticket:
We keep the implemented behavior where non-existing source folders are ignored with an INFO log statement. I've studied how the m-resources-p handles non-exisiting resources folders (actually how maven-filtering does this) and it is the same behavior. I simply don't think misconfiguration etc is a problem. If they have something misconfigured, the should see the log output or their tests should catch this.
Adding an extra config parameter for this is not a good idea I think, we don't need more parameters and more options.

Should this turn out to be a bad call, we could always change it in the future. If it is a problem people will file tickets. However, as the m-resources-p has a similar behavior I don't think this will be a problem.