Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Buckminster » Problems installing headless buckminster 3.6
Problems installing headless buckminster 3.6 [message #489852] Tue, 06 October 2009 08:58 Go to next message
Johannes Utzig is currently offline Johannes UtzigFriend
Messages: 329
Registered: July 2009
Senior Member
Hi,

I'm still struggeling to get the helios builds of buckminster running to
try out the JUnit support.
I can install the core feature from the update site, but for all others
I get this error:
../buckminster --loglevel debug install
http://download.eclipse.org/tools/buckminster/headless-3.6
org.eclipse.buckminster.cvs.headless.feature
install 'http://download.eclipse.org/tools/buckminster/headless-3.6'
'org.eclipse.buckminster.cvs.headless.feature'
An error occurred while installing the items
[0]session context was:(profile=Buckminster,
phase=org.eclipse.equinox.internal.provisional.p2.engine.pha ses.Install,
operand=null --> [R]org.eclipse.buckminster.cvs 1.0.350.r10356,
action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.ac tions.InstallBundleAction).
[0]Error while loading manipulator.
Caused by:

Any ideas on this one?

Best regards,
Johannes
Re: Problems installing headless buckminster 3.6 [message #489884 is a reply to message #489852] Tue, 06 October 2009 12:11 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
I have seen this happen as a consequence of installing buckminster using a relative destination path. I.e.

director -d ../some/path

Could that be it?

Regards,
Thomas Hallgren


On 10/06/2009 10:58 AM, Johannes Utzig wrote:
> Hi,
>
> I'm still struggeling to get the helios builds of buckminster running to
> try out the JUnit support.
> I can install the core feature from the update site, but for all others
> I get this error:
> ./buckminster --loglevel debug install
> http://download.eclipse.org/tools/buckminster/headless-3.6
> org.eclipse.buckminster.cvs.headless.feature
> install 'http://download.eclipse.org/tools/buckminster/headless-3.6'
> 'org.eclipse.buckminster.cvs.headless.feature'
> An error occurred while installing the items
> [0]session context was:(profile=Buckminster,
> phase=org.eclipse.equinox.internal.provisional.p2.engine.pha ses.Install,
> operand=null --> [R]org.eclipse.buckminster.cvs 1.0.350.r10356,
> action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.ac tions.InstallBundleAction).
>
> [0]Error while loading manipulator.
> Caused by:
>
> Any ideas on this one?
>
> Best regards,
> Johannes
Re: Problems installing headless buckminster 3.6 [message #489923 is a reply to message #489884] Tue, 06 October 2009 13:32 Go to previous messageGo to next message
Johannes Utzig is currently offline Johannes UtzigFriend
Messages: 329
Registered: July 2009
Senior Member
Hi Thomas,

once more you've safed my day, thank you very much :)
The unit tests are running like a charm now, so that's great.
Unfortunately the output.xml doesn't seem to be parsable by Hudsons'
JUnit Publisher. I'll try to figure out what the problem with the xml
structure is and give feedback in bugzilla on that.

Best regards,
Johannes

Thomas Hallgren schrieb:
> I have seen this happen as a consequence of installing buckminster using
> a relative destination path. I.e.
>
> director -d ../some/path
>
> Could that be it?
>
> Regards,
> Thomas Hallgren
>
>
> On 10/06/2009 10:58 AM, Johannes Utzig wrote:
>> Hi,
>>
>> I'm still struggeling to get the helios builds of buckminster running to
>> try out the JUnit support.
>> I can install the core feature from the update site, but for all others
>> I get this error:
>> ./buckminster --loglevel debug install
>> http://download.eclipse.org/tools/buckminster/headless-3.6
>> org.eclipse.buckminster.cvs.headless.feature
>> install 'http://download.eclipse.org/tools/buckminster/headless-3.6'
>> 'org.eclipse.buckminster.cvs.headless.feature'
>> An error occurred while installing the items
>> [0]session context was:(profile=Buckminster,
>> phase=org.eclipse.equinox.internal.provisional.p2.engine.pha ses.Install,
>> operand=null --> [R]org.eclipse.buckminster.cvs 1.0.350.r10356,
>> action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.ac tions.InstallBundleAction).
>>
>>
>> [0]Error while loading manipulator.
>> Caused by:
>>
>> Any ideas on this one?
>>
>> Best regards,
>> Johannes
>
Re: Problems installing headless buckminster 3.6 [message #489950 is a reply to message #489923] Tue, 06 October 2009 15:04 Go to previous messageGo to next message
Johannes Utzig is currently offline Johannes UtzigFriend
Messages: 329
Registered: July 2009
Senior Member
Johannes Utzig schrieb:
> Hi Thomas,
>
> once more you've safed my day, thank you very much :)
> The unit tests are running like a charm now, so that's great.
> Unfortunately the output.xml doesn't seem to be parsable by Hudsons'
> JUnit Publisher. I'll try to figure out what the problem with the xml
> structure is and give feedback in bugzilla on that.
>
> Best regards,
> Johannes
>

Initially I had nested test suites and it looks like they caused the
trouble in hudson. Now I'm not sure if this is a problem with the hudson
code, or the XML format, I need some more investigation to find out.
So far, I simply removed my suites and used a launch configuration that
executes all tests in a project. The results of this execution work
perfectly fine in hudson.
Fantastic job on the junit support!

Best regards,
Johannes
Re: Problems installing headless buckminster 3.6 [message #489973 is a reply to message #489950] Tue, 06 October 2009 16:47 Go to previous messageGo to next message
Achim Demelt is currently offline Achim DemeltFriend
Messages: 160
Registered: July 2009
Senior Member
Johannes,

I'd appreciate any feedback concerning the parsing of XML output files in
Hudson. As a matter of fact, there is no XSD or any other normative
description of how a JUnit XML file ought to look like. In particular, I had
trouble parsing Eclipse's XML output with Bamboo, so I had to write my own
XML serializer for the Buckminster JUnit command. This output parses fine
with Bamboo and Sonar, but I have no access to Hudson so I cannot test this
scenario.

If you can supply some working and non-working examples, I can try to infer
a structure that can be parsed by both Hudson and Bamboo. Please open a new
bug for that so we can track progress on this topic for M3.

Thanks,
Achim

Johannes Utzig wrote:

> Johannes Utzig schrieb:
>> Hi Thomas,
>>
>> once more you've safed my day, thank you very much :)
>> The unit tests are running like a charm now, so that's great.
>> Unfortunately the output.xml doesn't seem to be parsable by Hudsons'
>> JUnit Publisher. I'll try to figure out what the problem with the xml
>> structure is and give feedback in bugzilla on that.
>>
>> Best regards,
>> Johannes
>>
>
> Initially I had nested test suites and it looks like they caused the
> trouble in hudson. Now I'm not sure if this is a problem with the hudson
> code, or the XML format, I need some more investigation to find out.
> So far, I simply removed my suites and used a launch configuration that
> executes all tests in a project. The results of this execution work
> perfectly fine in hudson.
> Fantastic job on the junit support!
>
> Best regards,
> Johannes
Re: Problems installing headless buckminster 3.6 [message #489984 is a reply to message #489973] Tue, 06 October 2009 18:07 Go to previous messageGo to next message
Johannes Utzig is currently offline Johannes UtzigFriend
Messages: 329
Registered: July 2009
Senior Member
Hi Achim,

please see comments inline

Achim Demelt schrieb:
> Johannes,
>
> I'd appreciate any feedback concerning the parsing of XML output files in
> Hudson. As a matter of fact, there is no XSD or any other normative
> description of how a JUnit XML file ought to look like. In particular, I had
> trouble parsing Eclipse's XML output with Bamboo, so I had to write my own
> XML serializer for the Buckminster JUnit command. This output parses fine
> with Bamboo and Sonar, but I have no access to Hudson so I cannot test this
> scenario.
>

Yes, I am aware of that. It's really weird that everybody seems to parse
the XML reports but nobody bothers to specify their format in a schema.

> If you can supply some working and non-working examples, I can try to infer
> a structure that can be parsed by both Hudson and Bamboo. Please open a new
> bug for that so we can track progress on this topic for M3.
>

Yes, that's what I am planning to do for the hudson Part.
I'll try some examples with nested test suites and hope to find out what
works for hudson and what doesn't.
I'll definetly get back to you in bugzilla if I can produce some good
working + non-working examples.

I absolutely love what you've done with the Junit support, it's so much
easier to provide good unit testing for PlugIn projects now.
Now I'm excited about the Emma support you promised :D
How much work would you expect if I'd like to add Cobertura support the
same way you're currently supporting Emma?

Best regards,
Johannes
Re: Problems installing headless buckminster 3.6 [message #490557 is a reply to message #489984] Fri, 09 October 2009 07:59 Go to previous messageGo to next message
Achim Demelt is currently offline Achim DemeltFriend
Messages: 160
Registered: July 2009
Senior Member
Hi Johannes,

Thanks for the kudos! Funny thing is that most of the work went into
refactoring JDT and PDE. The actual Buckminster JUnit integration work was
pretty much straightforward. Integrating EclEmma, then, was a walk in the
park, for two reasons:

1) EclEmma uses the regular Eclipse launching facilities to perform coverage
analysis.
2) Its code base is extremely well written and clearly separates between
launching code and UI code.

If Cobertura is similar in these two respects, integrating it in Buckminster
can be done in a couple of hours.

Regarding the availability of the Emma integration: the code is ready, but
we're still waiting for CQ approval to include the EclEmma bundle in our
repository. I don't know if Thomas found time to integrate the Buckminster
Emma feature in the Cloudsmith update site.

Cheers,
Achim

Johannes Utzig wrote:

> Hi Achim,
>
> please see comments inline
>
> Achim Demelt schrieb:
>> Johannes,
>>
>> I'd appreciate any feedback concerning the parsing of XML output files in
>> Hudson. As a matter of fact, there is no XSD or any other normative
>> description of how a JUnit XML file ought to look like. In particular, I
>> had trouble parsing Eclipse's XML output with Bamboo, so I had to write
>> my own XML serializer for the Buckminster JUnit command. This output
>> parses fine with Bamboo and Sonar, but I have no access to Hudson so I
>> cannot test this scenario.
>>
>
> Yes, I am aware of that. It's really weird that everybody seems to parse
> the XML reports but nobody bothers to specify their format in a schema.
>
>> If you can supply some working and non-working examples, I can try to
>> infer a structure that can be parsed by both Hudson and Bamboo. Please
>> open a new bug for that so we can track progress on this topic for M3.
>>
>
> Yes, that's what I am planning to do for the hudson Part.
> I'll try some examples with nested test suites and hope to find out what
> works for hudson and what doesn't.
> I'll definetly get back to you in bugzilla if I can produce some good
> working + non-working examples.
>
> I absolutely love what you've done with the Junit support, it's so much
> easier to provide good unit testing for PlugIn projects now.
> Now I'm excited about the Emma support you promised :D
> How much work would you expect if I'd like to add Cobertura support the
> same way you're currently supporting Emma?
>
> Best regards,
> Johannes
Re: Problems installing headless buckminster 3.6 [message #490564 is a reply to message #490557] Fri, 09 October 2009 08:16 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi Achim,
What dependencies will EclEmma introduce? Is it independent on the other work that you've made that in turn requires
3.6? The reason I ask is that if EclEmma is free-standing in the sense that it is installable into a 3.5 installation,
then it's just a matter of adding it to the external site. If that's not the case however, then we need a special
external site for 3.6.

If it's the simple case, then I suggest you just add what's needed to the org.eclipse.buckminster.site.external feature
and then ping me. I'll publish it.

Regards,
Thomas Hallgren



On 10/09/2009 09:59 AM, Achim Demelt wrote:
> Regarding the availability of the Emma integration: the code is ready, but
> we're still waiting for CQ approval to include the EclEmma bundle in our
> repository. I don't know if Thomas found time to integrate the Buckminster
> Emma feature in the Cloudsmith update site.
>
> Cheers,
> Achim
>
Re: Problems installing headless buckminster 3.6 [message #491649 is a reply to message #489973] Thu, 15 October 2009 11:45 Go to previous messageGo to next message
Johannes Utzig is currently offline Johannes UtzigFriend
Messages: 329
Registered: July 2009
Senior Member
Achim Demelt schrieb:
> Johannes,
>
> I'd appreciate any feedback concerning the parsing of XML output files in
> Hudson. As a matter of fact, there is no XSD or any other normative
> description of how a JUnit XML file ought to look like. In particular, I had
> trouble parsing Eclipse's XML output with Bamboo, so I had to write my own
> XML serializer for the Buckminster JUnit command. This output parses fine
> with Bamboo and Sonar, but I have no access to Hudson so I cannot test this
> scenario.
>
> If you can supply some working and non-working examples, I can try to infer
> a structure that can be parsed by both Hudson and Bamboo. Please open a new
> bug for that so we can track progress on this topic for M3.
>


Hi Achim,

I did some more tests and my root problem was indeed that the Hudson
reporter isn't able to handle nested testsuites. It expects one top
level <testsuites> with a flat list of <testsuite>.

See here:
https://hudson.dev.java.net/nonav/issues/show_bug.cgi?id=300 7

My current solution is to use the python script attached to this issue
to flatten the results.
So what do you think, should it be possible to add a --flatten parameter
to the junit command to achive the same without additional script, or
should the output stay like this since they are working on nested suites
in hudson already?

I also had 2 other issues and reported bugs for those:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=292376
https://bugs.eclipse.org/bugs/show_bug.cgi?id=292380


Best regards,
Johannes
Re: Problems installing headless buckminster 3.6 [message #491890 is a reply to message #491649] Fri, 16 October 2009 12:36 Go to previous messageGo to next message
Achim Demelt is currently offline Achim DemeltFriend
Messages: 160
Registered: July 2009
Senior Member
Johannes,

comments below.

Johannes Utzig wrote:

> Achim Demelt schrieb:
>> Johannes,
>>
>> I'd appreciate any feedback concerning the parsing of XML output files in
>> Hudson. As a matter of fact, there is no XSD or any other normative
>> description of how a JUnit XML file ought to look like. In particular, I
>> had trouble parsing Eclipse's XML output with Bamboo, so I had to write
>> my own XML serializer for the Buckminster JUnit command. This output
>> parses fine with Bamboo and Sonar, but I have no access to Hudson so I
>> cannot test this scenario.
>>
>> If you can supply some working and non-working examples, I can try to
>> infer a structure that can be parsed by both Hudson and Bamboo. Please
>> open a new bug for that so we can track progress on this topic for M3.
>>
>
>
> Hi Achim,
>
> I did some more tests and my root problem was indeed that the Hudson
> reporter isn't able to handle nested testsuites. It expects one top
> level <testsuites> with a flat list of <testsuite>.
>
> See here:
> https://hudson.dev.java.net/nonav/issues/show_bug.cgi?id=300 7
>
> My current solution is to use the python script attached to this issue
> to flatten the results.
> So what do you think, should it be possible to add a --flatten parameter
> to the junit command to achive the same without additional script, or
> should the output stay like this since they are working on nested suites
> in hudson already?
>

I'd rather not invent a new "--flatten" parameter when I know that it will
be obsolete in the foreseeable future. The python script attached to the
Hudson bug should provide a workaround for all users currently suffering
from this shortcoming.

> I also had 2 other issues and reported bugs for those:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=292376
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=292380
>
>

Thanks for those. I'll work on fixes over the weekend.

Cheers,
Achim

> Best regards,
> Johannes
Re: Problems installing headless buckminster 3.6 [message #491891 is a reply to message #490564] Fri, 16 October 2009 12:43 Go to previous messageGo to next message
Achim Demelt is currently offline Achim DemeltFriend
Messages: 160
Registered: July 2009
Senior Member
Thomas,

sorry for the late reply. My first response obviously got lost in a broken
mobile broadband connection on the train.

The EclEmma support builds upon the launching and JUnit support we
introduced with 3.6. So I don't see any way to integrate it in a 3.5
installation.

That said, we should still be able to publish the Buckminster Emma feature
on the (3.5) external repository. The dependency declarations should prevent
anyone from installing the feature in a 3.5 environment. Or do you think
this is too risky?

Cheers,
Achim

Thomas Hallgren wrote:

> Hi Achim,
> What dependencies will EclEmma introduce? Is it independent on the other
> work that you've made that in turn requires 3.6? The reason I ask is that
> if EclEmma is free-standing in the sense that it is installable into a 3.5
> installation, then it's just a matter of adding it to the external site.
> If that's not the case however, then we need a special external site for
> 3.6.
>
> If it's the simple case, then I suggest you just add what's needed to the
> org.eclipse.buckminster.site.external feature and then ping me. I'll
> publish it.
>
> Regards,
> Thomas Hallgren
>
>
>
> On 10/09/2009 09:59 AM, Achim Demelt wrote:
>> Regarding the availability of the Emma integration: the code is ready,
>> but we're still waiting for CQ approval to include the EclEmma bundle in
>> our repository. I don't know if Thomas found time to integrate the
>> Buckminster Emma feature in the Cloudsmith update site.
>>
>> Cheers,
>> Achim
>>
Re: configure hudson to digest xml test results with deeply nested testsuites [message #501970 is a reply to message #491649] Fri, 04 December 2009 15:54 Go to previous messageGo to next message
Joerg Buchberger is currently offline Joerg BuchbergerFriend
Messages: 46
Registered: July 2009
Member
Hi, just for the record.

I had faced the same problem. Luckily, there is the Hudson xUnit plugin ( http://wiki.hudson-ci.org/display/HUDSON/xUnit+Plugin ).

Once installed into your hudson, you can opt in Publish testing tools result report for your build job.

Here you can add a Custom Tool, which allows you to specify an XSL stylesheet. This one did the trick for me (and BTW it also sums up the execution times to calculate the total).
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template name="sumoftime">
  <xsl:param name="node"/>
  <xsl:param name="sum" />
  <xsl:choose>
    <xsl:when test="$node">
      <xsl:call-template name="sumoftime">
        <xsl:with-param name="node" select="$node/following-sibling::testcase[1]"/>
        <xsl:with-param name="sum" select="$sum + number(translate($node/@time, ',', ''))"/>
      </xsl:call-template>
    </xsl:when>
    <xsl:otherwise>
      <xsl:value-of select="$sum"/>
    </xsl:otherwise>
  </xsl:choose>
</xsl:template>
<xsl:template match="/">
  <xsl:element name="testsuite">
    <xsl:attribute name="{'time'}">
      <xsl:call-template name="sumoftime">
        <xsl:with-param name="node" select="testcase[1]"/>
        <xsl:with-param name="sum" select="0" />
      </xsl:call-template>
    </xsl:attribute>
    <xsl:attribute name="{'failures'}">
      <xsl:value-of select="count(/testsuite/testsuite/testsuite/testcase/failure)"/>
    </xsl:attribute>
    <xsl:attribute name="{'errors'}">
      <xsl:value-of select="count(/testsuite/testsuite/testsuite/testcase/failure)"/>
    </xsl:attribute>
    <xsl:attribute name="{'tests'}">
      <xsl:value-of select="count(/testsuite/testsuite/testsuite/testcase)"/>
    </xsl:attribute>
    <xsl:for-each select="//testsuite/testsuite/testsuite/testcase[not(@incomplete)]">
      <xsl:copy-of select="." />
    </xsl:for-each>
  </xsl:element>
</xsl:template>
</xsl:stylesheet>


Cheers.
Joerg



Johannes Utzig wrote on Thu, 15 October 2009 07:45
Achim Demelt schrieb:
> Johannes,
>
> I'd appreciate any feedback concerning the parsing of XML output files in
> Hudson. As a matter of fact, there is no XSD or any other normative
> description of how a JUnit XML file ought to look like. In particular, I had
> trouble parsing Eclipse's XML output with Bamboo, so I had to write my own
> XML serializer for the Buckminster JUnit command. This output parses fine
> with Bamboo and Sonar, but I have no access to Hudson so I cannot test this
> scenario.
>
> If you can supply some working and non-working examples, I can try to infer
> a structure that can be parsed by both Hudson and Bamboo. Please open a new
> bug for that so we can track progress on this topic for M3.
>


Hi Achim,

I did some more tests and my root problem was indeed that the Hudson
reporter isn't able to handle nested testsuites. It expects one top
level <testsuites> with a flat list of <testsuite>.

Re: Problems installing headless buckminster 3.6 [message #503250 is a reply to message #489884] Fri, 11 December 2009 10:28 Go to previous messageGo to next message
John is currently offline JohnFriend
Messages: 107
Registered: July 2009
Senior Member
Hi!

Thomas Hallgren wrote on Tue, 06 October 2009 08:11
I have seen this happen as a consequence of installing buckminster using a relative destination path. I.e.

director -d ../some/path

Could that be it?

Regards,
Thomas Hallgren



This is also a known problem with 3.5.
Is it a general problem with p2 and do you know if it's going to be fixed?

The reason I ask, is that I installed Buckminster 3.5 on my USB stick, which happens to be the d: drive.
I then copied it to my laptops c: drive. It runs fine, but when I try to use an import action on a custom builder,
it fails because it expects to find the artifacts.xml in the original location on the d: drive.

This makes me worry, since this means I need to install Buckminster on my c: drive in in a folder,
and then on my CI server copy the Buckminster installation to the exact same drive and path location.
This is necessary since we regularly check for updates to this custom builder and it will obviously fail
if the installation path doesn't match the original.

This isn't a problem with our current 3.4 version of Buckminster and it's a serious change of behavior.

So, do you know if it's going to be fixed or should I report it in Bugzilla?


/John
Re: Problems installing headless buckminster 3.6 [message #503352 is a reply to message #503250] Sat, 12 December 2009 02:52 Go to previous messageGo to next message
Henrik Lindberg is currently offline Henrik LindbergFriend
Messages: 2509
Registered: July 2009
Senior Member
There is an option when installing something that makes the install
relocateable. It is called "roaming".
- henrik

John <john.lindgreen@gmail.com> wrote:
> Hi!
>
> Thomas Hallgren wrote on Tue, 06 October 2009 08:11
> > I have seen this happen as a consequence of installing buckminster
> > using a relative destination path. I.e.
> >
> > director -d ../some/path
> >
> > Could that be it?
> >
> > Regards,
> > Thomas Hallgren
>
>
> This is also a known problem with 3.5.
> Is it a general problem with p2 and do you know if it's going to be
> fixed?
>
> The reason I ask, is that I installed Buckminster 3.5 on my USB stick,
> which happens to be the d: drive.
> I then copied it to my laptops c: drive. It runs fine, but when I try
> to use an import action on a custom builder,
> it fails because it expects to find the artifacts.xml in the original
> location on the d: drive.
>
> This makes me worry, since this means I need to install Buckminster on
> my c: drive in in a folder,
> and then on my CI server copy the Buckminster installation to the
> exact same drive and path location.
> This is necessary since we regularly check for updates to this custom
> builder and it will obviously fail
> if the installation path doesn't match the original.
>
> This isn't a problem with our current 3.4 version of Buckminster and
> it's a serious change of behavior.
>
> So, do you know if it's going to be fixed or should I report it in
> Bugzilla?
>
>
> /John


--
- henrik
Re: Problems installing headless buckminster 3.6 [message #508522 is a reply to message #503352] Tue, 19 January 2010 10:14 Go to previous messageGo to next message
John is currently offline JohnFriend
Messages: 107
Registered: July 2009
Senior Member
Thanks, Henrik!


Unfortunately this doesn't seem to work for me.

I've downloaded the director and then installed Buckminster to my USB drive using the following command:

director -r http://download.eclipse.org/tools/buckminster/headless-3.5/ -d e:\temp\bm35\buckminster -p Buckminster -i org.eclipse.buckminster.cmdline.product -roaming

Then I install some more Buckminster plugins using:

install http://download.eclipse.org/tools/buckminster/headless-3.5/ org.eclipse.buckminster.core.headless.feature
install http://download.eclipse.org/tools/buckminster/headless-3.5/ org.eclipse.buckminster.maven.feature
install http://download.eclipse.org/tools/buckminster/headless-3.5/ org.eclipse.buckminster.pde.headless.feature

Then I have moved the buckminster installation to C:\Temp\bm-home\buckminster

Now, when I try to install out own plugin into this installtion using an install command like the one above, I get the following error:

INFO: install 'http://myserver/mysite' 'my.company.myfeature'
java.io.FileNotFoundException: e:\temp\bm35\buckminster\artifacts.xml (The system cannot find the path specified)

So, even if I installed Buckminster using the -roaming option with the director command, it still doesn't work installing after it has been moved to another location.

The documentation for the -roaming option says:

-roaming
Indicates that the product resulting from the installation can be moved. Effective only when a new profile is created.

Am I doing something wrong or is there another explanation?

Thanks in advance.


/John
Re: Problems installing headless buckminster 3.6 [message #509843 is a reply to message #508522] Mon, 25 January 2010 15:22 Go to previous messageGo to next message
John is currently offline JohnFriend
Messages: 107
Registered: July 2009
Senior Member
Hi!


Can anybody provide some help with this?

I have made some more research on this and have found the following dependencies to the install dir in the installation without using the -roaming option:

In the file <installdir>\configuration\config.ini is

eclipse.p2.data.area=file\:/C\:/Temp/bm35/buckminster/config uration/../p2/

In the file <installdir> \p2\org.eclipse.equinox.p2.engine\.settings\org.eclipse.equi nox.p2.artifact.repository.prefs is

repositories/file\:_c\:_temp_bm35_buckminster/uri=file\:/c\: /temp/bm35/buckminster/

and

repositories/file\:_c\:_temp_bm35_buckminster_p2_org.eclipse .equinox.p2.core_cache/uri=file\:/c\:/temp/bm35/buckminster/ p2/org.eclipse.equinox.p2.core/cache/

Finally in the file <installdir> \p2\org.eclipse.equinox.p2.engine\profileRegistry\Buckminste r.profile\.data\.settings\org.eclipse.equinox.p2.artifact.re pository.prefs is

repositories/file\:_c\:_temp_bm35_buckminster/uri=file\:/c\: /temp/bm35/buckminster/

and

repositories/file\:_C\:_Temp_bm35_buckminster_p2_org.eclipse .equinox.p2.core_cache/uri=file\:/C\:/Temp/bm35/buckminster/ p2/org.eclipse.equinox.p2.core/cache/


Now, if I instead install using the -roaming option I get the following:

In the file <installdir>\configuration\config.ini is

eclipse.p2.data.area=@config.dir/../p2/

So there is no longer a reference to the original installation directory. Great!

However, the other four occurences in the two prefs files are still there.

Could this be the cause of my problem?

Does anybody have a suggestion how to avoid it?


Thanks.


/John
Re: Problems installing headless buckminster 3.6 [message #509972 is a reply to message #509843] Mon, 25 January 2010 22:39 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi John,
I think your initial install uses a '..' notation somewhere in the URL. That leads to problems further on. Please use an
absolute path for the first install.

Regards,
Thomas Hallgren

On 01/25/2010 04:22 PM, John wrote:
> Hi!
>
>
> Can anybody provide some help with this?
>
> I have made some more research on this and have found the following
> dependencies to the install dir in the installation without using the
> -roaming option:
>
> In the file <installdir>\configuration\config.ini is
>
> eclipse.p2.data.area=file\:/C\:/Temp/bm35/buckminster/config uration/../p2/
>
> In the file <installdir>
> \p2\org.eclipse.equinox.p2.engine\.settings\org.eclipse.equi
> nox.p2.artifact.repository.prefs is
>
> repositories/file\:_c\:_temp_bm35_buckminster/uri=file\:/c\:
> /temp/bm35/buckminster/
>
> and
>
> repositories/file\:_c\:_temp_bm35_buckminster_p2_org.eclipse
> .equinox.p2.core_cache/uri=file\:/c\:/temp/bm35/buckminster/
> p2/org.eclipse.equinox.p2.core/cache/
>
> Finally in the file <installdir>
> \p2\org.eclipse.equinox.p2.engine\profileRegistry\Buckminste
> r.profile\.data\.settings\org.eclipse.equinox.p2.artifact.re
> pository.prefs is
>
> repositories/file\:_c\:_temp_bm35_buckminster/uri=file\:/c\:
> /temp/bm35/buckminster/
>
> and
>
> repositories/file\:_C\:_Temp_bm35_buckminster_p2_org.eclipse
> .equinox.p2.core_cache/uri=file\:/C\:/Temp/bm35/buckminster/
> p2/org.eclipse.equinox.p2.core/cache/
>
>
> Now, if I instead install using the -roaming option I get the following:
>
> In the file <installdir>\configuration\config.ini is
>
> eclipse.p2.data.area=@config.dir/../p2/
>
> So there is no longer a reference to the original installation
> directory. Great!
>
> However, the other four occurences in the two prefs files are still there.
>
> Could this be the cause of my problem?
>
> Does anybody have a suggestion how to avoid it?
>
>
> Thanks.
>
>
> /John
Re: Problems installing headless buckminster 3.6 [message #509974 is a reply to message #509972] Mon, 25 January 2010 22:54 Go to previous messageGo to next message
John is currently offline JohnFriend
Messages: 107
Registered: July 2009
Senior Member
Hi Thomas!


Thanks for the reply.

My full install script is outlined in my post from the 19th.
For the install where my findings is from I used:


director -r http://download.eclipse.org/tools/buckminster/headless-3.5/ -d c:\temp\bm35-home\buckminster -p Buckminster -i org.eclipse.buckminster.cmdline.product -roaming

So I do use an absolute path. There must be another reason.


/John.
Re: Problems installing headless buckminster 3.6 [message #509981 is a reply to message #509974] Mon, 25 January 2010 19:14 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi John,
Sorry, I got stuck on the '..' in the data area and thought it was another problem.

- thomas


On 01/25/2010 11:54 PM, John wrote:
> Hi Thomas!
>
>
> Thanks for the reply.
>
> My full install script is outlined in my post from the 19th.
> For the install where my findings is from I used:
>
>
> director -r http://download.eclipse.org/tools/buckminster/headless-3.5/
> -d c:\temp\bm35-home\buckminster -p Buckminster -i
> org.eclipse.buckminster.cmdline.product -roaming
>
> So I do use an absolute path. There must be another reason.
>
>
> /John.
Re: Problems installing headless buckminster 3.6 [message #509982 is a reply to message #508522] Mon, 25 January 2010 19:14 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Do you get the same problem if you install everything with the director? I.e.

director -r http://download.eclipse.org/tools/buckminster/headless-3.5/
-d e:\temp\bm35\buckminster -p Buckminster
-i org.eclipse.buckminster.cmdline.product
-i org.eclipse.buckminster.core.headless.feature.feature.group
-i org.eclipse.buckminster.maven.feature.feature.group
-i org.eclipse.buckminster.pde.headless.feature
-roaming

The reason I ask is that if you still have the same problem then that will help us narrow down the problem domain a bit.

- thomas


On 01/19/2010 11:14 AM, John wrote:
> Thanks, Henrik!
>
>
> Unfortunately this doesn't seem to work for me.
>
> I've downloaded the director and then installed Buckminster to my USB
> drive using the following command:
>
> director -r http://download.eclipse.org/tools/buckminster/headless-3.5/
> -d e:\temp\bm35\buckminster -p Buckminster -i
> org.eclipse.buckminster.cmdline.product -roaming
>
> Then I install some more Buckminster plugins using:
>
> install http://download.eclipse.org/tools/buckminster/headless-3.5/
> org.eclipse.buckminster.core.headless.feature
> install http://download.eclipse.org/tools/buckminster/headless-3.5/
> org.eclipse.buckminster.maven.feature
> install http://download.eclipse.org/tools/buckminster/headless-3.5/
> org.eclipse.buckminster.pde.headless.feature
>
> Then I have moved the buckminster installation to
> C:\Temp\bm-home\buckminster
>
> Now, when I try to install out own plugin into this installtion using an
> install command like the one above, I get the following error:
>
> INFO: install 'http://myserver/mysite' 'my.company.myfeature'
> java.io.FileNotFoundException: e:\temp\bm35\buckminster\artifacts.xml
> (The system cannot find the path specified)
>
> So, even if I installed Buckminster using the -roaming option with the
> director command, it still doesn't work installing after it has been
> moved to another location.
>
> The documentation for the -roaming option says:
>
> -roaming
> Indicates that the product resulting from the installation can be moved.
> Effective only when a new profile is created.
>
> Am I doing something wrong or is there another explanation?
>
> Thanks in advance.
>
>
> /John
Re: Problems installing headless buckminster 3.6 [message #510665 is a reply to message #509982] Thu, 28 January 2010 10:01 Go to previous messageGo to next message
John is currently offline JohnFriend
Messages: 107
Registered: July 2009
Senior Member
Hi Thomas!


Thanks for the suggestion. I tried it out like this:

director -r http://download.eclipse.org/tools/buckminster/headless-3.5/
-d e:\temp\bm35-home\buckminster -p Buckminster
-i org.eclipse.buckminster.cmdline.product
-i org.eclipse.buckminster.core.headless.feature.feature.group
-i org.eclipse.buckminster.maven.feature.feature.group
-i org.eclipse.buckminster.pde.headless.feature.feature.group
-roaming

Unfortunately this doesn't make it work. However, there is a difference. First of all, if I take a fresh director_latest.zip, unzips it and run the director command with any number of -i arguments, I get the file:

director\p2\org.eclipse.equinox.p2.engine\.settings\org.ecli pse.equinox.p2.artifact.repository.prefs

and it has references to the install dir specified by the -d option. So in some sense the director installtion gets "polluted". It's almost like Highlander: "There can only be one" (use of the director) Smile. Unless, of course, it doesn't have any influnence at all.

Second, after having executed the director I have the file:

E:\temp\bm35-home\buckminster\p2\org.eclipse.equinox.p2.engi ne\.settings\org.eclipse.equinox.p2.artifact.repository.pref s

with references to the install dir.

Then, if I use my current approach of installing Buckminster features using Buckminster commands like:

install http://download.eclipse.org/tools/buckminster/headless-3.5/ org.eclipse.buckminster.core.headless.feature

then I also get the file:

E:\temp\bm35-home\buckminster\p2\org.eclipse.equinox.p2.engi ne\profileRegistry\Buckminster.profile\.data\.settings\org.e clipse.equinox.p2.artifact.repository.prefs

with references to the install dir.

However, if I just install everything with the director, I don't get this file in the profile.

So I don't know if we're closer to finding the cause of the problem, but it still only works installing plugins from our update site, if the Buckminster installation is in the same path as it was, when I first installed it with the director.

Do you have other ideas?

Thanks.


/John
Re: Problems installing headless buckminster 3.6 [message #510676 is a reply to message #510665] Thu, 28 January 2010 05:28 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi John,
Well, at least I know that Buckminster isn't the culprit. I'll bring this up with my collegues on the p2 team and I
promise I'll get back to you as soon as I have some relevant info.

Regards,
Thomas Hallgren

On 01/28/2010 11:01 AM, John wrote:
> Hi Thomas!
>
>
> Thanks for the suggestion. I tried it out like this:
>
> director -r http://download.eclipse.org/tools/buckminster/headless-3.5/
> -d e:\temp\bm35-home\buckminster -p Buckminster
> -i org.eclipse.buckminster.cmdline.product
> -i org.eclipse.buckminster.core.headless.feature.feature.group
> -i org.eclipse.buckminster.maven.feature.feature.group
> -i org.eclipse.buckminster.pde.headless.feature.feature.group
> -roaming
>
> Unfortunately this doesn't make it work. However, there is a difference.
> First of all, if I take a fresh director_latest.zip, unzips it and run
> the director command with any number of -i arguments, I get the file:
>
> director\p2\org.eclipse.equinox.p2.engine\.settings\org.ecli
> pse.equinox.p2.artifact.repository.prefs
>
> and it has references to the install dir specified by the -d option. So
> in some sense the director installtion gets "polluted". It's almost like
> Highlander: "There can only be one" (use of the director) :). Unless, of
> course, it doesn't have any influnence at all.
>
> Second, after having executed the director I have the file:
>
> E:\temp\bm35-home\buckminster\p2\org.eclipse.equinox.p2.engi
> ne\.settings\org.eclipse.equinox.p2.artifact.repository.pref s
>
> with references to the install dir.
>
> Then, if I use my current approach of installing Buckminster features
> using Buckminster commands like:
>
> install http://download.eclipse.org/tools/buckminster/headless-3.5/
> org.eclipse.buckminster.core.headless.feature
>
> then I also get the file:
>
> E:\temp\bm35-home\buckminster\p2\org.eclipse.equinox.p2.engi
> ne\profileRegistry\Buckminster.profile\.data\.settings\org.e
> clipse.equinox.p2.artifact.repository.prefs
>
> with references to the install dir.
>
> However, if I just install everything with the director, I don't get
> this file in the profile.
>
> So I don't know if we're closer to finding the cause of the problem, but
> it still only works installing plugins from our update site, if the
> Buckminster installation is in the same path as it was, when I first
> installed it with the director.
>
> Do you have other ideas?
>
> Thanks.
>
>
> /John
Re: Problems installing headless buckminster 3.6 [message #510743 is a reply to message #510665] Thu, 28 January 2010 14:25 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi John,
The entry present in the org.eclipse.equinox.p2.artifact.repository.prefs file should not cause any harm. That's just a
list of repositories previously known to p2. You application should function normally even if the entries there cannot
be reached.

Do you get a fatal error when you run or is it just a log entry? Can you please tell me exactly what you do and what the
output is?

Thanks,
Thomas Hallgren


On 01/28/2010 11:01 AM, John wrote:
> Hi Thomas!
>
>
> Thanks for the suggestion. I tried it out like this:
>
> director -r http://download.eclipse.org/tools/buckminster/headless-3.5/
> -d e:\temp\bm35-home\buckminster -p Buckminster
> -i org.eclipse.buckminster.cmdline.product
> -i org.eclipse.buckminster.core.headless.feature.feature.group
> -i org.eclipse.buckminster.maven.feature.feature.group
> -i org.eclipse.buckminster.pde.headless.feature.feature.group
> -roaming
>
> Unfortunately this doesn't make it work. However, there is a difference.
> First of all, if I take a fresh director_latest.zip, unzips it and run
> the director command with any number of -i arguments, I get the file:
>
> director\p2\org.eclipse.equinox.p2.engine\.settings\org.ecli
> pse.equinox.p2.artifact.repository.prefs
>
> and it has references to the install dir specified by the -d option. So
> in some sense the director installtion gets "polluted". It's almost like
> Highlander: "There can only be one" (use of the director) :). Unless, of
> course, it doesn't have any influnence at all.
>
> Second, after having executed the director I have the file:
>
> E:\temp\bm35-home\buckminster\p2\org.eclipse.equinox.p2.engi
> ne\.settings\org.eclipse.equinox.p2.artifact.repository.pref s
>
> with references to the install dir.
>
> Then, if I use my current approach of installing Buckminster features
> using Buckminster commands like:
>
> install http://download.eclipse.org/tools/buckminster/headless-3.5/
> org.eclipse.buckminster.core.headless.feature
>
> then I also get the file:
>
> E:\temp\bm35-home\buckminster\p2\org.eclipse.equinox.p2.engi
> ne\profileRegistry\Buckminster.profile\.data\.settings\org.e
> clipse.equinox.p2.artifact.repository.prefs
>
> with references to the install dir.
>
> However, if I just install everything with the director, I don't get
> this file in the profile.
>
> So I don't know if we're closer to finding the cause of the problem, but
> it still only works installing plugins from our update site, if the
> Buckminster installation is in the same path as it was, when I first
> installed it with the director.
>
> Do you have other ideas?
>
> Thanks.
>
>
> /John
Re: Problems installing headless buckminster 3.6 [message #510982 is a reply to message #510743] Fri, 29 January 2010 12:41 Go to previous message
John is currently offline JohnFriend
Messages: 107
Registered: July 2009
Senior Member
Hi Thomas!


Well, it manifests itself differently. I haven't really found the pattern.
Sometimes I can't find any log entries, but I can see that the plugins aren't installed in my Buckminster.
I have also on occasion found entries in a log.
Sometimes, like when I tried it right now, I get a full stack trace in the console, so hopefully you can get some useful information from this.

This Buckminster has been created by using the director for installing the org.eclipse.buckminster.cmdline.product with the -roaming option and then use Buckminster to install the other three headless features.

As you can see from the log, the original installation was made in e:\temp\bm35\buckminster and when I attempt to install from our update site, the Buckminster installation is placed in \temp\bm35-full-roam\buckminster\buckminster on the C: drive.

The console loge is below.

Thanks.

/John

call \temp\bm35-full-roam\buckminster\buckminster
-data /temp/bmtest35-assembly/bm_install
-S install-ncd-features.script
-vmargs -Xmx768M -XX:"MaxPermSize=256M"
-D"http.proxyHost=my.proxy.server"
-D"http.proxyPort=80"
-D"http.nonProxyHosts=mysiteserver"
-D"java.io.tmpdir=\temp\bmtest35-assembly\nbd_temp"
INFO: install 'http://mysiteserver/mysite' 'my.company.bd.dev.plugin.stubbuilderfeature'
java.io.FileNotFoundException: e:\temp\bm35\buckminster\artifacts.xml (The system cannot find the path specified)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(Unknown Source)
at java.io.FileOutputStream.<init>(Unknown Source)
at org.eclipse.equinox.internal.p2.artifact.repository.simple.S impleArtifactRepository.save(SimpleArtifactRepository.java:8 96)
at org.eclipse.equinox.internal.p2.artifact.repository.simple.S impleArtifactRepository.save(SimpleArtifactRepository.java:8 77)
at org.eclipse.equinox.internal.p2.artifact.repository.simple.S impleArtifactRepository. <init>(SimpleArtifactRepository.java:298)
at org.eclipse.equinox.internal.provisional.spi.p2.artifact.rep ository.SimpleArtifactRepositoryFactory.create(SimpleArtifac tRepositoryFactory.java:123)
at org.eclipse.equinox.internal.p2.artifact.repository.Artifact RepositoryManager.factoryCreate(ArtifactRepositoryManager.ja va:55)
at org.eclipse.equinox.internal.p2.repository.helpers.AbstractR epositoryManager.doCreateRepository(AbstractRepositoryManage r.java:272)
at org.eclipse.equinox.internal.p2.artifact.repository.Artifact RepositoryManager.createRepository(ArtifactRepositoryManager .java:48)
at org.eclipse.equinox.internal.p2.touchpoint.eclipse.Util.getB undlePoolRepository(Util.java:95)
at org.eclipse.equinox.internal.p2.touchpoint.eclipse.Util.getA ggregatedBundleRepository(Util.java:126)
at org.eclipse.equinox.internal.p2.touchpoint.eclipse.Util.getA ggregatedBundleRepository(Util.java:103)
at org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.C ollectAction.collect(CollectAction.java:70)
at org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.C ollectAction.execute(CollectAction.java:30)
at org.eclipse.equinox.internal.provisional.p2.engine.Phase.mai nPerform(Phase.java:129)
at org.eclipse.equinox.internal.provisional.p2.engine.Phase.per form(Phase.java:72)
at org.eclipse.equinox.internal.provisional.p2.engine.PhaseSet. perform(PhaseSet.java:44)
at org.eclipse.equinox.internal.provisional.p2.engine.Engine.pe rform(Engine.java:54)
at org.eclipse.buckminster.installer.Install.planAndExecute(Ins tall.java:122)
at org.eclipse.buckminster.installer.Install.run(Install.java:1 90)
at org.eclipse.buckminster.cmdline.AbstractCommand.basicRun(Abs tractCommand.java:155)
at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:3 41)
at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:1 35)
at org.eclipse.buckminster.cmdline.Headless.start(Headless.java :189)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.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(EclipseS tarter.java:368)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
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)
An error occurred while collecting items to be installed
[0]session context was:(profile=Buckminster, phase=org.eclipse.equinox.internal.provisional.p2.engine.pha ses.Collect, operand=, action=).
[0]Unable to write to repository: file:/e:/temp/bm35/buckminster.
Caused by: [0]java.io.IOException: Failed to create directory e:\temp\bm35\buckminster\plugins\my.company.bd.dev.plugin.bu ilderruntime_1.2.6.
[0]Unable to write to repository: file:/e:/temp/bm35/buckminster.
Caused by: [0]java.io.IOException: Failed to create directory e:\temp\bm35\buckminster\plugins.
[0]Unable to write to repository: file:/e:/temp/bm35/buckminster.
Caused by: [0]java.io.IOException: Failed to create directory e:\temp\bm35\buckminster\plugins.
buckminster failed with error code 1
Previous Topic:Aggregator NPE when building repo with Maven
Next Topic:qualifier replacement not happening
Goto Forum:
  


Current Time: Sun Sep 24 01:50:48 GMT 2023

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

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

Back to the top