Hi,
I feel the eclipse plugin doesn't do what we need it to do. A few of
the issues are:
1) .project file has entries for the eclipse checkstyle plugin, and
these get wiped out on regeneration.
2) .classpath file is able to generate workspace local dependencies,
however this is indicated in the pom rather than a manner that is
independent to the developers environment. This causes problems when
working with only a few projects as it generates local dependencies
which are not available [unless you go and remove them for the pom].
3) additional classpath entries (added via the
maven.eclipse.classpath.include) in the .classpath file are only added
if there is a test source tree present.
So, I've tried to come up with some solutions, and I'd like to hear
people's thoughts on them.
1) Add something to the project.properties to specify the additional
buildCommands and natures that are used by the project. Seems fairly
simple for eclipse checkstyle plugin. Are there other
modifications/structure in .project to consider?
2) Remove the concept of eclipse.dependency in the properties for the
dependency. Whether or not its an local workspace dependancy should be
dependent on your eclipse workspace, not the pom. I've written a local
change at work where the plugin detects what projects are open in
eclipse and makes those into local dependencies only. The only thing
you have to supply is the eclipse workspace directory (in the
~/build.properties file normally) so it can detect against it, and
optionally a value in the project.properties to indicate that you want
to have local dependancies. We have found this useful, would this be a
better approach for the eclipse plugin?
There are hybrid solutions for this too, perhaps keep the
eclipse.depenency in the pom, but if the workspace directory is
supplied, a dependency could be double checked and if not available the
"true" could be overridden and it would then use the jar in the
repository.
3) I'm not really sure why this is the case, I'm presuming that we all
work in a test-driven development environment and it would be sacrilige
to not have a java/test/* directory :).
${maven.eclipse.classpath.include} is only considered if the test source
is present:
<j:if test="${unitTestSourcesPresent}">
...
<u:tokenize var="maven.eclipse.classpath.include.split"
delim=",">${maven.eclipse.classpath.include}</u:tokenize>
<!-- add extra directories to be included in the classpath -->
<j:forEach var="res"
items="${maven.eclipse.classpath.include.split}">
<classpathentry kind="src" path="${res}"/>
</j:forEach>
...
</j:if>
Is there any good reason why this cannot just be moved outside the
enclosing j:if? It seems that the current logic implies that if you
have a test directory then you can have additional includes for the
classpath.
So, if people feel the above are reasonable and useful, I'll actually
submit the patches to achieve it. Let me know your thoughts.
Regards,
Kris.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
