this discussion about how we build tp it is off topic :)
So lets continue it at some point later.

So far new tp is buildable and build for jbosstools-base works fine.
Other builds like jbosstools-server or jbosstools-hbernate fails with compilation errors in classes that uses eclipse internal packages, which is fine, because we're movin TP to new major release.

Denis

On 10/08/2013 12:10 AM, Mickael Istria wrote:
On 10/08/2013 01:04 AM, Denis Golovin wrote:
On 10/07/2013 12:36 PM, Nick Boldt wrote:
If you resolve the multiple target first, you can then use that to resolve the unified one, as per my instructions below and in the README.
I don't resolve anything, build is supposed to do that for me. If it is not, why all targets are in the same reactor?
Having unified referencing not existing sites in the same reactor makes indeed stuff less clear. Those target platforms are supposed to be built sequentially, and the unified.target requires TP site to be published remotely. You can override the TP site location for testing purpose, and in order to test module, you can use the -Pmultiple profile (cf mail announcing TP changes).
The process for making TP public is
1. Build, validate, deploy multiple
2. Publish unified site (creating when building multiple)
3. Build and validate unified against just published site; and then deploy it

-DtargetRepositoryUrl=file://path/to/jbosstools-target-platforms/jbdevstudio/multiple/target/jbdevstudio-multiple.target.repo/

why this -DtargetRepository= is not set by default to local jbdevstudio/multiple/target/jbdevstudio-multiple.target.repo/  which has been built in the same reactor just couple seconds ago?
IMO, the remote site is a better default value: https://github.com/jbosstools/jbosstools-target-platforms/blob/4.40.x/jbosstools/unified/pom.xml#L16
Although it makes local builds fail just after TP change. it configures a good value which makes sure that if someone runs "mvn clean install", he'll end up with a TP referencing the remote site and not the local one.
What I thought it was verified against the same locations presented in jbdevstudio-multiple.target.repo, because they should be available online to let jbdevstudio/multiple build to work and all metadata is downloaded into local maven repo.
Multiple are built against the multiple dependency repositories, unified is built against the "unified" site we create with all dependencies (which exists for installation purpose).

BTW the same problem with jbosstools tp's after -DtargetRepositoryUrl is set as suggested above

[INFO] Building JBoss Tools Unified (Aggregate) Target Platform 4.40.0.Alpha1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- target-platform-utils:0.16.0-SNAPSHOT:flatten-target (create-target) @ jbosstools-unified ---
[INFO] 
[INFO] --- build-helper-maven-plugin:1.3:attach-artifact (attach-artifacts) @ jbosstools-unified ---
[INFO] 
[INFO] --- target-platform-validation-plugin:0.18.1:validate-target-platform (default) @ jbosstools-unified ---
[INFO] Validating /var/lib/jenkins/workspace/jbosstools-target-platform-luna/jbosstools/unified/target/jbosstools-unified.target...
[INFO] Failed, see Error log below
[ERROR] Validation found errors in 1 .target files:
Could not resolve content of jbosstools-unified.target
Could not find "org.eclipse.swtbot.eclipse.feature.group/2.1.1.201305311053" in the repositories of the current location
Aren't you verifying JBT unified TP against the JBDS unified site? That could explain why SWTBot is missing.


I'll check modules build later.
They are actually the ones that require the more effort. So far, I don't think it's necessary to have so much time spent on the build of target-platforms. which is not very error-prone.

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