I've definitely had the same issues. Are you fixing where I have source and dependency specified that is really the source. I don't want my source wiped out if it is the same thing. I think you are.
sandeep -----Original Message----- From: Kristopher Brown [mailto:[EMAIL PROTECTED] Sent: Thursday, April 29, 2004 11:59 AM To: [EMAIL PROTECTED] Subject: Eclipse Plugin Ideas 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
