Eclipse Community Forums: Buckminster » Problem importing product with headless Buckminster 3.5

Home » Archived » Buckminster » Problem importing product with headless Buckminster 3.5

Problem importing product with headless Buckminster 3.5 [message #497130]

Thu, 12 November 2009 09:58

Eclipse User

Hi!

I have a problem with resolving a product using headless Buckminster 3.5.

I have a product which is completely feature based and only uses plugins and features.
So most of the Buckminster files are generated for me.
I only have a very simple cspec and rmap.

Using headless Buckminster 3.4 (1.1.340.r10097) I can resolve and build the product.
Using headless Buckminster 3.5 the import action only resolves and materializes the plugin with the product file.
No dependencies are resolved or materialized.

I can, however, successfully resolve and materialize the feature that the product uses
if I specify the feature directly as argument to the import action.

Has something changed between headless Buckminster 3.4 and 3.5?
Shouldn't I be able to use the same cquery and rmap?

Is the problem possibly related to the fact, that my product is in a plugin and not a feature?
If this is the case, is this an intended change of behavior between 3.4 and 3.5?

Thanks in advance.

/John.

Re: Problem importing product with headless Buckminster 3.5 [message #498335 is a reply to message #497130]

Mon, 16 November 2009 09:09

Eclipse User

Hi!

I tried to create a feature instead and included the product file.
Now the import fails instead with the following error:

!MESSAGE ERROR [0001] : No suitable provider for component com.my.company.app.launch2:eclipse.feature was found in resourceMap file:/C:/somepath/buildcore-disk.rmap
ERROR [0001] : No suitable provider for component com.my.company.app.launch2:eclipse.feature was found in searchPath PSD-DISK
ERROR [0001] : Resolution attempt ended with exception: CSpec com.my.company.app.launch2, attribute feature.references already has a prerequisite named com.my.company.app.feature:eclipse.feature#feature.jars
ERROR CSpec com.my.company.app.launch2, attribute feature.references already has a prerequisite named com.my.company.app.feature:eclipse.feature#feature.jars

The name of the feature with the product is: com.my.company.app.launch2.
It contains the product file, which is based on the two features
com.my.company.app.feature and com.my.company.app.dev.feature

There seem to be something strange with the cspec Buckminster generates for com.my.company.app.launch2.
This doesn't happen with the existing plugin com.my.company.app.launch that we currently use to hold the product file.

I don't know if it's relevant, but our target platform is 3.4.0.

And I should also mention that com.my.company.app.launch2 build fine with headless Buckminster 3.4.
Is there something I need to do to make a 3.4 Buckminster build work with 3.5?

I'll appreciate any help on this.

/John

[Updated on: Mon, 16 November 2009 09:18] by Moderator

Re: Problem importing product with headless Buckminster 3.5 [message #498366 is a reply to message #498335]

Mon, 16 November 2009 10:50

Eclipse User

Hi John,
Would it be possible for you to create a test-case that reproduces your problem and attach that to a bugzilla? It's very
hard to guess what the cause might be.

Regards,
Thomas Hallgren

On 11/16/2009 03:09 PM, John wrote:
> Hi!
>
>
> I tried to create a feature instead and included the product file.
> Now the import fails instead with the following error:
>
> !MESSAGE ERROR [0001] : No suitable provider for component
> com.my.company.app.launch2:eclipse.feature was found in resourceMap
> file:/C:/somepath/buildcore-disk.rmap
> ERROR [0001] : No suitable provider for component
> com.my.company.app.launch2:eclipse.feature was found in searchPath PSD-DISK
> ERROR [0001] : Resolution attempt ended with exception: CSpec
> com.my.company.app.launch2, attribute feature.references already has a
> prerequisite named com.my.company.app.feature:eclipse.feature#feature.jars
> ERROR CSpec com.my.company.app.launch2, attribute feature.references
> already has a prerequisite named
> com.my.company.app.feature:eclipse.feature#feature.jars
>
> The name of the feature with the product is: com.my.company.app.launch2.
> It contains the product file, which is based on the two features
> com.my.company.app.feature and com.my.company.app.dev.feature
>
> There seem to be something strange with the cspec Buckminster generates
> for com.my.company.app.launch2.
> This doesn't happen with the existing plugin com.my.company.app.launch
> that we currently use to hold the product file.
>
> I don't know if it's relevant, but our target platform is 3.4.0.
>
> I'll appreciate any help on this.
>
>
> /John

Re: Problem importing product with headless Buckminster 3.5 [message #498770 is a reply to message #497130]

Wed, 18 November 2009 10:20

Eclipse User

Hi!

Thanks for the response.

While I was trying to make a simple testcase as requested,
I stumbled over part of the reason why my build fails with headless Buckminster 3.5.

As mentioned the name of the feature with the product is: com.my.company.app.launch2.
But actually we have two products in the feature (previously a plugin).
One product is for building the production version and includes the feature com.my.company.app.feature.
The other product is for building the development/test version and includes the features
com.my.company.app.feature and com.my.company.app.dev.feature.

If I leave just one of the products in the feature and import using "import com.my.company.app.launch2" I actually get a complete resolved workspace
with all the features and plugins used by the product.

Q1: Is it now a requirement to have only one product defined in a feature/plugin?

If I do the same thing with my old plugin com.my.company.app.launch and only have one product,
I still only get the plugin com.my.company.app.launch resolved in the workspace
and none of the dependencies.

Q2: Is it now a requirement to have the product file in a feature instead of a plugin?

After having resolved using the feature com.my.company.app.launch2,
if I look in the workspaces .metadata\.plugins\org.eclipse.buckminster.core,
there's only a materialization folder with generated files for all the plugins.
With headless Buckminster 3.4 I also have the folders
resolution, provider, and most importantly cspec.

Without the cspecs I don't have an action to perform to build the product.
In this example I would execute the following after the import:
perform com.my.company.app.launch2#create.my.product.id,
where my.product.id is the id of the product.

Q3: Am I missing something to get the cspecs generated as they used to be with 3.4?

Thanks.

/John

[Updated on: Wed, 18 November 2009 17:19] by Moderator

Re: Problem importing product with headless Buckminster 3.5 [message #499229 is a reply to message #497130]

Fri, 20 November 2009 08:48

Eclipse User

Hi!

Regarding Q3 in my previous post, I have come a bit further.

I'm still confused about the cspecs no longer being generated during import/resolve.
I have previously found it useful to look in those.
But I have found out that the build process still works (I can e.g. perform feature.exports)
so they must be generated on the fly but not stored on disk?

More importantly I must then conclude that com.my.company.app.launch2#create.my.product.id
is no longer generated for me, which is really a step back compared to 3.4.
In the BuckyBook there's not a lot of help for this particular issue
and chapter 15 "Building RCP Products" is not written yet (I'm looking forward to that).

But I did find "Building an RCP application with hudson" ( http://wiki.eclipse.org/Building_an_RCP_application_with_hud son_%28Buckminster%29).
I don't use the Buckminster plugin for Hudson (yet) since it became available after our build script was made.
By taking the build folder with the ANT script from the Mailapp tutorial and the buckminster.cspex,
I'm now able to build my test case product and have my zip file created and it executes fine.

I think it's really nice that I can now have the zip file generated for me.
The only glitch is that it also includes an eclipsec.exe.

The only other issue is that the buckminster.cspex contains information,
that in 3.4 was extracted from the product file.
I assume that <path path="MailApp/"/> and <path path="MailApp.zip"/>
can use the value from <launcher name="mailapp"> in the product file?
But is there a way to specify this in buckminster.cspex?
If not I must try to see if the two values supports properties.
Hopefully <property key="iu" value="org.eclipse.buckminster.tutorial.mailapp.product"/> supports using a property.
The profile <property key="profile" value="MailProfile"/> has really no value for my case,
since we're not allowed to distribute a product that updates itself from an update site.
It would be best for me if it could be taken from the launcher name in the product file.

Now I just need to make my real product build. For some reason our custom builder doesn't work (again).

I really miss a short note on "Important changes between Buckminster 3.5 and 3.4".
It would be excellent to have on the Buckminster sites front page (http://wiki.eclipse.org/Buckminster).
Since there's no such note I assumed that I could just build my product as is, but unfortunately not.

My product must be in a feature and there must only be one product file in the feature.
I would really like to know if this is intentional?
I would assume that if I can export the product from Eclipse, then Buckminster should be able to build it.
But that appears not to be the case?

Our major reason to shift to 3.5 is the better support for target platform,
which I expect to be better than 3.4. We're now in a situation where we need to make a product,
which is the basic platform, and then individually features should be build by different teams.
These features are of course dependent on the basic platform, which I expect to make available
as part of the target platform. For development purposes I also think the P2 support will come in handy.
Hopefully I don't run into too many problems with that. Smile

Thanks.

/John

Previous Topic:	Aggregator: how to overcome unmet dependencies?
Next Topic:	Setup / tear down for JUnit plugin tests

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 02 03:37:38 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter