I am doing hudson builds of a eclipse product on a windows hudson server, seems most tutorials etc are done for linux, and i ran in to something that i guess is platform specific for the windows version.
Am 13.07.2010 13:25, schrieb David:
> "-DtargetPlatformPath=/Y:/hudson_home/jobs/Get helios target
> platform/workspace//targetPlatform"
>
> notice the extra / before Y: and the extra / after workspace. Thus i get
> a problem with the ${targetPlatformPath} property.
>
Actually the path looks fine to me, the leading / should work. Maybe
the // at the end causes the problem. Can you try
-DtargetPlatformPath=${WORKSPACE}targetPlatform instead (you shouldn't
need to quote that, the hudson plugin is supposed to quote all arguments
when needed.
> trying it the windows way:
> ""-DtargetPlatformPath=${WORKSPACE}\targetPlatform" results in:
>
> -DtargetPlatformPath=/Y:/hudson_home/jobs/Get helios target
> platform/workspace/\targetPlatform"
>
Now this seems to be wrong. You have "" at the beginning and only one "
at the end. See above, you shouldn't have the need to quote anything at all.
> The slash seems to be hardcoded?
If I recall correctly the slash comes from absolutizing the path but a
path with a leading / should be resolvable on a windows system.
The path looks like you build the TP in a separate hudson job. Have you
tried to use the target platform publisher of the plugin instead of
setting the paths manually?
I know, it should work no matter, but in my experience paths with spaces
cause far more trouble than they are worth and I'd keep them away from
my build system. Can you clone the 'Get helios target platform' job as
'Get_helios_target_platform' and see if that makes a difference?
Yes that seemed to fix the problem, i.e on windows getting rid of the /.
-DtargetPlatformPath=${WORKSPACE}targetPlatform
My product actually is a lot of more dependencies so i decided to head on after this small success of provisioning a simple target.
I read somewhere that if i use a target definition file and import it via importtargetdefinition it has problems with resolving directory locations ( http://swissdev.blogspot.com/2010/03/building-products-with. html) don't know if that's true or not still, but i decided to go another route instead of the .target file.
i created a new feature called "se.rsv.zz.eclipse.target.dependencies"
in this feature i added all of my dependencies that are exposed as features / plugins. The are all available via an internal P2 repo that i made conveniently via the B3 aggregator.
I then created an *.cquery and a *.mspec for this target feature. it fetches it from a simple *.rmap that only contains the actual path to the folder that houses the feature that lists all target dependencies and the p2 repo. see below:
Seems to be finding all dependencies, its when its about to start downloading it gets: (same behavior in the ui)
job started with (from hudson)
[workspace] $ C:\Program\Java\jdk1.5.0_14\bin\java.exe -Dbuckminster.output.root=Y:\hudson_home\jobs\build_helios_p roduct\workspace\buckminster.output -Dbuckminster.temp.root=Y:\hudson_home\jobs\build_helios_pro duct\workspace\buckminster.temp -Xmx1024m -DtargetPlatformPath=/Y:/hudson_home/jobs/build_helios_produ ct/workspace/targetPlatform -jar C:\WS\buckminster\buck-headless\plugins\org.eclipse.equinox. launcher_1.1.0.v20100507.jar -application org.eclipse.buckminster.cmdline.headless -data Y:\hudson_home\jobs\build_helios_product\workspace --loglevel debug -S Y:\hudson_home\jobs\build_helios_product\workspace\commands. txt
import 'file:/Z:/proj_zv_vobs_main/eclipse/Products/Helios/se.rsv.z z.eclipse.helios.build/target_platform.mspec'
Platform install location: C:\WS\buckminster\buck-headless
Target platform provided by class org.eclipse.buckminster.pde.internal.PDETargetPlatform
targetPlatformPath set to the value '/Y:/hudson_home/jobs/build_helios_product/workspace/targetP latform/'
Doing full workspace refresh
Waiting for jobs to end
.....
finds all dependencies
.....
ERROR [0001] : No repository found at file:/Z:/proj_zv_vobs_main/eclipse/Products/Helios/se.rsv.zz .eclipse.target.dependencies. ERROR: No repository found at file:/Z:/proj_zv_vobs_main/eclipse/Products/Helios/se.rsv.zz .eclipse.target.dependencies. ERROR: Errors and Warnings org.eclipse.core.runtime.CoreException: Errors and Warnings at org.eclipse.buckminster.runtime.BuckminsterException.wrap(Bu ckminsterException.java:96) at org.eclipse.buckminster.core.materializer.MaterializationJob .internalRun(MaterializationJob.java:150) at org.eclipse.buckminster.core.materializer.MaterializationJob .run(MaterializationJob.java:126) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Contains: [0001] : No repository found at file:/Z:/proj_zv_vobs_main/eclipse/Products/Helios/se.rsv.zz .eclipse.target.dependencies. INFO: TAG-ID 0001 = Query for se.rsv.zz.eclipse.target.dependencies:eclipse.feature/[1.0.0 .qualifier,1.0.0.qualifier]
Doing full workspace refresh Waiting for jobs to end
Archiving artifacts Finished: FAILURE
Can't see whats the problem here..probably something easy that i overlooked
Am 16.07.2010 10:46, schrieb David:
>
> i created a new feature called "se.rsv.zz.eclipse.target.dependencies"
>
> in this feature i added all of my dependencies that are exposed as
> features / plugins. The are all available via an internal P2 repo that i
> made conveniently via the B3 aggregator.
> I then created an *.cquery and a *.mspec for this target feature. it
> fetches it from a simple *.rmap that only contains the actual path to
> the folder that houses the feature that lists all target dependencies
> and the p2 repo. see below:
Hi David,
if you already have your internal p2 repo, why don't you simply create a
target file that points to this internal p2 repo?
I also was aiming to use the deltapack that is exposed over an file path, then after seeing that it doesn't work over file paths i reconsidered. I don't have any requirements (yet) to build for different platforms, but i thought why not do it while i am at it.
So currently i only target to build for x86 win32 win32.
seems i might have to convert the deltapack to an p2 format and upload it as well later.
anyway..that doesn't explain the error i got does it?
Just out of curiosity, why do you consider the delta-pack at all? Why not use the o.e.equinox.executable feature or the
o.e.rcp feature and have Buckminster resolve it against the standard platform repository?
- thomas
On 07/16/2010 12:17 PM, David wrote:
> I also was aiming to use the deltapack that is exposed over an file
> path, then after seeing that it doesn't work over file paths i
> reconsidered. I don't have any requirements (yet) to build for different
> platforms, but i thought why not do it while i am at it.
>
> So currently i only target to build for x86 win32 win32.
>
> seems i might have to convert the deltapack to an p2 format and upload
> it as well later.
>
> anyway..that doesn't explain the error i got does it?
On 07/16/2010 12:41 PM, David wrote:
> Hey Thomas, back from vacation already? :)
>
Yes. People outside of Europe has a very vague understanding of the word :)
> I need to have everything locally inside the firewall. Thus i use an
> aggregated internal site for this.
>
> I think i ran into the same issue posted here:
> http://www.eclipse.org/forums/index.php?t=msg&goto=54570 5&#msg_545705
>
That particular problem no longer applies. Helios contains all fragments today.
> Do i need to update the aggregated helios site? and add all types of
> platform specific configurations to do this?
>
No. We decided to fix that once and for all: