For a bit more context, Fabrizio has sent me a patch for all these
issues. I'll get it put into JIRA and apply it after reviewing. If there
is anyone more familiar with the m1 eclipse plugin that would like to
volunteer and can actually test it effectively, that'd be grand :)
Cheers,
Brett
Fabrizio Giustina wrote:
>FYI
>
>---------- Forwarded message ----------
>From: Fabrizio Giustina <[EMAIL PROTECTED]>
>Date: Sep 11, 2005 11:47 AM
>Subject: Re: [M1] Commit support for WTP in Eclipse plug-in
>To: Brett Porter <[EMAIL PROTECTED]>
>
>
>this is an aggregate diff for a bunch of eclipse plugin issues. There
>is a txt attached with the list of solved issues and also a list of
>items which IMHO should be closed as invalid, duplicate, or won't fix.
>All the changes have unit tests and documentation has been updated.
>The total number of issues which should be closed in jira after this
>is 19.
>
>There are still some issues left which I would like to work at, but
>first I would like to start seeing something committed, before wasting
>my time and ending up in a totally changed plugin... an aggregate diff
>should be easy to commit for you also if, I know, it's not ideal to
>have many changes in the same commit.
>I actually focused on solving old issues reported by users, adding
>webtool support, and starting making the m1 and m2 plugin converging
>(make the M1 plugin use the same path for source attachment as the M2
>one, now that maven 2 has a standardized artifact name for sources). I
>will investigate in extracting bits from the m2 plugin when issues are
>mostly solved...
>
>Let me know what you think
>
>fabrizio
>
>
>==== MPECLIPSE_fixes.txt ====
>
>fixed:
>MPECLIPSE-96 classpathentry contains trailing pipe character that
>confuses Eclipse 3.1
>MPECLIPSE-80 Generate .wtpmodules files
>MPECLIPSE-78 avoid duplicated builders/natures
>MPECLIPSE-63 dont want the hardcoded org.eclipse.jdt.core.javabuilder
>MPECLIPSE-92 Setting relative path value to "maven.eclipse.output.dir"
>generates wrong absolute classpath entry
>MPECLIPSE-72 Failing use cases for projects with just resources
>
>
>duplicate:
>MPECLIPSE-81 Resources are added as path even if they do not exist in
>the filesystem
> -> see MPECLIPSE-72
>MPECLIPSE-74 javanature / javabuilder for every kind of project
> -> see MPECLIPSE-63 (different solution, java nature is
>not added if there are no source/resource folders)
>
>
>already fixed in svn:
>MPECLIPSE-87 syntax problem using classpath exclusions with Eclipse 3.0
>MPECLIPSE-90 Backslash in generated .classpath
>
>
>mark as invalid:
>MPECLIPSE-97 (refers to the Mevenide eclipse plugin)
>MPECLIPSE-95 (refers to the Mevenide eclipse plugin)
>MPECLIPSE-98 Default locations not formatted correctly out of the box
> the issue report states that the plugin is generating
>entries starting with "file://" somewhere,
> but that's absolutely not the case, at least for the
>current version. Maybe another Mevenide issue?
>
>
>won't fix:
>MPECLIPSE-57 Make sourcepath more flexible
> Related to the change explained in changes.xml:
> Java source location now defaults to
>MAVEN_REPO${groupId}/java-sources/${artifactId}-${version}-sources.jar
> (standard location where source artifacts are deployed by
>the m2 source plugin in a legacy/m1 repository layout).
> The path
>${groupId}/src/${artifactId}-${version}.${maven.eclipse.src.extension}
>is still supported for backward
> compatibility and it will be used only if a file already
>exists at that location.
> Since now there is well defined standard it doesn't make
>sense to make the artifact name and location configurable.
>MPECLIPSE-89 ignore non-existing projects referenced by
>eclipse.dependency property
> Referenced projects could be located in a different
>directory: projects in the same eclipse workspace are in the
> workspace directory by default, but you are free to link
>projects in different locations.
> DUe to this reason, there is no way to check for the
>existence of a dependant project in the eclipse workspace.
>MPECLIPSE-85 Support for "lib" classpathentry
> jar files not in the maven repository should anyway be
>added to project.xml using the standard maven jar override system.
> The project should mantain the same set of dependencies
>both when built using maven than Eclipse, why you should need a
> dependency only when the project is built using eclipse
>MPECLIPSE-73 User Library type dependecy
> A user library can be added as a "con" classpath entry,
>already supported by the plugin. See also MPECLIPSE-85 for
> some considerations about "eclipse only" dependencies
>MPECLIPSE-66 Custom eclipse variables in .classpath generation
> same as MPECLIPSE-85
>MPECLIPSE-61 Support different output folders for different source folders
> The maven eclipse plugin already supports setting
>different output folders for main/test source folders. I couldn't see
> any valid use case for adding different output folders to
>eclipse since maven simply doesn't support that.
>
>---------------------------------------------------------------------
>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]
