[ https://issues.jboss.org/browse/JBIDE-17464?page=com.atlassian.jira.plugi... ] Fred Bricon edited comment on JBIDE-17464 at 6/30/14 5:08 AM: -------------------------------------------------------------- I can see 3 approaches : * add required_maven_dependencies fix : missing repo would appear in list of requirements instead of current behavior => UI inconsistency. Would also require special handling to load fixes from other plugins than org.jboss.tools.project.examples, to avoid dragging m2e dependencies in examples core. Meh * new import type "maven+zip" : explicitly declares the example is *hybrid*, handles import in 2 steps. That means the day we add gradle support, we'll need gradle+zip. Meh. * augment import type maven to import non-maven eclipse projects as well when listed in <includedProject>. Problem is ProjectExample definitions are mutated when they shouldn't (see https://github.com/jbosstools/jbosstools-central/blob/master/maven%2Fplug... for instance). A proper solution requires to split ProjectExample in a definition class and a working copy class. But that requires some non-trivial refactoring as I expressed before (see JBIDE-17713 ). Other ideas? was (Author: fbricon): I can see 3 approaches : * add required_maven_dependencies fix : missing repo would appear in list of requirements instead of current behavior => UI inconsistency. Would also require special handling to load fixes from other plugins than org.jboss.tools.project.examples, to avoid dragging m2e dependencies in examples core. Meh * new import type "maven+zip" : explicitly declares the example is *hybrid*, handles import in 2 steps. That means the day we add gradle support, we'll need gradle+zip. Meh. * augment import type maven to import non-maven eclipse projects as well when listed in <includedProject>. Problem is ProjectExample definitions are mutated when they shouldn't (see https://github.com/jbosstools/jbosstools-central/blob/master/maven%2Fplug... for instance). A proper solution requires to split ProjectExample in a definition class and a working copy class. But that requires some non-trivial refactoring as I expressed before. Other ideas? -- This message was sent by Atlassian JIRA (v6.2.6#6264)