Re: [cross-project-issues-dev] validate Juno aggregation with b3 Aggregator Editor

[Adolfo Sánchez-Barbudo Herrera]

  
  
Igor,

El 15/12/2011 17:48, Igor Fedorenko escribió:
Is
  this expected? Apart from removing MDT/OCL, is there anything I
  can
  
  do to make validation (and actual aggregation) succeed for me
  locally?

No it's not expected, I made a mistake removing the corrupted OCL
Tools repository. Now it should be fixed.

P.S: Let the mirrors do their work before verifying that.

Thanks,
Adolfo.
-- 
  


  

  
  
Adolfo
Sánchez-Barbudo Herrera
  adolfosbh(at)opencanarias(dot)com
  C/Elías Ramos González, 4, ofc. 304
  38001 SANTA CRUZ DE TENERIFE
  Tel.: +34 922 240231  

  

  

  

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] validate Juno aggregation with b3 Aggregator Editor

[Igor Fedorenko]

I am following instructions on [1] to validate Juno aggregation with b3
Aggregator Editor and MDT/OCL fails with


  Unable to load repository http://download.eclipse.org/modeling/mdt/ocl
/updates/milestones/4.0.0


Is this expected? Apart from removing MDT/OCL, is there anything I can
do to make validation (and actual aggregation) succeed for me locally?

[1] http://wiki.eclipse.org/Juno/Contributing_to_Juno_Build

--
Regards,
Igor
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] help with Buckminster problem needed

[Henrik Rentz-Reichert]

oops, that flag was dropped by copy/paste in the resource map editor.

Also, when I changed that flag in the editor, the namespace where messed up by 
the editor.
See here a diff with the correct version in green:
http://git.eclipse.org/c/etrice/org.eclipse.etrice.git/commit/releng/org.eclipse.etrice.releng/build.rmap?id=cb5eee108584b4bcd59a4e01ce6946a2db81e643

Now I just changed it in a textual editor.
Thanks, our build is working again :-)

Henrik

Am 15.12.2011 15:34, schrieb Thomas Hallgren:
> Hi Henrik,
>
> It seems the bundle is found in a p2 repository. Then, for some reason, 
> you're using 'eclipse.import' reader type which makes an
> attempt to import the binary bundle into the workspace. A couple of 
> suggestions:
>
> 1. Use 'p2' instead of 'eclipse.import'
> 2. Make sure binary bundles go to your target platform instead of into your 
> workspace.
>
> The latter is probably a case of using source="false" in the provider for 
> binaries.
>
> - thomas
>
>
> On 2011-12-15 15:18, Henrik Rentz-Reichert wrote:
>> thanks Thomas and Dennis,
>>
>> here is the console output of a failed import with --loglevel DEBUG:
>> https://hudson.eclipse.org/hudson/job/mdt-etrice-nightly/143/console
>>
>> I've also allowed workspace access for anonymous.
>>
>> -Henrik
>>
>> Am 15.12.2011 13:17, schrieb Dennis Hübner:
>>> Allow others to browse your job workspace for mdt-etrice-nightly. So we can 
>>> also look into your rmap and cquery.
>>> Regards,
>>> Dennis.
>>>
>>> Am 15.12.2011 um 12:41 schrieb Thomas Hallgren:
>>>
 Please try running with --loglevel DEBUG and then provide a link to the 
 complete build output.
>>>
>>>
>>>
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org
>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

-- 
..
.   ..
. Dr. Henrik Rentz-Reichert .  mailto:h...@protos.de  .
.   .  +49-7551-831365   .
.   ..
.   .  Am Bacheck 7a . 
.   .  D-88662 Überlingen-Deisendorf .
..

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] MORE Issues !!! ... Re: Is it acceptable to have two com.google.common.collect providers?

[David M Williams]

I agree with Igor's response.

> I would rather see there only have to be _one_ signing step, that of
> the final aggregation :)

This assume that everything every project produces is put into the
aggregation repo. Which isn't true (and the stuff that wasn't should be
signed, also).

Plus, if/when projects had their "own" repo (which should frequently be
true) they need their their own bundle there also signed or else there
would be two bundles with same version/qualifier, one signed, one not,
which isn't good.

I realize that some people would like to simply provide the Java code, and
have someone else build it all, sign it all, and everything else releng
related. Maybe someday. But ... in the meantime ... the aggregation is just
an aggregation of what already exists.

Thanks for your comments though.





From:   Jesse McConnell 
To: Cross project issues ,
Date:   12/15/2011 11:49 AM
Subject:Re: [cross-project-issues-dev] MORE Issues !!! ... Re: Is it
acceptable to have two com.google.common.collect providers?
Sent by:cross-project-issues-dev-boun...@eclipse.org



> A better approach (for you) might be to work the test (and failure) into
> your own build and promotion procedures.


I would rather see there only have to be _one_ signing step, that of
the final aggregation :)

then you could just start signing at M1 and people could validate
things are working correctly from then on

cheers,
jesse
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] MORE Issues !!! ... Re: Is it acceptable to have two com.google.common.collect providers?

[Igor Fedorenko]

Many (all?) projects can be installed from project-specific
repositories. Are release artifacts in these project-specific
repositories supposed to be signed too?

--
Regards,
Igor

On 11-12-15 11:49 AM, Jesse McConnell wrote:

A better approach (for you) might be to work the test (and failure) into
your own build and promotion procedures.



I would rather see there only have to be _one_ signing step, that of
the final aggregation :)

then you could just start signing at M1 and people could validate
things are working correctly from then on

cheers,
jesse
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] MORE Issues !!! ... Re: Is it acceptable to have two com.google.common.collect providers?

[Jesse McConnell]

> A better approach (for you) might be to work the test (and failure) into
> your own build and promotion procedures.


I would rather see there only have to be _one_ signing step, that of
the final aggregation :)

then you could just start signing at M1 and people could validate
things are working correctly from then on

cheers,
jesse
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] MORE Issues !!! ... Re: Is it acceptable to have two com.google.common.collect providers?

[David M Williams]

> On the other hand, is not there any way to make the aggregator fail in
case the bundles which feed it are not signed ?

Well, we could ... but, it'd pretty much always fail until M7 :)

A better approach (for you) might be to work the test (and failure) into
your own build and promotion procedures.

[If there was wide-spread consensus no unsigned bundle should ever go into
an aggregated common repo, I'd consider that, but suggest it be widely
discussed in a cross-project feature enhancement request first. I think it
is always hard to trade off an "always correct repository" (which
admittedly would be nice) with the practical aspects of getting the kinks
out of builds and releng ... one of the purposes for having milestones ...
we typically expect steady progress towards perfection, not perfection
every time ... but, if unsigned content was considered so bad or dangerous
to avoid at all costs then it'd be worth considering stricter checks.]

[One thing on my "it'd be nice todo" list is to provide some examples of
how to "run the reports" from your own workspace ... see
http://wiki.eclipse.org/SimRel/Simultaneous_Release_Reports_FAQ ... and
from there, I'm sure many could/would figure out how to automate their own
versions of the tests in their own builds. Thanks for the reminder :) ]






From:   Adolfo Sánchez-Barbudo Herrera 
To: cross-project-issues-dev@eclipse.org,
Date:   12/15/2011 11:25 AM
Subject:Re: [cross-project-issues-dev] MORE Issues !!! ... Re: Is it
acceptable to have two com.google.common.collect providers?
Sent by:cross-project-issues-dev-boun...@eclipse.org



David,

(Ok, The OCL milestones repository is in order again).

Thanks for your tip, I'll identify the plugins which need their qualifier
version need increased for M5.

On the other hand, is not there any way to make the aggregator fail in case
the bundles which feed it are not signed ?

Cheers,
Adolfo.

