On Tue, Oct 08, 2013 at 04:25:04PM -0700, Denis Golovin wrote:
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.
AH - those should be reported and linked up to a Juno migration jira. i'll get one
created
if noone else beats me to it :)
/max
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
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev