[#MPECLIPSE-63] dont want the hardcoded org.eclipse.jdt.core.javabuilder

Maven 1.x Eclipse Plugin

dont want the hardcoded org.eclipse.jdt.core.javabuilder

Created: 03/Jan/05 07:22 PM Updated: 09/Oct/05 12:06 PM

Component/s:

None

Affects Version/s:

None

Fix Version/s:

1.10

Time Tracking:

Not Specified

Environment:

Description

« Hide

There are cases that we dont want this plugin to be added org.eclipse.jdt.core.javabuilder automatically.

The same for org.eclipse.jdt.core.javanature.

Docu plugin does not need java builder and nature

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

dion gillard added a comment - 03/Jan/05 08:48 PM

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?

[ Permlink | « Hide ]

Dan Tran added a comment - 03/Jan/05 10:04 PM

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

[ Permlink | « Hide ]

dion gillard added a comment - 03/Jan/05 10:07 PM

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

Eclipse will create the .project file for you automatically.

[ Permlink | « Hide ]

Dan Tran added a comment - 03/Jan/05 10:22 PM

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?

[ Permlink | « Hide ]

dion gillard added a comment - 03/Jan/05 11:08 PM

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?

[ Permlink | « Hide ]

Dan Tran added a comment - 04/Jan/05 01:35 AM

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.

[ Permlink | « Hide ]

Leo Fang added a comment - 08/Feb/05 07:40 PM

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.

[ Permlink | « Hide ]

fabrizio giustina added a comment - 11/Mar/05 05:46 AM

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.

[ Permlink | « Hide ]

Juraj Burian added a comment - 20/Jun/05 09:42 AM

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 ....

[ Permlink | « Hide ]

fabrizio giustina added a comment - 09/Oct/05 12:06 PM

fixed in svn for 1.10