El 15/12/2011 16:04, David M Williams escribió:

  Yes, for M4, unsigned content wouldn't justify a respin. Its not a
  "blocking" problem nor (directly) causes harm. Its not great ...
  but ...
  not so bad progress can't continue.

  One problem, if you have unsigned content, with one
  version/qualifier, once
  you get it signed (e.g. next milestone) you'll need to be sure the
  version/qualifiers all increase or else someone who "picked up" old,
  unsigned one, might not get new signed one installed into their
  workbench
  or product.  Just a general principle.

  And, it seems you are not the only one with unsigned content in M4 :(
  http://build.eclipse.org/juno/simrel/reports/verifydiroutput/unsigned.txt


  Tip for all: Even if you do everything exactly right, the signing
  process
  can occasionally fail, so its recommended you double check all is
  signed
  from your build, especially for milestones and releases.
  For more information, see
  http://wiki.eclipse.org/JAR_Signing#Can_the_signing_process_fail.3F

  Thanks for the care,







  From:  Adolfo Sánchez-Barbudo Herrera
  
  To:cross-project-issues-dev@eclipse.org,
  Date:  12/15/2011 10:21 AM
  Subject:   [cross-project-issues-dev] MORE Issues !!! ... Re:
  Is it
  acceptable to have two com.google.common.collect
  providers?
  Sent by:   cross-project-issues-dev-boun...@eclipse.org



  David,

  I've detected more problems, which I'm not sure it merits a respin or
  it
  doesn't in a milestone.

  Don't ask me about the reasons (Honestly, I don't know them right
  know) but
  as you may check in the attachment that our milestones repository
  (used to
  contribute to the simultaneous release) has a corrupted M4
  repository:

  1. It contains two bundles per source project ( xxx-1639 and
  xxx-1651).
  2. worse, one of them (xxx-1639) is not signed.
  3. worse, the bundle caught by the aggregator is the unsigned one :(

  That means that the M4 staging repository contains unsigned content,
  which
  I'm not sure is a strong cause for a respin. In any case, I'm doing a
  new
  OCL Core and Tools M4a builds, just in case is necessary for the
  respin. In
  any case, we will remove the corrupted OCL Core repository and create
  a new
  one for our consumers.

  More guesses about the cause of this damned milestones repository
  later.

  Regards and apologies for the inconveniences,
  Adolfo.

  El 15/12/2011 14:25, Ed Willink escribió:
Hi

In Indigo, the com.google.common.collect package was (and still
  is)
provided by the com.google.collect plugin.

It is now also provided by the com.google.guava plugin.

For M4, Xtext 2.2.1 switched to Guava and so switched provider,

Re: [cross-project-issues-dev] MORE Issues !!! ... Re: Is it acceptable to have two com.google.common.collect providers?

[Adolfo Sánchez-Barbudo Herrera]

  
  
David,

(Ok, The OCL milestones repository is in order again).

Thanks for your tip, I'll identify the plugins which need their
qualifier version need increased for M5.

On the other hand, is not there any way to make the aggregator fail
in case the bundles which feed it are not signed ?

Cheers,
Adolfo.

El 15/12/2011 16:04, David M Williams escribió:

  
Yes, for M4, unsigned content wouldn't justify a respin. Its not a
"blocking" problem nor (directly) causes harm. Its not great ... but ...
not so bad progress can't continue.

One problem, if you have unsigned content, with one version/qualifier, once
you get it signed (e.g. next milestone) you'll need to be sure the
version/qualifiers all increase or else someone who "picked up" old,
unsigned one, might not get new signed one installed into their workbench
or product.  Just a general principle.

And, it seems you are not the only one with unsigned content in M4 :(
http://build.eclipse.org/juno/simrel/reports/verifydiroutput/unsigned.txt

Tip for all: Even if you do everything exactly right, the signing process
can occasionally fail, so its recommended you double check all is signed
from your build, especially for milestones and releases.
For more information, see
http://wiki.eclipse.org/JAR_Signing#Can_the_signing_process_fail.3F

Thanks for the care,







From:	Adolfo Sánchez-Barbudo Herrera 
To:	cross-project-issues-dev@eclipse.org,
Date:	12/15/2011 10:21 AM
Subject:	[cross-project-issues-dev] MORE Issues !!! ... Re: Is it
acceptable to have two com.google.common.collect providers?
Sent by:	cross-project-issues-dev-boun...@eclipse.org



David,

I've detected more problems, which I'm not sure it merits a respin or it
doesn't in a milestone.

Don't ask me about the reasons (Honestly, I don't know them right know) but
as you may check in the attachment that our milestones repository (used to
contribute to the simultaneous release) has a corrupted M4 repository:

1. It contains two bundles per source project ( xxx-1639 and xxx-1651).
2. worse, one of them (xxx-1639) is not signed.
3. worse, the bundle caught by the aggregator is the unsigned one :(

That means that the M4 staging repository contains unsigned content, which
I'm not sure is a strong cause for a respin. In any case, I'm doing a new
OCL Core and Tools M4a builds, just in case is necessary for the respin. In
any case, we will remove the corrupted OCL Core repository and create a new
one for our consumers.

More guesses about the cause of this damned milestones repository later.

Regards and apologies for the inconveniences,
Adolfo.

El 15/12/2011 14:25, Ed Willink escribió:
  Hi

  In Indigo, the com.google.common.collect package was (and still is)
  provided by the com.google.collect plugin.

  It is now also provided by the com.google.guava plugin.

  For M4, Xtext 2.2.1 switched to Guava and so switched provider, but
  the old provider is still available in repositories for downstream
  projects that neglect to update their dependencies accurately.

  As a consequence, the M4 OCL Tools contribution provides broken
  editors. Since these are technically 'Examples', a respin is clearly
  not merited, so MDT/OCL will be providing an M4a.

  However it seems appropriate to at least warn the community of this
  hazard, and ask whether this is a serious breach of versioning
  principles.

  Regards

  Ed Willink
  ___
  cross-project-issues-dev mailing list
  cross-project-issues-dev@eclipse.org
  https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


--
   
Open Adolfo Sánchez-Barbudo Herrera
  Canarias,  adolfosbh(at)opencanarias(dot)com 
S.L. C/Elías Ramos González, 4, ofc.   
 304   
 38001 SANTA CRUZ DE TENERIFE  
 Tel.: +34 922 240231  
   

[attachment "Snapshot.PNG" deleted by David M Williams/Raleigh/IBM]
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev




-- 
  


  

  
  
Adolfo
Sánchez-Barbudo Herrera
  adolfosbh(at)opencanarias(dot)com
  C/Elías Ramos González, 4, ofc. 304
  38001 SANTA CRUZ DE TENERIFE
  Tel.: +34 922 240231  

  

  

Re: [cross-project-issues-dev] MORE Issues !!! ... Re: Is it acceptable to have two com.google.common.collect providers?

[David M Williams]

Yes, for M4, unsigned content wouldn't justify a respin. Its not a
"blocking" problem nor (directly) causes harm. Its not great ... but ...
not so bad progress can't continue.

One problem, if you have unsigned content, with one version/qualifier, once
you get it signed (e.g. next milestone) you'll need to be sure the
version/qualifiers all increase or else someone who "picked up" old,
unsigned one, might not get new signed one installed into their workbench
or product.  Just a general principle.

And, it seems you are not the only one with unsigned content in M4 :(
http://build.eclipse.org/juno/simrel/reports/verifydiroutput/unsigned.txt

Tip for all: Even if you do everything exactly right, the signing process
can occasionally fail, so its recommended you double check all is signed
from your build, especially for milestones and releases.
For more information, see
http://wiki.eclipse.org/JAR_Signing#Can_the_signing_process_fail.3F

Thanks for the care,







From:   Adolfo Sánchez-Barbudo Herrera 
To: cross-project-issues-dev@eclipse.org,
Date:   12/15/2011 10:21 AM
Subject:[cross-project-issues-dev] MORE Issues !!! ... Re: Is it
acceptable to have two com.google.common.collect providers?
Sent by:cross-project-issues-dev-boun...@eclipse.org



David,

I've detected more problems, which I'm not sure it merits a respin or it
doesn't in a milestone.

Don't ask me about the reasons (Honestly, I don't know them right know) but
as you may check in the attachment that our milestones repository (used to
contribute to the simultaneous release) has a corrupted M4 repository:

1. It contains two bundles per source project ( xxx-1639 and xxx-1651).
2. worse, one of them (xxx-1639) is not signed.
3. worse, the bundle caught by the aggregator is the unsigned one :(

That means that the M4 staging repository contains unsigned content, which
I'm not sure is a strong cause for a respin. In any case, I'm doing a new
OCL Core and Tools M4a builds, just in case is necessary for the respin. In
any case, we will remove the corrupted OCL Core repository and create a new
one for our consumers.

More guesses about the cause of this damned milestones repository later.

Regards and apologies for the inconveniences,
Adolfo.

El 15/12/2011 14:25, Ed Willink escribió:
  Hi

  In Indigo, the com.google.common.collect package was (and still is)
  provided by the com.google.collect plugin.

  It is now also provided by the com.google.guava plugin.

  For M4, Xtext 2.2.1 switched to Guava and so switched provider, but
  the old provider is still available in repositories for downstream
  projects that neglect to update their dependencies accurately.

  As a consequence, the M4 OCL Tools contribution provides broken
  editors. Since these are technically 'Examples', a respin is clearly
  not merited, so MDT/OCL will be providing an M4a.

  However it seems appropriate to at least warn the community of this
  hazard, and ask whether this is a serious breach of versioning
  principles.

  Regards

  Ed Willink
  ___
  cross-project-issues-dev mailing list
  cross-project-issues-dev@eclipse.org
  https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


--
   
Open Adolfo Sánchez-Barbudo Herrera
  Canarias,  adolfosbh(at)opencanarias(dot)com 
S.L. C/Elías Ramos González, 4, ofc.   
 304   
 38001 SANTA CRUZ DE TENERIFE  
 Tel.: +34 922 240231  
   

[attachment "Snapshot.PNG" deleted by David M Williams/Raleigh/IBM]
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] MORE Issues !!! ... Re: Is it acceptable to have two com.google.common.collect providers?

[Adolfo Sánchez-Barbudo Herrera]

  
  
Markus 

Yes the problem is basically B). Somebody installing the OCL
features will receive a message about unsigned content. If this is
not a problem in M4, all right from our side.

To fix the other problem Ed mentioned we will publish (at [1]) a new
M4a for OCL consumers anyway.

[1] http://download.eclipse.org/modeling/mdt/ocl/updates/milestones

Regards,
Adolfo.
El 15/12/2011 15:48, Markus Knauer escribió:
So you are saying that
  
  A) you didn't contribute the latest and greatest to the
  Simultaneous Release repository and
  B) some (or all) of your artifacts in the Simultaneous Release
  repository are not signed.
  
  But in the end the Simultaneous Release repository is *not*
  corrupt, right? If it is only about A) and B) then I doubt that
  this qualifies for an M4 respin (in my opinion).
  
  Regards, Markus
  
  
  
2011/12/15 Adolfo Sánchez-Barbudo Herrera 

   David,

I've detected more problems, which I'm not sure it merits a
respin or it doesn't in a milestone.

Don't ask me about the reasons (Honestly, I don't know them
right know) but as you may check in the attachment that our
milestones repository (used to contribute to the
simultaneous release) has a corrupted M4 repository:

1. It contains two bundles per source project ( xxx-1639 and
xxx-1651).
2. worse, one of them (xxx-1639) is not signed.
3. worse, the bundle caught by the aggregator is the
unsigned one :(

That means that the M4 staging repository contains unsigned
content, which I'm not sure is a strong cause for a respin.
In any case, I'm doing a new OCL Core and Tools M4a builds,
just in case is necessary for the respin. In any case, we
will remove the corrupted OCL Core repository and create a
new one for our consumers.

More guesses about the cause of this damned milestones
repository later.

Regards and apologies for the inconveniences,
Adolfo.

El 15/12/2011 14:25, Ed Willink escribió:
Hi 
  
  In Indigo, the com.google.common.collect package was (and
  still is) provided by the com.google.collect plugin. 
  
  It is now also provided by the com.google.guava plugin. 
  
  For M4, Xtext 2.2.1 switched to Guava and so switched
  provider, but the old provider is still available in
  repositories for downstream projects that neglect to
  update their dependencies accurately. 
  
  As a consequence, the M4 OCL Tools contribution provides
  broken editors. Since these are technically 'Examples', a
  respin is clearly not merited, so MDT/OCL will be
  providing an M4a. 
  
  However it seems appropriate to at least warn the
  community of this hazard, and ask whether this is a
  serious breach of versioning principles. 
  
      Regards 
  
      Ed Willink 
  ___ 
  cross-project-issues-dev mailing list 
  cross-project-issues-dev@eclipse.org
  
  https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
  
  
   
 
-- 
  

  

  
  
Adolfo
Sánchez-Barbudo Herrera
  adolfosbh(at)opencanarias(dot)com
  C/Elías Ramos González, 4, ofc. 304
  38001 SANTA CRUZ DE TENERIFE
  Tel.: +34
922 240231  

  

  

  
  
  ___
  cross-project-issues-dev mailing list
  cross-project-issues-dev@eclipse.org
  https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
  

  
  
  
  
  
  
  ___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



-- 
  
 

Re: [cross-project-issues-dev] MORE Issues !!! ... Re: Is it acceptable to have two com.google.common.collect providers?

[Markus Knauer]

So you are saying that

A) you didn't contribute the latest and greatest to the Simultaneous
Release repository and
B) some (or all) of your artifacts in the Simultaneous Release repository
are not signed.

But in the end the Simultaneous Release repository is *not* corrupt, right?
If it is only about A) and B) then I doubt that this qualifies for an M4
respin (in my opinion).

Regards, Markus


2011/12/15 Adolfo Sánchez-Barbudo Herrera 

