Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-user] Compilation error during install

On 12/05/2012 07:59 PM, Alex Kravets wrote:
I mavenizied my plugins and features and was able to execute install
goal and can see my plugins in ~/.m2/repository. However, once I
execute install goal again I got the following error:

ERROR] Failed to execute goal
(default-compile) on project com.iwaysoftware.eclipse.common:
Compilation failure: Compilation failure:
[ERROR] /home/akravets/dev/workspaces/trunk/com.iwaysoftware.eclipse.common/src/com/iwaysoftware/eclipse/common/util/[13,0]
[ERROR] public boolean visit(IResourceDelta delta) throws CoreException {
[ERROR] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[ERROR] The method visit(IResourceDelta) of type NamespaceUpdater must
override a superclass method
[ERROR] /home/akravets/dev/workspaces/trunk/com.iwaysoftware.eclipse.common/src/com/iwaysoftware/eclipse/common/model/[317,0]
[ERROR] public int getChildIndex(ITreeNode child) {
[ERROR] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[ERROR] The method getChildIndex(ITreeNode) of type BaseTreeNode must
override a superclass method

I found this strange because in Eclipse workspace I don't see these
errors. So why is it failing during install?
Are you sure you're using the same version of dependencies in Workspace and Tycho (best way is to use the same target-platform definition in IDE and Tycho)? If not that could explain why you see a difference.
If you're using the same version, it's just one more case where PDE and JDT are more forgiving than Tycho. In general, Tycho is stricter, so you can see some issues that are ignored by PDE.
In this case, removing the erroneous @Override annotations may work.

In Buckminster there is a notion of CQUERY and RMAP where you would
specify your top feature, which in turn has dependencies on other
features and plugins. During materialization phase specifying top
feature was enough for discovery of dependencies and transitive
dependencies to occur. In Maven, I find that I need to specify all
features and plugins as modules in parent POM. Is this the correct way
of doing dependency references or am I doing something wrong?
Maven does not have the concept of CQUERY or RMAP. The best way to deal with dependency management with Tycho is IMO to rely on .target files. You can also use those .target in PDE.
.target files don't have concept of cquery neither, but they are quite simple and efficient to list all your 3rd-party dependencies.
Another way to let Tycho resolve dependencies is to specify some p2 <repositories/> in your pom.xml where Tycho will look for dependencies. I prefer .target because it provides more consistency between dev-time and build-time, and because providing a .target is also good for people who want to setup their IDE to work your project since they can directly consume them in PDE to specify dependency resolution.

External dependencies must not be listed as modules, modules are stuff that you want to build and ship, nothing else.

How does resolution phase happens in Jenkins for example using Maven?
Do I need to checkout all features and plugins, specify parent POM and
that's it? Is there way to create some sort of aggregator that
specifies exactly what and where (branches, trunk, tags) something
needs to come from?
It works exactly the same way locally and on Jenkins.
You must either build the parent pom as part of the same Reactor (ie same "mvn verify" instance), or make it available for consumption by installing in local Maven repo (with "mvn install") first, or make it available on an instance of Nexus or other Maven Artifact Repository. If you go for a Nexus(-like) you'll need to specify in your root pom.xml a <repository/> linking to the place where parent is published so Maven will be able to pull it from there.
In your case, I think starting by building parent along with children is the easiest way to get started. Later you'll see whether you need to share parent pom or not.

Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets

Back to the top