Opened 5 years ago

Closed 2 years ago

#8902 closed defect (needmoreinfo)

Vaadin eclipse plugin shouldn't add VAADIN_DOWNLOAD entries to classpath for Maven projects

Reported by: ringerc Owned by: ticketmaster
Priority: normal Milestone:
Component: dontuse-Plug-in for Eclipse (Use github.com/vaadin/eclipse-plugin instead) Version: 6.7.9
Keywords: cleaning Cc:
Depends on:
Workaround:
Verified: no
Fv: no

Description

In Properties -> Java Build Path -> Libraries, Vaadin adds a bunch of VAADIN_DOWNLOAD/ entries when the Vaadin facet is enabled. This is incorrect when Maven and m2e are in use. When working with a Maven project, the Vaadin eclipse plugin shouldn't mess with the project classpath; m2e is responsible for maintaining it.

By adding these entries, Vaadin creates the possibility that the classpath seen by Maven will differ from the classpath seen by Eclipse. If the Vaadin, gwt, etc, versions in the pom.xml differ from those the Vaadin eclipse plugin thinks are in use, exciting and fun breakage can happen, including warnings and compile errors in Eclipse that don't happen with a Maven build, etc.

When the project is a Maven project, the Vaadin plugin should check to see if Vaadin depdendencies are in the pom.xml and offer to add them if they are not, rather than messing with the project class path directly. If they are present in the pom.xml it should auto-set the "Vaadin version" in the facet to the version found in the pom.

It should *NOT* silently add vaadin dependencies to the pom.xml - not unless it's smart enough to check the effective POM for dependencies inherited from a parent pom or via dependencyManagement and transitive dependencies. Correct handling of this would be required to detect the vaadin version in a project reliably anyway. Trying to change the version should produce a warning if the version wasn't set directly in the version field of the dependency - ie if it was inherited from a parent, transitively acquired, from a dependencyManagement pom import, etc. Either that, or changing the version should just not be supported for Maven projects, telling the user to go change it in their pom.xml instead.

Change history (6)

comment:1 Changed 5 years ago by ringerc

Vaadin also copies the Vaadin library into src/main/webapp/WEB-INF/lib/vaadin-6.7.9.jar, which is again incorrect for a Maven project. It should let the maven-dependency-plugin do its job and copy it from the local repository alongside everything else.

Copying it into src/main/webapp/WEB-INF/lib/ practically guarantees fun version conflicts down the track. It must not be done for a Maven project.

Seems the Vaadin plugin doesn't really support Maven / m2e projects yet.

comment:2 Changed 5 years ago by ringerc

The plugin is also generating widget sets in src/main/webapp/VAADIN/widgetsets . Generated files shouldn't be going into src/ in a Maven project, they should be deposited into target/ and the maven archiver plugin should be told where to put them when creating a war archive.

If the generated widget sets are modified by the user after creation then they could go in src/ , but most of the output I'm seeing there isn't user modifiable in any useful way.

The target/ tree isn't deleted except on a "mvn clean" so unless a clean build is requested the widget sets shouldn't need re-generation. On a clean build they *should* be re-generated. So putting them in target/ fits with the normal build lifecycle.

See: http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

You can ask m2eclipse and Maven where the build output directory is, etc.

comment:3 Changed 5 years ago by ringerc

  • Priority changed from undefined to normal

comment:4 Changed 3 years ago by Artur Signell

  • Verified unset

comment:5 Changed 3 years ago by Artur Signell

  • Fv unset

comment:6 Changed 2 years ago by Artur Signell

  • Keywords cleaning added
  • Resolution set to needmoreinfo
  • Status changed from new to closed

A lot of tickets have been left hanging in the issue tracker through the years. Some of them are still relevant, some of them have been fixed a long time ago and some are no longer valid. To get a better look on what is important and still relevant, we are closing old tickets which have not been touched in a long time.

No further work will be done on this ticket unless someone indicates that it's still relevant.

If this ticket is still relevant to you, please reopen it.

Note: See TracTickets for help on using tickets.