>  David,
>
> I've detected more problems, which I'm not sure it merits a respin or it
> doesn't in a milestone.
>
> Don't ask me about the reasons (Honestly, I don't know them right know)
> but as you may check in the attachment that our milestones repository (used
> to contribute to the simultaneous release) has a corrupted M4 repository:
>
> 1. It contains two bundles per source project ( xxx-1639 and xxx-1651).
> 2. worse, one of them (xxx-1639) is not signed.
> 3. worse, the bundle caught by the aggregator is the unsigned one :(
>
> That means that the M4 staging repository contains unsigned content, which
> I'm not sure is a strong cause for a respin. In any case, I'm doing a new
> OCL Core and Tools M4a builds, just in case is necessary for the respin. In
> any case, we will remove the corrupted OCL Core repository and create a new
> one for our consumers.
>
> More guesses about the cause of this damned milestones repository later.
>
> Regards and apologies for the inconveniences,
> Adolfo.
>
> El 15/12/2011 14:25, Ed Willink escribió:
>
> Hi
>
> In Indigo, the com.google.common.collect package was (and still is)
> provided by the com.google.collect plugin.
>
> It is now also provided by the com.google.guava plugin.
>
> For M4, Xtext 2.2.1 switched to Guava and so switched provider, but the
> old provider is still available in repositories for downstream projects
> that neglect to update their dependencies accurately.
>
> As a consequence, the M4 OCL Tools contribution provides broken editors.
> Since these are technically 'Examples', a respin is clearly not merited, so
> MDT/OCL will be providing an M4a.
>
> However it seems appropriate to at least warn the community of this
> hazard, and ask whether this is a serious breach of versioning principles.
>
> Regards
>
> Ed Willink
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
> --
>   [image: Open Canarias, S.L.]
>   *Adolfo Sánchez-Barbudo Herrera*
> adolfosbh(at)opencanarias(dot)com
> C/Elías Ramos González, 4, ofc. 304
> 38001 SANTA CRUZ DE TENERIFE
> Tel.: +34 922 240231
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
<>___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Old builds no longer deleted as per config?

[Adolfo Sánchez-Barbudo Herrera]

  
  
Hi Eikke,

I'm also having this issue with my jobs... it should have been some
kind of change in hudson version increase... but no idea, certainly.

Cheers,
Adolfo.

El 15/12/2011 15:10, Eike Stepper escribió:
Hi,
  
  
  I have the feeling that my Hudson configuration (keep max of 3 old
  builds) is ignored:
  https://hudson.eclipse.org/hudson/job/emf-cdo-integration/configure
  
  
  I'm almost sure this did work in the past. Is somebody havig the
  same problem?
  
  
  Cheers
  
  /Eike
  
  
  
  
  http://www.esc-net.de
  
  http://thegordian.blogspot.com
  
  http://twitter.com/eikestepper
  
  
  
  ___
  
  cross-project-issues-dev mailing list
  
  cross-project-issues-dev@eclipse.org
  
  https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
  
  


-- 
  


  

  
  
Adolfo
Sánchez-Barbudo Herrera
  adolfosbh(at)opencanarias(dot)com
  C/Elías Ramos González, 4, ofc. 304
  38001 SANTA CRUZ DE TENERIFE
  Tel.: +34 922 240231  

  

  

  

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] MORE Issues !!! ... Re: Is it acceptable to have two com.google.common.collect providers?

[Adolfo Sánchez-Barbudo Herrera]

  
  
David,

I've detected more problems, which I'm not sure it merits a respin
or it doesn't in a milestone.

Don't ask me about the reasons (Honestly, I don't know them right
know) but as you may check in the attachment that our milestones
repository (used to contribute to the simultaneous release) has a
corrupted M4 repository:

1. It contains two bundles per source project ( xxx-1639 and
xxx-1651).
2. worse, one of them (xxx-1639) is not signed.
3. worse, the bundle caught by the aggregator is the unsigned one :(

That means that the M4 staging repository contains unsigned content,
which I'm not sure is a strong cause for a respin. In any case, I'm
doing a new OCL Core and Tools M4a builds, just in case is necessary
for the respin. In any case, we will remove the corrupted OCL Core
repository and create a new one for our consumers.

More guesses about the cause of this damned milestones repository
later.

Regards and apologies for the inconveniences,
Adolfo.

El 15/12/2011 14:25, Ed Willink escribió:
Hi
  
  
  In Indigo, the com.google.common.collect package was (and still
  is) provided by the com.google.collect plugin.
  
  
  It is now also provided by the com.google.guava plugin.
  
  
  For M4, Xtext 2.2.1 switched to Guava and so switched provider,
  but the old provider is still available in repositories for
  downstream projects that neglect to update their dependencies
  accurately.
  
  
  As a consequence, the M4 OCL Tools contribution provides broken
  editors. Since these are technically 'Examples', a respin is
  clearly not merited, so MDT/OCL will be providing an M4a.
  
  
  However it seems appropriate to at least warn the community of
  this hazard, and ask whether this is a serious breach of
  versioning principles.
  
  
      Regards
  
  
      Ed Willink
  
  ___
  
  cross-project-issues-dev mailing list
  
  cross-project-issues-dev@eclipse.org
  
  https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
  
  


-- 
  


  

  
  
Adolfo
Sánchez-Barbudo Herrera
  adolfosbh(at)opencanarias(dot)com
  C/Elías Ramos González, 4, ofc. 304
  38001 SANTA CRUZ DE TENERIFE
  Tel.: +34 922 240231  

  

  

  

<>___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Old builds no longer deleted as per config?

[Eike Stepper]

Hi,

I have the feeling that my Hudson configuration (keep max of 3 old builds) is ignored: 
https://hudson.eclipse.org/hudson/job/emf-cdo-integration/configure


I'm almost sure this did work in the past. Is somebody havig the same problem?

Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] help with Buckminster problem needed

[Thomas Hallgren]

  
  
Hi Henrik,

It seems the bundle is found in a p2 repository. Then, for some
reason, you're using 'eclipse.import' reader type which makes an
attempt to import the binary bundle into the workspace. A couple of
suggestions:

1. Use 'p2' instead of 'eclipse.import'
2. Make sure binary bundles go to your target platform instead of
into your workspace.

The latter is probably a case of using source="false" in the
provider for binaries.

- thomas


On 2011-12-15 15:18, Henrik Rentz-Reichert wrote:

  
  thanks Thomas and
Dennis,

here is the console output of a failed import with --loglevel
DEBUG:
https://hudson.eclipse.org/hudson/job/mdt-etrice-nightly/143/console

I've also allowed workspace access for anonymous.

-Henrik
  
  Am 15.12.2011 13:17, schrieb Dennis Hübner:
  Allow others to browse your job workspace for mdt-etrice-nightly. So we can also
look into your rmap and cquery.
Regards,
Dennis.

  
Am 15.12.2011 um 12:41 schrieb Thomas Hallgren:

Please try
running with --loglevel DEBUG and then provide a link to
the complete build output.
  
  




___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

  
  
  

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



  

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Make FamFamFam part of Orbit ?

[Mickael Istria]

Hi all,

I often see some projects using icons from the FamFamFam gallery [1], 
after agreement by a CQ. I'd like to use them from time to time too, but 
I generally tells myself "I'll open a CQ and do that later" and never 
does so...
I am wondering whether it would make sense to have a project containing 
bundles with such icons in it. Do you think it could be part of Orbit? 
Or maybe we could start a new Eclipse project dedicated to making such 
non-code resources easier to consumes and that would factorize them 
instead of duplicating, the same way Orbit does for Java libraries?


