|
| Re: How to do CVS update for nightly build [message #383055 is a reply to message #383054] |
Wed, 18 February 2009 15:33   |
|
Hi qd1840,
Yes, it is possible to force an update. The default behavior for
Buckminster is to be happy with what's in the workspace but if you add
an advisor node to the CQUERY where you alter the resolution scope
(uncheck "Workspace" in this case), you will force Buckminster to look
elsewhere (i.e. using the RMAP). For a CVS reader, that will be equal to
performing a CVS update.
Regards,
Thomas Hallgren
qd1840 wrote:
> I have successfully materialized my workspace using buckminster headless
> mode, but after the initial materialization of workspace, every time I
> run the same "buckminster resolve" command, the workspace doesn't get
> updated from CVS. Is there any way I can configure the "resolving"
> process to do CVS update when the workspace is already in place?
> Otherwise, I'll have to delete the existing workspace and re-check
> everything out from CVS, but it's very time consuming for a large project.
>
|
|
|
|
| Re: How to do CVS update for nightly build [message #383070 is a reply to message #383069] |
Thu, 26 February 2009 17:24 |
|
Sorry, you cannot force override. If that's a requirement, you'll need
to start afresh with a new workspace.
- thomas
qd1840 wrote:
>
> Thanks, Thomas, it worked!
>
> But I noticed that it only did update, but what I really need is CVS
> "Override and update" for nightly build, how can I force that?
>
> Thanks,
>
> qd1840
>
|
|
|
|
|
| Re: How to do CVS update for nightly build [message #383226 is a reply to message #383224] |
Fri, 13 March 2009 17:34 |
|
John wrote:
> Hi again!
>
> I forgot to ask explicitely if the problem is that my namePattern i
> incorrect?
> By using "^.*" I expect to match all components. Is this correct?
>
That's correct. You can remove the leading ^ (start of string). It has
no meaning here.
- thomas
|
|
|
| Re: How to do CVS update for nightly build [message #383467 is a reply to message #383220] |
Fri, 13 March 2009 17:36 |
|
Hi John,
From the looks of it, the cspec is generated from a binary jar that
doesn't contain the .product file. You can only build products from
source bundles.
Regards,
Thomas Hallgren
John wrote:
> Hi Thomas!
>
>
> Will this also work if I use readerType="url.catalog"?
> I have added an advisorNode to my cquery:
>
> <cq:advisorNode namePattern="^.*" useWorkspace="false"/>
>
> I have two ecplise workspaces checked out from CVS at different times.
> They are not built and represent the same as was in CVS.
>
> When I run my scritp resolving from either of the two workspaces using:
>
> import buildpsd.cquery
> perform --properties buildpsd.properties
> my.company.cd.psd.delivery#create.my.company.cd.core.applica tion.product
>
> they both build fine when materializing to a clean workspace.
>
> If I first run resolving from the oldest workspace and it have built
> successfully
> and then run resolving from the newest workspace and materialize into
> the same workspace as the first run,
> I get the following error:
>
> CSpec my.company.cd.psd.delivery:osgi.bundle$1.0.0#OSGi has no action,
> group,
> or local artifact named create.my.company.cd.core.application.product
>
> The debug log output is:
>
> import 'buildpsd.cquery'
> Platform install location: C:\buckminster-1.1.340.r09952
> Target platform provided by class
> org.eclipse.buckminster.pde.internal.PDETargetPlatform
> my.company.cd.psd.delivery:osgi.bundle: Using resolver rmap
> my.company.cd.psd.delivery:osgi.bundle: Found match 1.0.0
> INFO: Import complete.
> Doing full workspace refresh
> Waiting for jobs to end
> perform '--properties' 'buildpsd.properties'
> 'my.company.cd.psd.delivery#create.my.company.cd.core.applic ation.product'
> Downloading file:/C:/buckminster-build/buildpsd.properties
>
> It doesn't really look like it resolved any of the new files from the
> newest workspace.
> Does the error come from having already built the product?
> The generated cspec looks like:
>
> <cs:cspec xmlns:cs="http://www.eclipse.org/buckminster/CSpec-1.0"
> name="my.company.cd.psd.delivery" componentType="osgi.bundle"
> version="1.0.0" versionType="OSGi" shortDesc="Delivery Plug-in">
> <cs:dependencies>
> <cs:dependency name="org.eclipse.osgi"
> componentType="osgi.bundle"/>
> </cs:dependencies>
> <cs:actions>
> <cs:public name="buckminster.clean" actor="ant">
> <cs:actorProperties>
> <cs:property key="buildFileId"
> value="buckminster.pdetasks"/>
> <cs:property key="targets" value="delete.dir"/>
> </cs:actorProperties>
> <cs:properties>
> <cs:property key="dir.to.delete"
> value="${buckminster.output}/"/>
> </cs:properties>
> </cs:public>
> <cs:public name="bundle.jar" actor="ant">
> <cs:actorProperties>
> <cs:property key="buildFileId"
> value="buckminster.pdetasks"/>
> <cs:property key="targets" value="recreate.jar"/>
> </cs:actorProperties>
> <cs:prerequisites alias="action.requirements">
> <cs:attribute name="buckminster.component.self"/>
> </cs:prerequisites>
> <cs:products alias="action.output"
> base="${buckminster.output}/">
> <cs:path path="my.company.cd.psd.delivery_1.0.0.jar"/>
> </cs:products>
> </cs:public>
> <cs:private name="target.fragments" actor="copyTargetFragments">
> <cs:products alias="action.output"
> base="${buckminster.output}/fragments/" upToDatePolicy="ACTOR"/>
> </cs:private>
> </cs:actions>
> <cs:groups>
> <cs:public name="bundle.and.fragments">
> <cs:attribute name="target.fragments"/>
> <cs:attribute name="bundle.jar"/>
> </cs:public>
> <cs:public name="bundle.and.fragments.source"/>
> <cs:public name="bundle.jars">
> <cs:attribute name="bundle.and.fragments"/>
> </cs:public>
> <cs:public name="java.binaries">
> <cs:attribute name="buckminster.component.self"/>
> </cs:public>
> </cs:groups>
> </cs:cspec>
>
> Any help is appreciated.
>
> Thanks.
>
> /John
>
|
|
|
|
|
| Re: How to do CVS update for nightly build [message #383474 is a reply to message #383472] |
Mon, 16 March 2009 12:51 |
|
John,
As I explained earlier, the former cspec must be generated from a binary
bundle. I can see that by looking at the group:
<cs:public name="java.binaries">
<cs:attribute name="buckminster.component.self"/>
</cs:public>
I.e. Buckminster considers the 'java.binaries' to consist of the
component "as is". This leads me to believe that this component is not
resolved through the RMAP provider that you think is used. Perhaps it's
resolved from the target platform (do you have this component installed?)
- thomas
John wrote:
> Hi Thomas!
>
>
> My /older_source and /newer_source are actually in different folders. I
> thought maybe the url.catalog readerType was location sensitive, so I
> did the same experiment where I renamed the /newer_source to be in the
> same location as older_source was. This also mirrors the real situation
> more correctly. However, the result was exactly the same. I still get
> the error.
>
> But upon closer inspection I found out that /older_target (let's call it
> /old+new_target) is actually updated with the changes from
> /newer_source. New plugins have been added to /old+new_target, deleted
> plugins have been removed from /old+new_target and modified files have
> been copied to /old+new_target.
>
> When comparing /old+new_target/plugins with /newer_source they appear to
> be equal when it comes to the source files and the plugin meta data
> files. So the import command actually works with the advisorNode I
> added. But the perform command fails because the
> create.my.company.cd.core.application.product action isn't generated in
> the cspec.
>
> When comparing /old+new_target/plugins with /newer_target/plugins they
> are identical when comparing file sizes. This is interesting since
> /newer_target has new plugins where source has been generated by our
> builder when the perform command was executed.
>
> I /old+new_target/plugins the debug log mentioned earlier didn't list
> the actions to be performed as usual. It just fails with the error about
> the missing create.my.company.cd.core.application.product action. But
> for these plugins I can see our builder has also generated source, so
> apparently the build process has been completed. It appear that the only
> problem is that in the /old+new_target case, Buckminster decides not to
> generate a create.my.company.cd.core.application.product action.
>
> Can you (or anybody else) give me a good explanation on why this fails?
>
> Thanks in advance.
>
> /John
>
|
|
|
|
| Re: How to do CVS update for nightly build [message #383477 is a reply to message #383472] |
Mon, 16 March 2009 20:45 |
|
John wrote:
> When comparing /old+new_target/plugins with /newer_target/plugins they
> are identical when comparing file sizes. This is interesting since
> /newer_target has new plugins where source has been generated by our
> builder when the perform command was executed.
>
What source files is it that your builder will generate? Does it
generate a build.properties file or perhaps the .product file? What
triggers your builder? Does it refresh the parent folder after the files
has been added?
- thomas
|
|
|
|
| Re: How to do CVS update for nightly build [message #383481 is a reply to message #383479] |
Mon, 16 March 2009 22:10 |
|
Hi John,
I'm lost here I'm afraid. I can't see why the second build would produce
a cspec with java.binaries as buckminster.component.self unless
Buckminster somehow finds the result of the first build and uses that
instead. But I cannot figure out how that happens. Do you have the
buckminster.output.root pointing into your workspace somehow?
- thomas
John wrote:
> Hi Thomas!
>
>
> Our builder build client stubs to web services. As mentioned here
> http://www.eclipse.org/newsportal/article.php?id=771&gro up=eclipse.tools.buckminster#771
> we only have the wsdl file. But in order for it to work with Buckminster
> we also now have in CVS the generated build.properties, .classpath and
> the emptu src folder as described later in the same thread
> http://www.eclipse.org/newsportal/article.php?id=784&gro up=eclipse.tools.buckminster#784.
> Then out builder runs first and generates the source and then the Java
> builder runs and compiles the classes.
>
> This is for the web service projects. The plugin that misses the create
> action in this case is a very skinny plugin, that just contains our
> product configuration. There is nothing generated there and it conatins
> the build.properties and manifest.mf.
>
> The generated cspec I showed you with the missing create action is for
> this plugin and as mentioned it builds fine except in the combined case.
>
>
> /John.
>
|
|
|
|
|
| Re: How to do CVS update for nightly build [message #383485 is a reply to message #383484] |
Tue, 17 March 2009 10:10 |
|
Hi John,
There's nothing wrong in having all files used by the product separate
from the product configuration. Personally, I would place the product
configuration itself in a feature since I feel it's awkward to have a
bundle with implicit dependencies to a feature. I'm not sure if it's in
anyway related to your current problems though.
I recommend you follow the approach outlined here:
http://thhal.blogspot.com/2008/01/product-configurations.htm l
Regards,
Thomas Hallgren
John wrote:
> Hi Thomas!
>
>
> This is the second problem we have with products. Earlier I reported a
> problem with resolving products from CVS.
> http://www.eclipse.org/newsportal/article.php?id=768&gro up=eclipse.tools.buckminster#768
>
>
> Is it possible that we create our product wrong?
> We basically just have a basic plugin and a product file based on features.
> All files used by the product (png's, ico's, ini's etc.) are located in
> a separate plugin which is included in one of the features referenced by
> the product.
>
> One reason for doing this is that when the product file was co-located
> with these files, we had a circular dependency, but besides that problem
> it was still impossible to resolve it from CVS.
>
> We would also like to continue with this separation in order to have two
> (or more) products using the same files.
>
> Do you think this is again a problem related to products?
>
>
> /John
>
|
|
|
Powered by
FUDForum. Page generated in 0.03857 seconds
] 
Search
Help
Register
Login
Home
