Do you have a use case for this?

The usual reason for using this plugin is to put the java dependencies onto the eclipse Build Path for a java project.

If you are using it for something else - what is it?

My company has a eclipse documention project plugin which has
nojava source. but maven.ecplise.plugin generates java builder,
in .project and eclipse fails to load the project

So why are you running the eclipse plugin against a documentation project?

Eclipse will create the .project file for you automatically.

Our developers create eclipse plugins, I just mavenize them.
For my case, they create a eclipse plugin with no java source for
documentation purpose.

I use maven-eclipse-plugin to generate all .classpath and .project
files for all eclipse plugins.

Do you suggest not using maven to generate the .project
only for that particular use case?

If the .project exists already, and it's a non-java project, I don't see the point in running the eclipse plugin. Can you clear me up on that?

I thought we want to use maven's POM to generate elipse's project file. This way we do not have maintain 2 different files.

But I can see the impact on existing application which heavily depend on current behavior. This fix can break lots of existing maven projects.

For now, I will override eclipse:genetate_project goal to either
ignored and keep the existing .project, or remove the unneeded java buidler and nature after .project is generated

Perhaps,we should document this unsupported use case. I am sure
someone will hit this scenario again since it it not uncommon to
have an eclipse plugin without source and it is natural to use
this plugin the generate all plugins in one shot using multiproject:goal without worrying about the unsupported case.

How about use case of an ear project. It also don't have src folder, and would like to remove the default java builder and nature.

Patch is attached to MPECLIPSE-80
the javanature is not added if no source file is found, just like for the java builder.
This is pretty common in multiproject parents, which usually only contains documentation.

Please folks is there chance fix this problem or not?
I see lot of reason to have javanature and javabuilder included optional.
Namely, for example javabuilder is not necessary when project is compiled by another builder.
Next, we have problems with the order in natures and buildSpec blocks in RAD.

So I am thing that best way is add property like : maven.eclipse.defaultbuilder
and do modification of project.jelly file like this:

<j:set var="addDefaultBuilder" value="${maven.eclipse.defaultbuilder}"/>
<j:if test="${addDefaultBuilder != 'false'}">
<buildCommand>
<name>org.eclipse.jdt.core.javabuilder</name>
<arguments>
</arguments>
</buildCommand>
</j:if>

Similar convention should be ok. for javanature ....

fixed in svn for 1.10