Regards,

[1] http://www.famfamfam.com/
--

Mickael Istria
R&D Engineer, Eclipse Plug-in RCP Developer

PetalsLink  - Open Source SOA

My blog  - My Tweets 



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Is it acceptable to have two com.google.common.collect providers?

[Ed Willink]

Hi

In Indigo, the com.google.common.collect package was (and still is) 
provided by the com.google.collect plugin.


It is now also provided by the com.google.guava plugin.

For M4, Xtext 2.2.1 switched to Guava and so switched provider, but the 
old provider is still available in repositories for downstream projects 
that neglect to update their dependencies accurately.


As a consequence, the M4 OCL Tools contribution provides broken editors. 
Since these are technically 'Examples', a respin is clearly not merited, 
so MDT/OCL will be providing an M4a.


However it seems appropriate to at least warn the community of this 
hazard, and ask whether this is a serious breach of versioning principles.


Regards

Ed Willink
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] help with Buckminster problem needed

[Henrik Rentz-Reichert]

thanks Thomas and Dennis,

here is the console output of a failed import with --loglevel DEBUG:
https://hudson.eclipse.org/hudson/job/mdt-etrice-nightly/143/console

I've also allowed workspace access for anonymous.

-Henrik

Am 15.12.2011 13:17, schrieb Dennis Hübner:
> Allow others to browse your job workspace for mdt-etrice-nightly. So we can 
> also look into your rmap and cquery.
> Regards,
> Dennis.
>
> Am 15.12.2011 um 12:41 schrieb Thomas Hallgren:
>
>> Please try running with --loglevel DEBUG and then provide a link to the 
>> complete build output.
>
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Status and outlook near end of M4 +3

[Bob Brodt]

But...I had already done that (open the release tracker, set the offset and a bunch of other fields, and clicked the "track with parent" link) yesterday.Any idea why soa.bpel wasn't showing up?

  

  
  
Okay, I sorted it out.

Flipping the bit--it turns out--isn't enough.

After flipping the bit, projects will have to open the "Simultaneous
Release Tracker" component and set any of the values. I recommend
setting the offset.

If your project is releasing as part of the parent project, click
the "track with parent" link.

We're working on making this better.

Wayne

On 12/14/2011 10:07 PM, Wayne Beaton wrote:

  
  It looks like it should work. I am investigating.
  
  Wayne
  
  On 12/14/2011 07:18 PM, Bob Brodt wrote:
  
Argh, one more try:
  
  
  
  
Yes, I have read this wiki...but I'm still confused.
  Here's the portal page showing the "flipping of the
  simultaneousrelease bit" for soa.bpel:
  
  Yes, I have read this
  wiki...but I'm still confused. Here's the portal page
  showing the "flipping of the simultaneousrelease bit" for
  soa.bpel:
  
  
  
  Are there any other bits that need flipping or am I
  looking at the wrong bit or what?
  
  the release train requirements are listed here
http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements
  
   2011/12/15 Bob Brodt 

  
 okI thought I had already "flipped the
  bit". Not sure what else I need to do other
  than setting the "simultaneousrelease"
  metadata to "1" for juno (soa.bpel project)
  and filling in the simultaneous release
  tracker. What am I missing?

  


  
 
  

   AFAICT, BPEL has not yet
flipped the bit for Juno. Can you please
do that?

The calendar and other resources are
accessible from the wiki http://wiki.eclipse.org/Juno

Thanks,

Wayne

On 12/14/2011 06:13 PM, Bob Brodt wrote:

  Yes, I'm not here 
I don't think BPEL will be in the aggregation build by tonight. When is M5?


Robert ("Bob") Brodt
Senior Software Engineer
JBoss by Red Hat

- Original Message -

  
Roll call ... I think the last aggregation build got all the latest
changes/additions for M4, but please speak up now if your
contribution
isn't there yet.

I promoted the latest results to /releases/staging so you can
check/test
there, if all is as expected.

If anyone needs to contribute by 7 PM Eastern, I'd think that'd be
containable ... after that, I'd begin to ask if better to wait to M5,
or
other more specific questions.

Oh, and you don't really need to answer "roll call" unless there's
problems ... like my teachers used to say "if anyone is not here,
will you
please speak up?"  :)


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


  
  ___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev




-- 
  Wayne Beaton
  The Eclipse Foundation
  Twitter: @waynebeaton
  

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
  
  

Re: [cross-project-issues-dev] Xtext M4 ?

[Paul Webster]

On Wed, Dec 14, 2011 at 3:01 PM, Dennis Hübner wrote:

>  Am 14.12.11 20:52, schrieb Thomas Hallgren:
>
> On 2011-12-14 20:44, Dennis Hübner wrote:
> >
> > I think it's also a good idea to point b3 aggregator to projects nightly
> > update site after a milestone is released.
> > So dependent projects can earlier react to probably breaking changes.
> >
> Keep in mind though, that many project build nightlys produce version 
> qualifiers
> that starts with 'N' and that this often break the version semantics when
> intermixed with other types of builds.
>
>  That's new to me. I thought all project should use
> X.Y.Z.vBUILD-QUALIFIER. [1]
> Thank for this info Thomas.
>
> [1] http://wiki.eclipse.org/Version_Numbering
>
>
PDE has this support for the nightlies where the fetchTag is HEAD (instead
of the qualifier in the maps), and when using the generic fetchTag the
qualifier gets set to N-

Interestingly with the switch to git, we've switched to a convention where
the qualifier in the map is the v of the last commit to
touch a given bundle/project.  That same practice could be applied to
nightlies since it is invariant with the same build input.

In the Eclipse SDK case, that still wouldn't allow easy intermingling of
types of builds as the product qualifier *is* changed on every build and in
our case would swap between N- and I-

PW


