[jbosstools-issues] [JBoss JIRA] (JBIDE-24129) download-devstudio profile breaks component builds

[ https://issues.jboss.org/browse/JBIDE-24129?page=com.atlassian.jira.plugi... ] Pavol Srna commented on JBIDE-24129: ------------------------------------ First, let me explain the reason why we need the profile and how we use it. We run integration tests against core devstudio (all plugins) even if the itests are only for e.g. hibernate (or other component) and verify it integrates well with the whole product. We saw some plugin collision problems in the past. When tycho is about to run the itests it computes the target platform and installs com.jboss.devstudio.core.feature.feature.group from <devstudioRepository>https://devstudio.redhat.com/10.0/snapshots/update... into the running eclipse instance. This is defined in the download-devstudio profile. Then it installs itests and runs them. This was completely fine and working when the itests have lived in integration-tests repository as a downstream project.The problem is when we move the itests into component repository and try to run them during the component build process. As you can see from the error message in the description, {{_com.jboss.devstudio.core.feature.feature.group_}} depends on {{_org.jboss.ide.eclipse.as.feature.feature.group_}} and tycho doesn’t resolve the feature from site because we are building the as unit locally. What we would need is to resolve as.feature from site, install {{_com.jboss.devstudio.core.feature.feature.group_}} and then update the plugins with locally build plugins. This seems not to be supported by tycho. We have two options how to approach the problem: # itests run fine if you: cd into component/itests and run {code}mvn clean verify -PITests,download-devstudio{code} But will be disabled on component level by default. # define all itests dependencies in MANIFEST. This has downsides. a) the list can be long and tricky to maintain, b) most likely it will create new dependencies for the component e.g. to m2e, to some other eclipse wizards (plugins) that the itests use, or to server adapter ui for end to end tests. Because integration tests have been designed as downstream devstudio project/component. Therefore they rely on e.g maven import, or server adapter (for the end to end tests) even if the component doesn’t have direct dependencies on these plugins. [~jeffmaury] How would you like to come across the problem? Option 1) seems best to me. -- This message was sent by Atlassian JIRA (v7.2.3#72005)