[jbosstools-dev] Upcoming change for TP 4.40.0.Alpha1-SNAPSHOT => Luna M2

Max Rydahl Andersen manderse at redhat.com
Wed Oct 9 03:15:13 EDT 2013


On Tue, Oct 08, 2013 at 10:57:13PM -0700, Denis Golovin wrote:
>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?

yeah :)

/max

>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 at lists.jboss.org
>>>https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>


More information about the jbosstools-dev mailing list