Home » Archived » Buckminster » Problems installing headless buckminster 3.6
|
Re: Problems installing headless buckminster 3.6 [message #489884 is a reply to message #489852] |
Tue, 06 October 2009 12: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
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 |
Johannes Utzig 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 #489973 is a reply to message #489950] |
Tue, 06 October 2009 16:47 |
Achim Demelt 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 |
Johannes Utzig 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 |
Achim Demelt 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 |
|
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 |
Johannes Utzig 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 |
Achim Demelt 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 |
Achim Demelt 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 |
Joerg Buchberger 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 |
John 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 |
Henrik Lindberg 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 #509972 is a reply to message #509843] |
Mon, 25 January 2010 22:39 |
|
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 #509982 is a reply to message #508522] |
Mon, 25 January 2010 19:14 |
|
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 |
John 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) . 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 |
|
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 |
|
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 |
John 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
|
|
|
Goto Forum:
Current Time: Tue Dec 03 01:45:05 GMT 2024
Powered by FUDForum. Page generated in 0.06186 seconds
|