-- 
Paul Webster
Hi floor.  Make me a sammich! - GIR
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Juno M4 staging repo is done (more on respins and EPP)

[Beth Tibbitts]

Yes I agree mostly, but being an early M4 and we just got our build fixed,
I put it there and if it gets
used, easier for our testing, but no big deal if it doesn't.
Sorry for the monkey wrench.
I agree they should match.



...Beth

Beth Tibbitts
Eclipse Parallel Tools Platform  http://eclipse.org/ptp
IBM STG - High Performance Computing Tools
Mailing Address:  IBM Corp., 745 West New Circle Road, Lexington, KY 40511



  
  From:   David M Williams/Raleigh/IBM@IBMUS
  

  
  To: Cross project issues ,  
  

  
  Date:   12/15/2011 12:36 AM   
  

  
  Subject:Re: [cross-project-issues-dev] Juno M4 staging repo is done (more 
on respins and EPP)   

  
  Sent by:cross-project-issues-dev-boun...@eclipse.org  
  

  






It could be argued this is "none of my business" and entirely up to Markus
and the PTP project ... but ... I can't help myself ... and maybe my
comments will help set future expectations or processes.

The staging (and soon milestone) repo and the EPP packages are meant to
match exactly. EPP pulls from staging repo. Normally. If an exception is
required, Markus has some ways he can "hack" the normal process and do
something different on a case by case basis, but I'd think it'd be best to
mention what serious bug it is required to fix and justify the extra effort
and risks. And, in many cases, if it was that serious, it would probably
justify a respin of the common repo too. There is some risk in having them
different, least of all that users can get different things from different
sources ... some risk, not to mention that does not sound very
"coordinated" ... the whole point of a "simultaneous release train".  I
know, in the past, exceptions have been made that were considered "a bad
enough bug for EPP but not bad enough for common repo", but I'd think these
should be rare ... and justified in a bugzilla for all to read why it might
be justifiable in one case, but not another.

Don't get me wrong ... it might well be the best thing to do in this
case ... but a) should normally be rare, and b) should be explained and
linked to a specific bug.

Thanks for reading,






From:Beth Tibbitts/Watson/IBM@IBMUS
To:  Cross project issues ,
Date:12/14/2011 09:34 PM
Subject: Re: [cross-project-issues-dev] Juno M4 staging repo is
done
Sent by: cross-project-issues-dev-boun...@eclipse.org



We have a respin of PTP in place  but too late for Juno M4 repo.
I think it should make the EPP build tomorrow though.


...Beth

Beth Tibbitts
Eclipse Parallel Tools Platform  http://eclipse.org/ptp
IBM STG - High Performance Computing Tools
Mailing Address:  IBM Corp., 745 West New Circle Road, Lexington, KY 40511

Inactive hide details for David M Williams---12/14/2011 08:32:35 PM---All
did go fine and I re-promoted one more aggregation buDavid M
Williams---12/14/2011 08:32:35 PM---All did go fine and I re-promoted one
more aggregation build (the one from 6:33 started by Adolfo) a


   From:   David M Williams/Raleigh/IBM@IBMUS


   To: Cross project issues
   ,


   Date:   12/14/2011 08:32 PM


   Subject:[cross-project-issues-dev] Juno M4 staging repo is done


   Sent by:cross-project-issues-dev-boun...@eclipse.org







All did go fine and I re-promoted one more aggregation build (the one from
6:33 started by Adolfo) and since there were no other requests for "respin"
or blocking problems, we'll consider this part of M4 done. Tomorrow
(Thursday) the focus will be on EPP ... and assuming that goes fine ...
we'll make both available Friday. (usually, 9 to noonish, Eastern Time).

Thanks all ... remember, test early, test often ... oh, and remember this
time ou

Re: [cross-project-issues-dev] help with Buckminster problem needed

[Dennis Hübner]

Allow others to browse your job workspace for mdt-etrice-nightly. So we can 
also look into your rmap and cquery.
Regards,
Dennis.

Am 15.12.2011 um 12:41 schrieb Thomas Hallgren:

> Please try running with --loglevel DEBUG and then provide a link to the 
> complete build output.

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Juno M4 staging repo is done

[Adolfo Sánchez-Barbudo Herrera]

  
  
David,

Thank you very much. I've verified the proper OCL contribution in
the staging repository.

P.S: Hudson jobs are queuing again, I guess hudson-slave1 needs a
restart.

Cheers,
Adolfo.

El 15/12/2011 1:31, David M Williams escribió:

  
All did go fine and I re-promoted one more aggregation build (the one from
6:33 started by Adolfo) and since there were no other requests for "respin"
or blocking problems, we'll consider this part of M4 done. Tomorrow
(Thursday) the focus will be on EPP ... and assuming that goes fine ...
we'll make both available Friday. (usually, 9 to noonish, Eastern Time).

Thanks all ... remember, test early, test often ... oh, and remember this
time our /releases/juno repo will contain _only_ M4 (rather than a
composite of last 3) since a key bundle package went "down" in version
numbering, so that means you can start testing /releases/staging and expect
same results and behavior for final M4 repo.






From:	Adolfo Sanchez Barbudo 
To:	Cross project issues ,
Date:	12/14/2011 06:33 PM
Subject:	Re: [cross-project-issues-dev] Status and outlook near end of
M4 +3
Sent by:	cross-project-issues-dev-boun...@eclipse.org



BTW,

If all goes fine, as I expect, I'd be pleased to have the new result
promoted for packaging.

