12:57 a.m.
On 10/08/2013 10:47 PM, Max Rydahl Andersen wrote:
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 :)
Juno => Luna?
Denis
/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