Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Buckminster dev » buckminster.download.source=true causes failure(If buckminster.download.source is true, and buckminster cannot find the source for a plugin, the resolve stage fails)
buckminster.download.source=true causes failure [message #722340] Mon, 05 September 2011 12:35 Go to next message
Alan Underwood is currently offline Alan UnderwoodFriend
Messages: 37
Registered: October 2010
Member
I'm just trying to get a feature to resolve from multiple p2 sites but some plug-ins do not have associated source plug-ins. I would like to resolve and materialize as many source plug-ins in to the IDE's target platform as possible and ignore those where there is no source.

It would be good if Buckminster would continue even if .source plug-ins cannot be found.

Should I file this as a bug?

Alan
Re: buckminster.download.source=true causes failure [message #722380 is a reply to message #722340] Mon, 05 September 2011 14:52 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3232
Registered: July 2009
Senior Member
On 2011-09-05 14:35, Alan Underwood wrote:
> I'm just trying to get a feature to resolve from multiple p2 sites but some plug-ins do not have associated source
> plug-ins. I would like to resolve and materialize as many source plug-ins in to the IDE's target platform as possible
> and ignore those where there is no source.
>
> It would be good if Buckminster would continue even if .source plug-ins cannot be found.
>
The current behavior should match what you want very well. The source bundles are always treated as optional. Do you get
errors that indicate otherwise? If so, perhaps you are trying to materialize a feature that indeed do require a source
bundle?

- thomas

> Should I file this as a bug?
>
> Alan
Re: buckminster.download.source=true causes failure [message #722698 is a reply to message #722380] Tue, 06 September 2011 14:31 Go to previous messageGo to next message
Alan Underwood is currently offline Alan UnderwoodFriend
Messages: 37
Registered: October 2010
Member
Hi, Thomas

I thought it might have been my misunderstanding of what source="true" means. However, I still have a problem resolving the binary plug-in with buckminster.download.source=true when there is no source. I've looked at the CSpecBuilder.addSourceDependency() method, which adds the source plugin dependency to the cspec and sets a filter on that dependency to make it optional (I presume). The filter is:
(&(buckminster.download.source=true)(!(eclipse.p2.optional=false)))

But when it comes to resolving the child node (the .source plug-in) I don't think the filter applied to the dependency is checked - I think it might be using the filter in the context it takes from the binary plug-in which is not optional, but I find it difficult to follow the code.

I have checked the binary plug-in and it has no dependency on .source, the .source dependency is added by the addSourceDependency() method.

Any ideas? Where in the code does the resolver check for filters such as eclipse.p2.optional?

Alan
Re: buckminster.download.source=true causes failure [message #722736 is a reply to message #722698] Tue, 06 September 2011 15:34 Go to previous messageGo to next message
Alan Underwood is currently offline Alan UnderwoodFriend
Messages: 37
Registered: October 2010
Member
Okay, so there is a problem in the ResolverNodeWithJob.buildTree() method, or at least, its dependent objects.
The code loops through the dependencies of the ResolvedNode to create its child queries, which have not got the filter applied to them. The Resolution.cspec.dependencies however, do have the eclipse.p2.optional filter set. So I guess there is a problem where the cspec is having the .source plug-in dependency added with filter, but the Resolved node is not including that filter when it adds those plug-in dependencies.

Then when the ResourceMap.resolve() method calls request.isOptional(), having failed to resolve the .source plug-in, the ComponentRequest.filter field is null, so the whole Buckminster resolution is counted as a failure.

Definitely a bug.
Re: buckminster.download.source=true causes failure [message #722749 is a reply to message #722736] Tue, 06 September 2011 15:38 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3232
Registered: July 2009
Senior Member
On 2011-09-06 17:34, Alan Underwood wrote:
> Okay, so there is a problem in the ResolverNodeWithJob.buildTree() method, or at least, its dependent objects.
> The code loops through the dependencies of the ResolvedNode to create its child queries, which have not got the filter
> applied to them. The Resolution.cspec.dependencies however, do have the eclipse.p2.optional filter set. So I guess there
> is a problem where the cspec is having the .source plug-in dependency added with filter, but the Resolved node is not
> including that filter when it adds those plug-in dependencies.
>
> Then when the ResourceMap.resolve() method calls request.isOptional(), having failed to resolve the .source plug-in, the
> ComponentRequest.filter field is null, so the whole Buckminster resolution is counted as a failure.
>
> Definitely a bug.

I find it odd that I've never encountered this bug although we resolve with source in all our builds. I know for sure
that many bundles doesn't come with source.

Can you give me a bit more detail about your set up and what kind of errors you see? What version of Bucky are you using?

- thomas
Re: buckminster.download.source=true causes failure [message #722977 is a reply to message #722749] Wed, 07 September 2011 11:01 Go to previous messageGo to next message
Alan Underwood is currently offline Alan UnderwoodFriend
Messages: 37
Registered: October 2010
Member
Hi Thomas,

I'm using Buckminster v 1.4.0.v20110712-1350

I have a plug-in org.h2 in maven but there is no source plug-in.

When Buckminster downloads the plug-in it adds the .source dependency with the eclipse.p2.optional filter.

But when Buckminster then tries to fetch the org.h2.source plug-in there is no filter on it, so Buckminster considers it to not be optional, it is required. Somewhere the org.h2.source request loses the optional filter, and I think it is to do with the dependencies on the ResolvedNode (its child nodes) not being the same as the dependencies in the resolution.cspec.dependencies. When I step through the code, the ResolvedNode child which is the org.h2.source does not have a filter (it is null) but when I look at the resolution.cspec.dependency which is org.h2.source the filter is there.
But the ResolverNodeWithJob.buildTree() method uses the ResolvedNode children rather than the resolution children, so there is no filter.

I've just tried it with a test plug-in and it works, though!

Investigating...

Ah! So, if I have an advisor node in my cquery with pattern org.h2 (I'm only overriding the version specifier), THAT is when the resolver fails on the org.h2.source and THAT is when the filter is null.

Any ideas?
Re: buckminster.download.source=true causes failure [message #722979 is a reply to message #722977] Wed, 07 September 2011 11:10 Go to previous messageGo to next message
Alan Underwood is currently offline Alan UnderwoodFriend
Messages: 37
Registered: October 2010
Member
I've tried adding a filter to the advisor node (!(buckminster.component.this=org.h2)) so that org.h2.source is not affected by the advisor node, but it does not help.

At least I've worked out how to make the problem repeatable now...

Alan
Re: buckminster.download.source=true causes failure [message #723019 is a reply to message #722979] Wed, 07 September 2011 12:35 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3232
Registered: July 2009
Senior Member
On 2011-09-07 13:10, Alan Underwood wrote:
> I've tried adding a filter to the advisor node (!(buckminster.component.this=org.h2)) so that org.h2.source is not
> affected by the advisor node, but it does not help.
>
> At least I've worked out how to make the problem repeatable now...
>
> Alan
Use a name pattern instead, i.e. ^org\.h2$

That includes org.ht but excludes org.ht.source

- thomas
Re: buckminster.download.source=true causes failure [message #723020 is a reply to message #722977] Wed, 07 September 2011 12:35 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3232
Registered: July 2009
Senior Member
On 2011-09-07 13:01, Alan Underwood wrote:
> Hi Thomas,
>
> I'm using Buckminster v 1.4.0.v20110712-1350
>
> I have a plug-in org.h2 in maven but there is no source plug-in.
>
> When Buckminster downloads the plug-in it adds the .source dependency with the eclipse.p2.optional filter.
>
> But when Buckminster then tries to fetch the org.h2.source plug-in there is no filter on it, so Buckminster considers it
> to not be optional, it is required. Somewhere the org.h2.source request loses the optional filter, and I think it is to
> do with the dependencies on the ResolvedNode (its child nodes) not being the same as the dependencies in the
> resolution.cspec.dependencies. When I step through the code, the ResolvedNode child which is the org.h2.source does not
> have a filter (it is null) but when I look at the resolution.cspec.dependency which is org.h2.source the filter is there.
> But the ResolverNodeWithJob.buildTree() method uses the ResolvedNode children rather than the resolution children, so
> there is no filter.
>
> I've just tried it with a test plug-in and it works, though!
>
> Investigating...
>
> Ah! So, if I have an advisor node in my cquery with pattern org.h2 (I'm only overriding the version specifier), THAT is
> when the resolver fails on the org.h2.source and THAT is when the filter is null.
>
> Any ideas?

It seems that when you override the version, the filter gets overridden too. Please file a bug on that.

- thomas
Re: buckminster.download.source=true causes failure [message #723024 is a reply to message #722979] Wed, 07 September 2011 13:02 Go to previous messageGo to next message
Alan Underwood is currently offline Alan UnderwoodFriend
Messages: 37
Registered: October 2010
Member
Sorry, that should have been (!(buckminster.component.self=org.h2))

Even if you could specify a filter for the advisor node that allowed you to ignore the .source plugin, it would a pain to have to specify such a filter in those cases the source plugin cannot be found.

My only workaround for the moment is to create a new advisor node for org.h2.source with the 'skip component' option checked, making sure it is above the org.h2 advisor node.

- Alan
Re: buckminster.download.source=true causes failure [message #723028 is a reply to message #723024] Wed, 07 September 2011 13:23 Go to previous message
Alan Underwood is currently offline Alan UnderwoodFriend
Messages: 37
Registered: October 2010
Member
Thomas

Thanks for the tip about the regular expression for the advisor node. That's a better fix than my workaround.

Filed new bug
http://bugs.eclipse.org/bugs/show_bug.cgi?id=356930

Alan

P.S. I hadn't realized the name patterns for advisor nodes were proper java regexes. It would be good to have a better example of a regex for advisor nodes in the bucky book. The screenshots and most examples are very glob-like e.g 'org.eclipse.*' rather than '^org\.eclipse\..*'

[Updated on: Wed, 07 September 2011 13:30]

Report message to a moderator

Previous Topic:Re: buckminster.download.source=true causes failure
Next Topic:Buckminster sample cqueries seem to be missing
Goto Forum:
  


Current Time: Sat Dec 20 12:22:21 GMT 2014

Powered by FUDForum. Page generated in 0.04281 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software