Cheers,
Adolfo.
2011/12/14 Adolfo Sanchez Barbudo 
  David,

  I have just run a build with some last bits for OCL Tools.

  Cheers,
  Adolfo.


  2011/12/14 David M Williams 


   Roll call ... I think the last aggregation build got all the latest
   changes/additions for M4, but please speak up now if your contribution
   isn't there yet.

   I promoted the latest results to /releases/staging so you can check/test
   there, if all is as expected.

   If anyone needs to contribute by 7 PM Eastern, I'd think that'd be
   containable ... after that, I'd begin to ask if better to wait to M5, or
   other more specific questions.

   Oh, and you don't really need to answer "roll call" unless there's
   problems ... like my teachers used to say "if anyone is not here, will
   you
   please speak up?"  :)


   ___
   cross-project-issues-dev mailing list
   cross-project-issues-dev@eclipse.org
   https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev




-- 
  


  

  
  
Adolfo
Sánchez-Barbudo Herrera
  adolfosbh(at)opencanarias(dot)com
  C/Elías Ramos González, 4, ofc. 304
  38001 SANTA CRUZ DE TENERIFE
  Tel.: +34 922 240231  

  

  

  

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] help with Buckminster problem needed

[Thomas Hallgren]

  
  
Hi Henrik,

It seems some of the trace is lost here so I cannot really determine
why the bundles aren't found. Please try running with --loglevel
DEBUG and then provide a link to the complete build output.

Regards,
Thomas Hallgren


On 2011-12-15 12:35, Henrik Rentz-Reichert wrote:

  
  Hi all,

I think that the experienced audience of this list might have a
clue what's going on with our Hudson eTrice build.

I had to adapt the Buckminster resource map to be able to locate
the new version of a dependency (we switched from Xtext 2.0 to
2.1).
If I perform the cquery locally everything can be resolved
properly.

However, if I run that inside Hudson I end up with
  
  ERROR   [0046] : No component named org.eclipse.emf.mwe2.runtime:osgi.bundle/2.2.0 is known to Buckminster
ERROR: No component named org.eclipse.emf.mwe2.runtime:osgi.bundle/2.2.0 is known to Buckminster
ERROR   [0047] : No component named org.eclipse.emf.mwe.core:osgi.bundle/[1.1.1.v201108020506,2.0.0) is known to Buckminster
ERROR: No component named org.eclipse.emf.mwe.core:osgi.bundle/[1.1.1.v201108020506,2.0.0) is known to Buckminster
INFO:  Resetting target platform Directory /opt/users/hudsonbuild/.hudson/jobs/mdt-etrice-nightly/workspace//buildroot/target.platform
ERROR: Errors and Warnings
org.eclipse.core.runtime.CoreException: Errors and Warnings
	at org.eclipse.buckminster.runtime.BuckminsterException.wrap(BuckminsterException.java:96)
	at org.eclipse.buckminster.core.materializer.MaterializationJob.internalRun(MaterializationJob.java:149)
	at org.eclipse.buckminster.core.materializer.MaterializationJob.run(MaterializationJob.java:125)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Contains: [0046] : No component named org.eclipse.emf.mwe2.runtime:osgi.bundle/2.2.0 is known to Buckminster
Contains: [0047] : No component named org.eclipse.emf.mwe.core:osgi.bundle/[1.1.1.v201108020506,2.0.0) is known to Buckminster


  The difference is that
the p2 Provider searches in the Hudson job in the shared file
system
/home/data/httpd/download.eclipse.org/etrice

while in my local setting I'm using
http://download.eclipse.org/etrice

Any help is appreciated,
Henrik
  -- 
..
.   ..
. Dr. Henrik Rentz-Reichert .  mailto:h...@protos.de  .
.   .  +49-7551-831365   .
.   ..
.   .  Am Bacheck 7a . 
.   .  D-88662 Überlingen-Deisendorf .
..
  

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



  


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] help with Buckminster problem needed

[Henrik Rentz-Reichert]

Hi all,

I think that the experienced audience of this list might have a clue what's 
going on with our Hudson eTrice build.

I had to adapt the Buckminster resource map to be able to locate the new 
version of a dependency (we switched from Xtext 2.0 to 2.1).
If I perform the cquery locally everything can be resolved properly.

However, if I run that inside Hudson I end up with

ERROR   [0046] : No component named 
org.eclipse.emf.mwe2.runtime:osgi.bundle/2.2.0 is known to Buckminster
ERROR: No component named org.eclipse.emf.mwe2.runtime:osgi.bundle/2.2.0 is 
known to Buckminster
ERROR   [0047] : No component named 
org.eclipse.emf.mwe.core:osgi.bundle/[1.1.1.v201108020506,2.0.0) is known to 
Buckminster
ERROR: No component named 
org.eclipse.emf.mwe.core:osgi.bundle/[1.1.1.v201108020506,2.0.0) is known to 
Buckminster
INFO:  Resetting target platform Directory 
/opt/users/hudsonbuild/.hudson/jobs/mdt-etrice-nightly/workspace//buildroot/target.platform
ERROR: Errors and Warnings
org.eclipse.core.runtime.CoreException: Errors and Warnings
at 
org.eclipse.buckminster.runtime.BuckminsterException.wrap(BuckminsterException.java:96)
at 
org.eclipse.buckminster.core.materializer.MaterializationJob.internalRun(MaterializationJob.java:149)
at 
org.eclipse.buckminster.core.materializer.MaterializationJob.run(MaterializationJob.java:125)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Contains: [0046] : No component named 
org.eclipse.emf.mwe2.runtime:osgi.bundle/2.2.0 is known to Buckminster
Contains: [0047] : No component named 
org.eclipse.emf.mwe.core:osgi.bundle/[1.1.1.v201108020506,2.0.0) is known to 
Buckminster


The difference is that the p2 Provider searches in the Hudson job in the shared 
file system
/home/data/httpd/download.eclipse.org/etrice

while in my local setting I'm using
http://download.eclipse.org/etrice

Any help is appreciated,
Henrik

-- 
..
.   ..
. Dr. Henrik Rentz-Reichert .  mailto:h...@protos.de  .
.   .  +49-7551-831365   .
.   ..
.   .  Am Bacheck 7a . 
.   .  D-88662 Überlingen-Deisendorf .
..

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev