| Re: [tycho-user] Compilation error during install |
|
On 12/05/2012 07:59 PM, Alex Kravets
wrote:
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. 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.Q2 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? .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. It works exactly the same way locally and on Jenkins.Q4 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? 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. HTH |