Home » Archived » Buckminster » Spaces in path on Windows with Hudson(Path resolution problems on Windows when run from Buckminster Hudson plugin)
| Spaces in path on Windows with Hudson [message #487662] |
Thu, 24 September 2009 01:48  |
 Bob Walker
Messages: 31
Registered: July 2009 |
Member |
|
|
Hi, I'm new here, and still pretty new to Buckminster and RCP development in general, but I hope someone can help.
After several days of head-scratching and frustration, I finally got a working site.p2 build with Hudson last night, and my next step was to try to build a product.
I'm using the org.eclipse.buckminster.tutorial.mailapp.product.feature as a starting point, and have reused the buckminster.cspex and build/product.ant verbatim from that product.
However, I'm struggling with the way paths are getting resolved on windows, and I get the impression all the examples have been done on *nix systems to date. I patched a local version of the Buckminster plugin to get the results I've needed up to now (I'll gladly contribute these changes back if anyone is interested, when they are a bit more tested).
My current problem is that I'm getting errors from the ant actor when it's trying to resolve the "artifactRepository" and "metaDataRepository" paths (these both come from the same source variable, ${repository} in product.ant, which I gather is supplied from this section in buckminster.cspex:
<prerequisites alias="repository">
<attribute name="site.p2"/>
</prerequisites>
Here's the log output from buckminster, it seems clear to me that the problem is because the file path is being resolved to a URI once before it gets passed to ant, and then ant is URLEncoding the path a second time.
However, it doesn't seem to be the Buckminster plugin that is doing the initial toURI(), as I've patched all occurrences in the plugin that I can find.
!SESSION 2009-09-23 17:37:30.213 -----------------------------------------------
eclipse.buildId=unknown
java.version=1.6.0_13
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Framework arguments: -application org.eclipse.equinox.p2.director -artifactRepository file:file:/D:/Data/Java%20Builds/Hudson/jobs/My%20Manager%20RCP%20build/workspace/buckminster.output/arc.manager.feature_1.0.0-eclipse.feature/site.p2/ -metadataRepository file:file:/D:/Data/Java%20Builds/Hudson/jobs/My%20Manager%20RCP%20build/workspace/buckminster.output/arc.manager.feature_1.0.0-eclipse.feature/site.p2/ -destination D:\Data\Java Builds\Hudson\jobs\My App RCP build\workspace\buckminster.output\arc.manager.feature_1.0.0-eclipse.feature\MyManagerApp -bundlepool D:\Data\Java Builds\Hudson\jobs\My App RCP build\workspace\buckminster.output\arc.manager.feature_1.0.0-eclipse.feature\MyManagerApp -profile MyManagerProfile -profileProperties org.eclipse.update.install.features=true -installIU arc.manager.product -p2.os win32 -p2.ws win32 -p2.arch x86
Command-line arguments: -application org.eclipse.equinox.p2.director -artifactRepository file:file:/D:/Data/Java%20Builds/Hudson/jobs/My%20Manager%20RCP%20build/workspace/buckminster.output/arc.manager.feature_1.0.0-eclipse.feature/site.p2/ -metadataRepository file:file:/D:/Data/Java%20Builds/Hudson/jobs/My%20Manager%20RCP%20build/workspace/buckminster.output/arc.manager.feature_1.0.0-eclipse.feature/site.p2/ -destination D:\Data\Java Builds\Hudson\jobs\My App RCP build\workspace\buckminster.output\arc.manager.feature_1.0.0-eclipse.feature\MyManagerApp -bundlepool D:\Data\Java Builds\Hudson\jobs\My App RCP build\workspace\buckminster.output\arc.manager.feature_1.0.0-eclipse.feature\MyManagerApp -profile MyManagerProfile -profileProperties org.eclipse.update.install.features=true -installIU arc.manager.product -p2.os win32 -p2.ws win32 -p2.arch x86 -consoleLog
!ENTRY org.eclipse.equinox.p2.artifact.repository 4 1000 2009-09-23 17:37:31.791
!MESSAGE No repository found at file:/D:/Data/Java%2520Builds/Hudson/jobs/My%2520Manager%2520RCP%2520build/workspace/buckminster.output/my.manager.feature_1.0.0-eclipse.feature/site.p2/.
!ENTRY org.eclipse.equinox.p2.core 4 0 2009-09-23 17:37:31.806
!MESSAGE Unable to load repositories.
As you can see below the initial output from my patched Buckminster Hudson plugin is using unadulterated paths:
Commandline:
java -Dbuckminster.output.root=D:\Data\Java Builds\Hudson\jobs\My Manager RCP build\workspace\buckminster.output -Dbuckminster.temp.root=D:\Data\Java Builds\Hudson\jobs\My Manager RCP build\workspace\buckminster.temp -jar plugins\org.eclipse.equinox.launcher_1.0.200.v20090520.jar -application org.eclipse.buckminster.cmdline.headless -data D:\Data\Java Builds\Hudson\jobs\My Manager RCP build\workspace --loglevel debug -S D:\Data\Java Builds\Hudson\jobs\My Manager RCP build\builds\2009-09-23_20-54-57\commands.txt setpref 'targetPlatformPath=D:\Data\Java Builds\Hudson\jobs\My Manager RCP Platform creation\builds\2009-09-22_11-15-18\archive\targetPlatform'
targetPlatformPath set to the value 'D:\Data\Java Builds\Hudson\jobs\My Manager RCP Platform creation\builds\2009-09-22_11-15-18\archive\targetPlatform'
I guess my question is - why is only that one instance of the file path getting this treatment, and does anyone know of a resolution, or am I going to have to rebuild my Hudson setup without spaces in paths?
Thanks for any insight!
Regards,
Bob Walker
|
|
|
| Re: Spaces in path on Windows with Hudson [message #487695 is a reply to message #487662] |
Thu, 24 September 2009 07:47  |
Johannes Utzig
Messages: 329
Registered: July 2009 |
Senior Member |
|
|
Hi Bob,
see comments inline.
Bob Walker schrieb:
> Hi, I'm new here, and still pretty new to Buckminster and RCP
> development in general, but I hope someone can help.
>
> After several days of head-scratching and frustration, I finally got a
> working site.p2 build with Hudson last night, and my next step was to
> try to build a product.
>
You've probably seen this wiki page?
http://wiki.eclipse.org/Building_an_RCP_application_with_hud son_%28Buckminster%29
Would you mind telling me what is not clear enough to prevent at least
others from several days of head-scratching?
> I'm using the org.eclipse.buckminster.tutorial.mailapp.product.feature
> as a starting point, and have reused the buckminster.cspex and
> build/product.ant verbatim from that product.
> However, I'm struggling with the way paths are getting resolved on
> windows, and I get the impression all the examples have been done on
> *nix systems to date. I patched a local version of the Buckminster
> plugin to get the results I've needed up to now (I'll gladly contribute
> these changes back if anyone is interested, when they are a bit more
> tested).
>
Contributions are always welcome, what was the nature/reason for your
changes?
And yes, every test (from my side) has been on a linux machine, but this
is not really a windows only problem. As soon as ANT Task with p2
incocation meets paths with spaces it fails, I just reproduced that on a
linux machine.
Could you file a bug in the hudson issue tracker on the buckminster
component (https://hudson.dev.java.net/issues/)? That would also be a
good place to apply the changes you made.
I'll investigate some more if there's anything wrong on the plugin side
and if not, file a bug for buckminster.
>
> I guess my question is - why is only that one instance of the file path
> getting this treatment, and does anyone know of a resolution, or am I
> going to have to rebuild my Hudson setup without spaces in paths?
>
I'd suggest you to not use spaces in paths for your build setup because
that usually means extra complexity that you want to avoid for a build.
However, it has to work of course so I'll see what I can do on the
plugin side at least.
Until then, if you want to prevent setting up hudson again, my only
advise would be to define a custom workspace directory for that job
without spaces (that is in the advanced section of the job configuration).
Hope that helps.
Best regards,
Johannes
|
|
|
| Re: Spaces in path on Windows with Hudson [message #487744 is a reply to message #487695] |
Thu, 24 September 2009 10:26 |
Bob Walker
Messages: 31
Registered: July 2009 |
Member |
|
|
Hi Johannes,
Many thanks for the speedy reply, much appreciated.
I don't think there's much wrong with the Wiki page, it's an extremely valuable resource, I think most of my problems have come from diving straight into Buckminster via Hudson, without really understanding how it works and the various parts that it comprises. I've referred to the BuckyBook.pdf extensively, but coming at it from a Maven/Hudson background, Buckminster just seems so unwieldy and complex it's hard to get a handle on it straight away. I think I leaped in too early adding bells and whistles (like p2 cloud update) to my product before trying to build it outside of a development environment. When I came to try to do a clean build in a controlled environment, the Buckminster learning curve was just too steep, and obscuredby trying to wrestle with Hudson integration at the same time.
Most of my troubles have been with:
- Dependencies, and the vagueness of the message "Unable to find localized component for xxxxx". I've spent hours and days tracking down plugin references.
- Maven integration in Resource Maps - I tried to make it resolve plugin jars in my Maven repo, but I just could not get it to work how I expected. I abandoned this in the end, but I'll revisit soon.
- The sheer number of configuration files and extensions, scattered across projects. I have struggled to keep a handle on what goes where, what it does, why, and so on. I appreciate that Buckminster is a level up from Maven in terms of resolving disparate sources, but when I just want to build my product from components that I've written myself and a few standard core rcp features, this all seems much more complex than it should be for my modest requirements.
My problems specifically with the Buckminster Hudson plugin were to do with Windows paths:
1) when the plugin resolves ${WORKSPACE} to a Windows path e.g. D:\Data\MyStuff, it doesn't escape the backslashes, and this ends up as D:DataMyStuff, which obviously can't be resolved. This was particularly an issue when passing targetPlatformPath to buckminster, but I ended up specifying all my paths as escaped absolutes in my Hudson config.
2) This is fairly minor, but it might be worth noting that the "rm -Rf ${WORKSPACE}" option doesn't need translating on a windows platform (I tried to use del /F/S/Q ${WORKSPACE}, this doesn't work), I had forgotten that Hudson expects UnxUtils on windows (see http:// wiki.hudson-ci.org/display/HUDSON/Installation+and+Execution #InstallationandExecution-WindowsInstallation)
I've ended up removing the spaces from my paths in my Hudson setup and I've now hit another different problem trying to execute "create.product.zip", where it says that
"The installable unit my.manager.product has not been found"
I'm not clear where it is looking or why it wouldn't find it, I thought the purpose of the job was to use my .product file and create the installable unit. This is kind of typical of most of the problems I've had - the error messages are not descriptive enough, and give no hints as to a solution.
I'll review my changes to the plugin and see if they are of sufficient quality to submit - my concern is that I've just created a Windows-specific version that I can't easily test on a *nix platform at the moment. My changes were basically to use java.io.File objects for as much of the path handling stuff as possible and only translate to strings at the point where it gets passed to the ProcessBuilder, and additionally to regex replace single backslashes with doubles in the code that builds the setpref targetPlatformPath=
I've filed a bug as requested: https://hudson.dev.java.net/issues/show_bug.cgi?id=4537
Let me know if I can do any more.
Thanks again,
Bob
|
|
|
| Re: Spaces in path on Windows with Hudson [message #487761 is a reply to message #487744] |
Thu, 24 September 2009 11:09 |
Johannes Utzig
Messages: 329
Registered: July 2009 |
Senior Member |
|
|
Hi Bob,
comments inline.
Bob Walker schrieb:
> Hi Johannes,
>
> Many thanks for the speedy reply, much appreciated.
>
> I don't think there's much wrong with the Wiki page, it's an extremely
> valuable resource, I think most of my problems have come from diving
> straight into Buckminster via Hudson, without really understanding how
> it works and the various parts that it comprises. I've referred to the
> BuckyBook.pdf extensively, but coming at it from a Maven/Hudson
> background, Buckminster just seems so unwieldy and complex it's hard to
> get a handle on it straight away. I think I leaped in too early adding
> bells and whistles (like p2 cloud update) to my product before trying to
> build it outside of a development environment. When I came to try to do
> a clean build in a controlled environment, the Buckminster learning
> curve was just too steep, and obscuredby trying to wrestle with Hudson
> integration at the same time.
> Most of my troubles have been with:
>
> - Dependencies, and the vagueness of the message "Unable to find
> localized component for xxxxx". I've spent hours and days tracking down
> plugin references.
> - Maven integration in Resource Maps - I tried to make it resolve
> plugin jars in my Maven repo, but I just could not get it to work how I
> expected. I abandoned this in the end, but I'll revisit soon.
>
Hard to say anything to that without more information
> - The sheer number of configuration files and extensions, scattered
> across projects. I have struggled to keep a handle on what goes where,
> what it does, why, and so on. I appreciate that Buckminster is a level
> up from Maven in terms of resolving disparate sources, but when I just
> want to build my product from components that I've written myself and a
> few standard core rcp features, this all seems much more complex than it
> should be for my modest requirements.
> My problems specifically with the Buckminster Hudson plugin were to do
> with Windows paths:
>
> 1) when the plugin resolves ${WORKSPACE} to a Windows path e.g.
> D:\Data\MyStuff, it doesn't escape the backslashes, and this ends up as
> D:DataMyStuff, which obviously can't be resolved. This was particularly
> an issue when passing targetPlatformPath to buckminster, but I ended up
> specifying all my paths as escaped absolutes in my Hudson config.
>
I see. Thank you for the pointer. Unfortunately I do not have a Windows
machine to test on, but I'll investigate this further.
> 2) This is fairly minor, but it might be worth noting that the "rm -Rf
> ${WORKSPACE}" option doesn't need translating on a windows platform (I
> tried to use del /F/S/Q ${WORKSPACE}, this doesn't work), I had
> forgotten that Hudson expects UnxUtils on windows (see
> http://wiki.hudson-ci.org/display/HUDSON/Installation+and+Ex ecution#InstallationandExecution-WindowsInstallation)
>
Nice. I didn't even know that :)
>
> I've ended up removing the spaces from my paths in my Hudson setup and
> I've now hit another different problem trying to execute
> "create.product.zip", where it says that "The installable unit
> my.manager.product has not been found"
> I'm not clear where it is looking or why it wouldn't find it, I thought
> the purpose of the job was to use my .product file and create the
> installable unit. This is kind of typical of most of the problems I've
> had - the error messages are not descriptive enough, and give no hints
> as to a solution.
The create.product.zip should have the output of site.p2 as a
prerequisite. P2 will look at the p2 repository you specify in the ant
script for the installable unit, it will not build the installable unit
itself. The p2 repository is what buckminster builds for you with the
site.p2 action, so you should point p2 to the output of that action.
I do agree though, that product build should be easier. I was
experimenting with a new action to directly create a product from a
feature without the ant-script commandline invokation, but I'm not ready
yet to submit a patch.
> I'll review my changes to the plugin and see if they are of sufficient
> quality to submit - my concern is that I've just created a
> Windows-specific version that I can't easily test on a *nix platform at
> the moment. My changes were basically to use java.io.File objects for as
> much of the path handling stuff as possible and only translate to
> strings at the point where it gets passed to the ProcessBuilder, and
> additionally to regex replace single backslashes with doubles in the
> code that builds the setpref targetPlatformPath= string.
> I've filed a bug as requested:
> https://hudson.dev.java.net/issues/show_bug.cgi?id=4537
>
Thank you for the bug and the work you're willing to spend on this. But
File objects are not the best choice I think. This will not work in a
master/slave scenario. Although I do know that the plugin currently
fails on master/slave scenarios anyway, I'd like to keep java.io.File
usage to a minimum to make it easier to enable master/slave support. I'd
be very interested in your patch though and hopefully it will be easy
enough to receive the same results without falling back to java.io.File.
Best regards,
Johannes
|
|
|
| Re: Spaces in path on Windows with Hudson [message #487769 is a reply to message #487744] |
Thu, 24 September 2009 11:21 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Bob, thanks for sharing the experience. We want to make it easy for
people to get started, and understanding how people get into trouble,
and where it feels like the learning curves goes vertical :) is very
valuable.
I made some comments inline...
Bob Walker wrote:
> Hi Johannes,
>
> Many thanks for the speedy reply, much appreciated.
>
> I don't think there's much wrong with the Wiki page, it's an extremely
> valuable resource, I think most of my problems have come from diving
> straight into Buckminster via Hudson, without really understanding how
> it works and the various parts that it comprises. I've referred to the
> BuckyBook.pdf extensively, but coming at it from a Maven/Hudson
> background, Buckminster just seems so unwieldy and complex it's hard to
> get a handle on it straight away.
Anything in particular that you found difficult to grasp at first? Any
suggestion what we could do to overcome such a hurdle - some concept
that could have been explained earlier - or explanations that you found
more confusing than helpful etc?
> I think I leaped in too early adding
> bells and whistles (like p2 cloud update) to my product before trying to
> build it outside of a development environment. When I came to try to do
> a clean build in a controlled environment, the Buckminster learning
> curve was just too steep, and obscuredby trying to wrestle with Hudson
> integration at the same time.
> Most of my troubles have been with:
>
> - Dependencies, and the vagueness of the message "Unable to find
> localized component for xxxxx". I've spent hours and days tracking down
> plugin references.
I guess this is in relationship to the hudson-buckminster plugin, and
not Buckminster itself?
> - Maven integration in Resource Maps - I tried to make it resolve
> plugin jars in my Maven repo, but I just could not get it to work how I
> expected. I abandoned this in the end, but I'll revisit soon.
>
Fire away with questions when you decide to give it a second try...
> - The sheer number of configuration files and extensions, scattered
> across projects. I have struggled to keep a handle on what goes where,
> what it does, why, and so on. I appreciate that Buckminster is a level
> up from Maven in terms of resolving disparate sources, but when I just
> want to build my product from components that I've written myself and a
> few standard core rcp features, this all seems much more complex than it
> should be for my modest requirements.
Are you refering to the Buckminster plugins (that gives Buckminster its
capabilities)? And if so, did you experience this with the IDE or
Headless Buckminster? (We know it is a confusing issue that the headless
Buckminster is ignorant (about pretty much everything) on first download.
In the Eclipse-b3 project we hope to rectify some of the issues
regarding complexity - the build system is supposed to make it simpler
to build stuff, not replace one difficulty with another. Although we
believe that Buckminster makes it easier than some of the alternatives,
it is still quite complex - and in some cases, the strict separation of
concerns in Buckminster makes it a developer concern :)
Adding to the complexity is the fact that there are several ways to
specify and build PDE based products - some more complex (and brittle)
than others. The image I have in my head is a balancing act with plates
on sticks, while riding a skateboard on top of a ball bounced around
between a dozen crazy circus seals. The "helpful" message 'Error: plate
dropped' being the typical outcome.
(anyway...)
Many projects do not need the complex separation. At least not at first.
So, a lesson learned in b3 is that it should be possible to specify
"everything" in one place - it should be the developer's choice to break
a configuration up into smaller reusable pieces (if ever required).
Essentially when you start, you really just want to say "build X from
stuff found 'here'."
Don't know how simple we can make it - when stuff is already in the
workspace it is easy. But starting from scratch on a build server
requires knowledge where stuff came from. Some ideas include creation of
the RMAP part by investigating the content of the workspace (and target
platform).
All ideas on how to make things simpler and easy to use are always very
welcome...
Regards
- henrik
|
|
| | |
| Re: Spaces in path on Windows with Hudson [message #487812 is a reply to message #487695] |
Thu, 24 September 2009 13:42 |
Bob Walker
Messages: 31
Registered: July 2009 |
Member |
|
|
| Johannes Utzig wrote on Thu, 24 September 2009 07:09 | Hi Bob,
comments inline.
Bob Walker schrieb:
> Hi Johannes,
>
> Many thanks for the speedy reply, much appreciated.
>
> I don't think there's much wrong with the Wiki page, it's an extremely
> valuable resource, I think most of my problems have come from diving
> straight into Buckminster via Hudson, without really understanding how
> it works and the various parts that it comprises. I've referred to the
> BuckyBook.pdf extensively, but coming at it from a Maven/Hudson
> background, Buckminster just seems so unwieldy and complex it's hard to
> get a handle on it straight away. I think I leaped in too early adding
> bells and whistles (like p2 cloud update) to my product before trying to
> build it outside of a development environment. When I came to try to do
> a clean build in a controlled environment, the Buckminster learning
> curve was just too steep, and obscuredby trying to wrestle with Hudson
> integration at the same time.
> Most of my troubles have been with:
>
> - Dependencies, and the vagueness of the message "Unable to find
> localized component for xxxxx". I've spent hours and days tracking down
> plugin references.
> - Maven integration in Resource Maps - I tried to make it resolve
> plugin jars in my Maven repo, but I just could not get it to work how I
> expected. I abandoned this in the end, but I'll revisit soon.
>
Hard to say anything to that without more information
|
Sure. I appreciate the need for detail, I'll try and pad this out next time I have a try with maven or encounter another missing resource error. I'l also try you troubleshooting tip.
| Quote: |
> - The sheer number of configuration files and extensions, scattered
> across projects. I have struggled to keep a handle on what goes where,
> what it does, why, and so on. I appreciate that Buckminster is a level
> up from Maven in terms of resolving disparate sources, but when I just
> want to build my product from components that I've written myself and a
> few standard core rcp features, this all seems much more complex than it
> should be for my modest requirements.
> My problems specifically with the Buckminster Hudson plugin were to do
> with Windows paths:
>
> 1) when the plugin resolves ${WORKSPACE} to a Windows path e.g.
> D:\Data\MyStuff, it doesn't escape the backslashes, and this ends up as
> D:DataMyStuff, which obviously can't be resolved. This was particularly
> an issue when passing targetPlatformPath to buckminster, but I ended up
> specifying all my paths as escaped absolutes in my Hudson config.
>
I see. Thank you for the pointer. Unfortunately I do not have a Windows
machine to test on, but I'll investigate this further.
|
If you want me to test anything I'd be glad to help.
I also get nasty permissions errors from sh.exe due to me running Hudson out of JBoss as a windows service, but let's not get into that here 
| Quote: |
>
> I've ended up removing the spaces from my paths in my Hudson setup and
> I've now hit another different problem trying to execute
> "create.product.zip", where it says that "The installable unit
> my.manager.product has not been found"
> I'm not clear where it is looking or why it wouldn't find it, I thought
> the purpose of the job was to use my .product file and create the
> installable unit. This is kind of typical of most of the problems I've
> had - the error messages are not descriptive enough, and give no hints
> as to a solution.
The create.product.zip should have the output of site.p2 as a
prerequisite. P2 will look at the p2 repository you specify in the ant
script for the installable unit, it will not build the installable unit
itself. The p2 repository is what buckminster builds for you with the
site.p2 action, so you should point p2 to the output of that action.
I do agree though, that product build should be easier. I was
experimenting with a new action to directly create a product from a
feature without the ant-script commandline invokation, but I'm not ready
yet to submit a patch.
|
Isn't that what
<prerequisites alias="repository">
<attribute name="site.p2"/>
</prerequisites>
in the cspex does? I appear to be passing the site.p2 location successfully in the ${repository} argument to the ant task, see:
INFO: [start my.manager.feature:eclipse.feature$1.0.0.qualifier#create.product]
Prerequisite alias = repository
Product alias = destination
Product base = ${buckminster.output}\
target.arch=x86
buckminster.component=my.manager.feature
workspace.root=D:/Data/JavaBuilds/Hudson/jobs/MyManager/workspace
buckminster.temp=D:/Data/JavaBuilds/Hudson/jobs/MyManager/workspace/buckminster.temp/my.manager.feature_1.0.0-eclipse.feature/temp
buckminster.home=D:\Data\JavaBuilds\Hudson\jobs\MyManager\workspace\features\my.manager.feature\
buckminster.output=D:/Data/JavaBuilds/Hudson/jobs/MyManager/workspace/buckminster.output/my.manager.feature_1.0.0-eclipse.feature
localhost=build
generator.buildTimestamp.format=2009-09-24T09:54:46.950+0000
buckminster.component.type=eclipse.feature
buckminster.version=1.0.0.qualifier
target.nl=en_US
target.ws=win32
eclipse.home=C:\Program Files\eclipse\buckminster3.5
profile=MyManagerProfile
iu=my.manager.product
target.os=win32
target.location=D:\Data\JavaBuilds\Hudson\jobs\MyManagerPlatformCreation\builds\2009-09-24_04-21-22\archive\targetPlatform
[ant] C:\Program Files\eclipse\buckminster3.5\plugins\org.eclipse.equinox.launcher_1.0.200.v20090520.jar
[ant] file:/D:/Data/JavaBuilds/Hudson/jobs/MyManager/workspace/buckminster.output/my.manager.feature_1.0.0-eclipse.feature/site.p2/
[ant] D:\Data\JavaBuilds\Hudson\jobs\MyManager\workspace\buckminster.output\my.manager.feature_1.0.0-eclipse.feature\MyManagerApp
[ant] The installable unit my.manager.product has not been found.
[ant] Application failed, log file location: C:\Program Files\eclipse\buckminster3.5\configuration\1253786100372.log
ERROR: org.eclipse.core.runtime.CoreException: D:\Data\JavaBuilds\Hudson\jobs\MyManager\workspace\features\my.manager.feature\build\product.ant:22: Java returned: 13
org.eclipse.core.runtime.CoreException: D:\Data\JavaBuilds\Hudson\jobs\MyManager\workspace\features\my.manager.feature\build\product.ant:22: Java returned: 13
at org.eclipse.buckminster.ant.AntRunner.handleInvocationTargetException(AntRunner.java:189)
at org.eclipse.buckminster.ant.AntRunner.run(AntRunner.java:352)
at org.eclipse.buckminster.ant.actor.AntActor.internalPerform(AntActor.java:281)
at org.eclipse.buckminster.core.actor.AbstractActor.perform(AbstractActor.java:201)
at org.eclipse.buckminster.core.internal.actor.PerformManager.perform(PerformManager.java:361)
at org.eclipse.buckminster.core.internal.actor.PerformManager.perform(PerformManager.java:405)
at org.eclipse.buckminster.core.commands.Perform.internalRun(Perform.java:118)
at org.eclipse.buckminster.core.commands.WorkspaceCommand.run(WorkspaceCommand.java:191)
at org.eclipse.buckminster.cmdline.AbstractCommand.basicRun(AbstractCommand.java:155)
at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:341)
at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:135)
at org.eclipse.buckminster.cmdline.Headless.start(Headless.java:189)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
at org.eclipse.equinox.launcher.Main.run(Main.java:1311)
at org.eclipse.equinox.launcher.Main.main(Main.java:1287)
Caused by: D:\Data\JavaBuilds\Hudson\jobs\MyManager\workspace\features\my.manager.feature\build\product.ant:22: Java returned: 13
at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at org.apache.tools.ant.Target.performTasks(Target.java:385)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.eclipse.ant.internal.core.ant.EclipseDefaultExecutor.executeTargets(EclipseDefaultExecutor.java:32)
at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
at org.eclipse.ant.internal.core.ant.InternalAntRunner.run(InternalAntRunner.java:622)
at org.eclipse.ant.internal.core.ant.InternalAntRunner.run(InternalAntRunner.java:455)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.buckminster.ant.AntRunner.run(AntRunner.java:344)
... 23 more
I'm unclear as to what should be in that directory though - I can see the plugin and feature jars that comprise my product, what is it that p2 is looking for that constitutes an Installable Unit? Should the .product file end up in there too?
| Quote: |
> I'll review my changes to the plugin and see if they are of sufficient
> quality to submit - my concern is that I've just created a
> Windows-specific version that I can't easily test on a *nix platform at
> the moment. My changes were basically to use java.io.File objects for as
> much of the path handling stuff as possible and only translate to
> strings at the point where it gets passed to the ProcessBuilder, and
> additionally to regex replace single backslashes with doubles in the
> code that builds the setpref targetPlatformPath= string.
> I've filed a bug as requested:
> https://hudson.dev.java.net/issues/show_bug.cgi?id=4537
>
Thank you for the bug and the work you're willing to spend on this. But
File objects are not the best choice I think. This will not work in a
master/slave scenario. Although I do know that the plugin currently
fails on master/slave scenarios anyway, I'd like to keep java.io.File
usage to a minimum to make it easier to enable master/slave support. I'd
be very interested in your patch though and hopefully it will be easy
enough to receive the same results without falling back to java.io.File.
|
I've uploaded a patch based on how I have it working at the moment - this includes the File usage, hopefully you be able to integrate what I've done a little better than I can
|
|
|
| Re: Spaces in path on Windows with Hudson [message #487829 is a reply to message #487769] |
Thu, 24 September 2009 14:20 |
Bob Walker
Messages: 31
Registered: July 2009 |
Member |
|
|
| Henrik Lindberg wrote on Thu, 24 September 2009 07:21 | Bob, thanks for sharing the experience. We want to make it easy for
people to get started, and understanding how people get into trouble,
and where it feels like the learning curves goes vertical  is very
valuable.
I made some comments inline...
Bob Walker wrote:
> Hi Johannes,
>
> Many thanks for the speedy reply, much appreciated.
>
> I don't think there's much wrong with the Wiki page, it's an extremely
> valuable resource, I think most of my problems have come from diving
> straight into Buckminster via Hudson, without really understanding how
> it works and the various parts that it comprises. I've referred to the
> BuckyBook.pdf extensively, but coming at it from a Maven/Hudson
> background, Buckminster just seems so unwieldy and complex it's hard to
> get a handle on it straight away.
Anything in particular that you found difficult to grasp at first? Any
suggestion what we could do to overcome such a hurdle - some concept
that could have been explained earlier - or explanations that you found
more confusing than helpful etc?
| Quote: |
My main hurdles were:
I found it particularly hard to understand how to handle non-OSGi jar resources, I still don't understand this properly and having looked at the source for m2eclipse, ended up embedding my jar resources in my plugins. I tried several approaches from OSGi-awaring my own supporting jars (couldn't get Buckminster to resolve them from Maven because they had "-client" classifiers in the filename), to embedding them all in a single plugin, which I then struggled with getting transitive visibility of the packages within to other plugins.
I still don't understand how my cquery, which is just a copy of the mailapp version should be modified to look for non-standard dependencies.
For example, yesterday I tried to add the Error Log View to my app, as per http://www.vogella.de/blog/2009/08/17/eclipse-rcp-error-view/. this introduces a dependency on , which I assumed would be part of the RCP core, but resulted in me getting "Unable to find localized component for org.eclipse.ui.views.log". I still don't understand how I am supposed to resolve issues like this, so I removed it from my app for now.
|
> I think I leaped in too early adding
> bells and whistles (like p2 cloud update) to my product before trying to
> build it outside of a development environment. When I came to try to do
> a clean build in a controlled environment, the Buckminster learning
> curve was just too steep, and obscuredby trying to wrestle with Hudson
> integration at the same time.
> Most of my troubles have been with:
>
> - Dependencies, and the vagueness of the message "Unable to find
> localized component for xxxxx". I've spent hours and days tracking down
> plugin references.
I guess this is in relationship to the hudson-buckminster plugin, and
not Buckminster itself?
|
I think this is Buckminster rather than the Hudson plugin, but I'm struggling to grasp how I test outside of Hudson, because I haven't used Buckminster outside of my Hudson setup.
| Quote: |
> - Maven integration in Resource Maps - I tried to make it resolve
> plugin jars in my Maven repo, but I just could not get it to work how I
> expected. I abandoned this in the end, but I'll revisit soon.
>
Fire away with questions when you decide to give it a second try...
|
Will do, thanks.
| Quote: |
> - The sheer number of configuration files and extensions, scattered
> across projects. I have struggled to keep a handle on what goes where,
> what it does, why, and so on. I appreciate that Buckminster is a level
> up from Maven in terms of resolving disparate sources, but when I just
> want to build my product from components that I've written myself and a
> few standard core rcp features, this all seems much more complex than it
> should be for my modest requirements.
Are you refering to the Buckminster plugins (that gives Buckminster its
capabilities)? And if so, did you experience this with the IDE or
Headless Buckminster? (We know it is a confusing issue that the headless
Buckminster is ignorant (about pretty much everything) on first download.
In the Eclipse-b3 project we hope to rectify some of the issues
regarding complexity - the build system is supposed to make it simpler
to build stuff, not replace one difficulty with another. Although we
believe that Buckminster makes it easier than some of the alternatives,
it is still quite complex - and in some cases, the strict separation of
concerns in Buckminster makes it a developer concern
Adding to the complexity is the fact that there are several ways to
specify and build PDE based products - some more complex (and brittle)
than others. The image I have in my head is a balancing act with plates
on sticks, while riding a skateboard on top of a ball bounced around
between a dozen crazy circus seals. The "helpful" message 'Error: plate
dropped' being the typical outcome.
(anyway...)
Many projects do not need the complex separation. At least not at first.
So, a lesson learned in b3 is that it should be possible to specify
"everything" in one place - it should be the developer's choice to break
a configuration up into smaller reusable pieces (if ever required).
Essentially when you start, you really just want to say "build X from
stuff found 'here'."
Don't know how simple we can make it - when stuff is already in the
workspace it is easy. But starting from scratch on a build server
requires knowledge where stuff came from. Some ideas include creation of
the RMAP part by investigating the content of the workspace (and target
platform).
All ideas on how to make things simpler and easy to use are always very
welcome...
|
My experience has all been with Headless Buckminster - I only investigated it so that I could perform clean builds away from my dev environment. I didn't have too much trouble setting headless buckminster up once I'd read the instructions at http://wiki.eclipse.org/Installing_Headless_Buckminster properly.
In fact, I get a different error running the same target from within my IDE, seemingly because my project source is located outside of my workspace.
I haven't yet been able to translate the command that the Hudson plugin is running to a command line that I can run to test outside of Hudson.
Coming from a Maven background I quite happy having to be explicit about my project's dependencies, I think the trouble I'm having comes partly from not knowing where various componenents are located, the separation between features and plugins, and the disparate sources that they can be resolved from
I think the biggest overriding benefit that could be brought to the table could be much tighter Maven integration - I played with both the felix plugin and the Tycho stuff, but both had their limitations in terms of creating me a clean build that I could run unmanned in a non-development environment, which is ultimately my single goal.
It would be nice for me to be able to run a maven build that specified some eclipse components as dependencies and my M2 repository mirror could go to the galileo p2 repo and pull them down for me. I think ideally I'd like the complexity of Buckminster hidden from me by a Maven plugin - my maven pom.xml would hjust specify that I have a family of plugins with
dependencies that may or may not be OSGi aware, if they are available in source form from within my pom's immediate family, then build them according to each own plugin or feature's pom.xml, if not, look in a maven repo and handle them accordingly. I wouldn't mind having to specify whether somethign was an OSGi componenent - I would expect to know that information when writing my pom.
I guess this is all the detail in which the devil lies but I agree this has to become simpler to get mass uptake among Java developers. RC blows everything else out of the water in terms of Java desktop development and I absolutley love it as a GUI platform, but it has to get easier to build
Thanks for all your time on this!
|
|
|
| Re: Spaces in path on Windows with Hudson [message #487833 is a reply to message #487812] |
Thu, 24 September 2009 14:02 |
Johannes Utzig
Messages: 329
Registered: July 2009 |
Senior Member |
|
|
Hi Bob.
Thank you very much for the patch. I'll have a closer look as soon as I
can .
>
> Isn't that what
> <prerequisites alias="repository">
> <attribute name="site.p2"/>
> </prerequisites>
>
> in the cspex does? I appear to be passing the site.p2 location
> successfully in the ${repository} argument to the ant task, see:
>
Yes, that's looking good.
>
> I'm unclear as to what should be in that directory though - I can see
> the plugin and feature jars that comprise my product, what is it that p2
> is looking for that constitutes an Installable Unit? Should the .product
> file end up in there too? Quote:
Yes, that's what's supposed to be there. The product file does not need
to be there, it will be in the bundle that defines the product.
As for the IU to use, you want to use the exact same ID as specified in
your product file in 'Overview' tab, 'Product Definition' Section,
'Product' Combobox. This should be identical to the name of plugin that
defined the product extension + '.' + the text in 'ID' of the
org.eclipse.core.runtime.products extension.
Best regards,
Johannes
|
|
|
| Re: Spaces in path on Windows with Hudson [message #487844 is a reply to message #487829] |
Thu, 24 September 2009 14:36 |
Johannes Utzig
Messages: 329
Registered: July 2009 |
Senior Member |
|
|
Hi Bob,
>
> My experience has all been with Headless Buckminster - I only
> investigated it so that I could perform clean builds away from my dev
> environment. I didn't have too much trouble setting headless buckminster
> up once I'd read the instructions at
> http://wiki.eclipse.org/Installing_Headless_Buckminster properly.
> In fact, I get a different error running the same target from within my
> IDE, seemingly because my project source is located outside of my
> workspace.
One of the major benefits of buckminster is, that it should behave
exactly the same, no matter if you have a headless build on a server, or
use the ui in a developers workbench. If you start with a clean
workspace, you should be able to perform the same resultion as you do in
hudson and then right click on your product-defining feature ->
buckminster -> invoke action -> create.product.zip
Without any properties like buckminster.output.root, the result will
appear in your temp directory in 'buckminster'
> I haven't yet been able to translate the command that the Hudson plugin
> is running to a command line that I can run to test outside of Hudson.
Hmm, there really isn't much magic involved. All commands entered in the
UI get persisted into a commands.txt that is passed to buckminster.
Executing the commands sequentially rather than batched with the text
file should however produce the same exact result. Only magic the plugin
does is setting some parameters for buckminster to nicely integrate it
into the hudson workspace. That includes the temp dir, the output dir,
the workspace location and (when using the target platform publisher)
the setTargetPlatformPath.
Maybe I can be of assistance if you tell me where you're facing problems
when writing the commandline.
best regards,
Johannes
|
|
| | | |
| Re: Spaces in path on Windows with Hudson [message #488077 is a reply to message #488059] |
Fri, 25 September 2009 13:50 |
Johannes Utzig
Messages: 329
Registered: July 2009 |
Senior Member |
|
|
Hi Bob,
to me this looks like you're trying to resolve a complete eclipse
platform into the workspace. While this should work in theory, it always
caused me trouble with literally hundreds of plugins in one workspace.
How does your CQuery look like?
Did you set a target platform? If so, what does it contain?
I don't know if it's the best approach, but what always worked best for
me is to define a target platform that describes the general base
content for all my eclipse applications.
This target platform is what the other builds compile against. Most of
the basic plugins can be resolved directly from the target platform and
everything that goes on top of that comes dynamically from the rmap.
Personally I have a separate job that creates the target platform and
then use the target platform publisher of the hudson plugin to pick up
the build result and that allows me to simply reference it in other jobs
(this is like shown in the wiki page for Buckminster integration into
Hudson).
There are many different ways to describe a target platform, but it is
usually a good idea to actually do so instead of just developing against
your development environment. Have a look here:
http://www.modumind.com/2008/04/21/why-create-a-custom-targe t-platform/
Once you actually have such a target platform and activated it in your
development eclipse, buckminster will use this setting. So you can
easily verify if everything works by starting with a fresh workspace,
resolving your query, executing your action.
When this works in the IDE, it will also work headless given that you
use the same target platform on both systems.
If you have a look at the wiki page, you'll see that there too are 2
different jobs. One that materializes a target platform from an eclipse
update site (it uses buckminster for that) and one that builds the
mailapp product against this target platform.
http://wiki.eclipse.org/Building_an_RCP_application_with_hud son_(Buckminster)#Building_a_Target_Platform
Hope that helps and best regards,
Johannes
Bob Walker schrieb:
> OK I'm back to getting "Unable to load localized model for xxxx"
> messages again. My problem here is that I don't understand what the
> error is telling me. To me, it looks like it's saying "you have a
> dependency on component xxxx, and I can't find it". However, I'm getting
> these messages for components that I thought were part of the eclipse
> core, or at least resolvable through the example rmap? Am I
> misunderstanding something? How do I use the dependency visualizer to
> resolve this:
>
>
> Provider
> eclipse.import( http://download.eclipse.org/eclipse/updates/3.5?importType=b inary):
> materializing to
> D:/Data/JavaBuilds/Hudson/jobs/MyManager/workspace/plugins/o rg.eclipse.equinox.common/
>
> ERROR [0005] : Unable to load localized model for
> org.eclipse.equinox.common
> ERROR: Unable to load localized model for org.eclipse.equinox.common
> Provider
> eclipse.import( http://download.eclipse.org/eclipse/updates/3.5?importType=b inary):
> materializing to
> D:/Data/JavaBuilds/Hudson/jobs/MyManager/workspace/plugins/o rg.eclipse.swt/
> ERROR: Errors and Warnings
> org.eclipse.core.runtime.CoreException: Errors and Warnings
> at
> org.eclipse.buckminster.runtime.BuckminsterException.wrap(Bu ckminsterException.java:109)
>
> at
> org.eclipse.buckminster.core.materializer.MaterializationJob .internalRun(MaterializationJob.java:175)
>
> at
> org.eclipse.buckminster.core.materializer.MaterializationJob .run(MaterializationJob.java:144)
>
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Contains: [0005] : Unable to load localized model for
> org.eclipse.equinox.common
> INFO: TAG-ID 0005 = Query for
> my.manager.product.feature:eclipse.feature, path:
> my.manager.product.feature:eclipse.feature$1.0.0.qualifier ->
> my.manager.plugin.publish:osgi.bundle$1.0.0.qualifier ->
> my.manager:osgi.bundle$1.0.0.qualifier ->
> org.eclipse.jface.databinding:osgi.bundle$1.3.0.I20090525-20 00
>
> Doing full workspace refresh
> Waiting for jobs to end
> Finished: FAILURE
>
>
> my rmap is the same as the one at
> http://dev.eclipse.org/svnroot/tools/org.eclipse.buckminster /trunk/org.eclipse.buckminster.tutorial.mailapp.releng/eclip se.rmap
> with the addition of a searchPath for my internal SVN provider.
> Having just checked my SVN history since it last worked, I had used
> "find/remove unused dependencies" from the IDE;
> org.eclipse.jface.databinding was one of those it reported and I
> removed. My app still works locally without it - is this a transitive
> dependency thing? If so, shouldn't that be handled by buckminster?
>
> This is an example of the kind of thing that just brings my progress to
> a dead halt and leaves me utterly confused. Any ideas?
>
> All the best,
>
> Bob
|
|
|
| Re: Spaces in path on Windows with Hudson [message #488109 is a reply to message #488077] |
Fri, 25 September 2009 15:07 |
Bob Walker
Messages: 31
Registered: July 2009 |
Member |
|
|
Hi Johannes,
Thanks for the time you're putting in on this, it's very gratefully received!
Yes I have a target platform set up, I followed the examples on the wiki, and my 2 mspecs + cquerys are exact copies of the content on that page, resolved as per the example with an upstream Hudson job.
I also have a .target definition in my IDE workspace but I can't test it at the moment as the Galileo update site appears to be in the process of being updated? yesterday it was out of action for ages, then today, the RCP and Equinox packages seem to be showing 3.5.1 versions but I don't get any content for those , just lots of errors. This *was* working the last time I looked at it (I only set it up on Tuesday).
My cquery for my product looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<cq:componentQuery xmlns:cq="http://www.eclipse.org/buckminster/CQuery-1.0" resourceMap="eclipse.rmap" shortDesc="Developer CQUERY to get all source for My Manager build">
<cq:rootRequest name="my.manager.product.feature" componentType="eclipse.feature"/>
<cq:property key="target.arch" value="*"/>
<cq:property key="target.os" value="*"/>
<cq:property key="target.ws" value="*"/>
<cq:property key="useBuild" value="RBUILD"/>
</cq:componentQuery>
I notice I'm missing this from the example on the wiki - I did have it there at one point, but had removed it, I think as one of the many things I was trying to make it work. Can you explain the significance if this is the root of this particular problem?
<cq:advisorNode namePattern=".*" useTargetPlatform="false" useWorkspace="false"/>
Many thanks again,
Bob
|
|
|
| Re: Spaces in path on Windows with Hudson [message #488121 is a reply to message #488109] |
Fri, 25 September 2009 15:34 |
Johannes Utzig
Messages: 329
Registered: July 2009 |
Senior Member |
|
|
Hi Bob,
see comments inline
Bob Walker schrieb:
> Hi Johannes,
>
> Thanks for the time you're putting in on this, it's very gratefully
> received!
>
> Yes I have a target platform set up, I followed the examples on the
> wiki, and my 2 mspecs + cquerys are exact copies of the content on that
> page, resolved as per the example with an upstream Hudson job.
> I also have a .target definition in my IDE workspace but I can't test it
> at the moment as the Galileo update site appears to be in the process of
> being updated? yesterday it was out of action for ages, then today, the
> RCP and Equinox packages seem to be showing 3.5.1 versions but I don't
> get any content for those , just lots of errors. This *was* working the
> last time I looked at it (I only set it up on Tuesday).
>
Ok, I have no insight on what's going with the update sites, but if they
are currently publishing 3.5.1 that might of course prevent you from
continuing until it's complete.
You say it's exact copies. Is your target platform materialized
correctly? Did the publisher task archive the right artifact and does
this artifact seem to be complete according to how you defined your
target platform?
This is essential, because it is what your product will complile
against. Everything not included there will be fetched according to your
rmap. If your actual product build has a whole lot external dependencies
in the 'plugins' directory in the hudson workspace, that'd be an
indication that there's a problem with your target platform.
> My cquery for my product looks like this:
>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <cq:componentQuery
> xmlns:cq="http://www.eclipse.org/buckminster/CQuery-1.0"
> resourceMap="eclipse.rmap" shortDesc="Developer CQUERY to get all source
> for My Manager build">
> <cq:rootRequest name="my.manager.product.feature"
> componentType="eclipse.feature"/>
> <cq:property key="target.arch" value="*"/>
> <cq:property key="target.os" value="*"/>
> <cq:property key="target.ws" value="*"/>
> <cq:property key="useBuild" value="RBUILD"/>
> </cq:componentQuery>
>
>
>
> I notice I'm missing this from the example on the wiki - I did have it
> there at one point, but had removed it, I think as one of the many
> things I was trying to make it work. Can you explain the significance if
> this is the root of this particular problem?
>
>
> <cq:advisorNode namePattern=".*" useTargetPlatform="false"
> useWorkspace="false"/>
>
>
Let me try to explain: When buckminster looks for a component X, it will
first try to get it from your workspace. If not there (and it's an OSGi
Bundle) it will try to resolve it directly from the target platform. If
it finds it in there, the bundle will *not* end up in the workspace
because it's already contained in the target platform.
Only if these two shortcuts fail, the Resolution Service is used, which
means your rmap is used.
Now this advisor node means: any component that matches the regex (i.e.
every component in this case) shall not be retrieved from the workspace
nor the target platform. In other words, everything needs to come from
the resolution service.
This is very handy for bootstrapping a target platform, because you
don't want any bundles to be picked up from the buckminster runtime
itself, but from e.g. the eclipse update site.
However, for building your product you do not want this advisor node in
your query because that will have make it behave as if you'd have no
target platform at all and that will add a huge amount of plugins into
your workspace.
Best regards,
Johannes
|
|
| | |
| Re: Spaces in path on Windows with Hudson [message #488379 is a reply to message #487662] |
Mon, 28 September 2009 13:42 |
Bob Walker
Messages: 31
Registered: July 2009 |
Member |
|
|
Whew!
After some problems over the weekend that I assume to be due to the mirror rollout of 3.5.1, I now have a working Hudson/Buckminster build of my app!
Johannes & Henrik: many, many thanks for your help with this, you brought me back from the brink of despair If I can contribute to the project in any way please do let me know, I'm glad to help out.
It seems the last piece was indeed the correlation between the name/id of the product definition and the name/id of its enclosing feature. This was caused because my product definition was created long before I created the enclosing feature, and when I came to making my product feature-based, I just moved the product definition into my feature project, never realising that there needed to be a tie between the names/ids.
Is this just an implementation quirk? I would have thought that having a feature project containing a product definition that has a single feature dependency of the enclosing feature would have been enough to tie everything together? If not, can this be made clearer in the documentation or enforced/validated somehow in the IDE?
Thanks again, one more RCP app is now released into the wild....!
Best regards,
Bob Walker
|
|
|
Goto Forum:
Current Time: Mon May 13 14:40:38 GMT 2024
Powered by FUDForum. Page generated in 0.06869 seconds |
] 
Search
Help
Register
Login
Home
