Community
Participate
Working Groups
Thomas, This is not a Buckminster problem but it has been motivated from recent changes in common infrastructure: "publish.build.stage.2: [echo] Used launcher: /opt/public/common/buckminster-3.7/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar [java] <title>Invalid Configuration Location</title>The configuration area at '/opt/public/common/buckminster-3.7/configuration' is not writable. Please choose a writable location using the '-configuration' command line option. BUILD FAILED /shared/jobs/buckminster-mdt-ocl-core-3.1-nightly/lastSuccessful/archive/publishroot/publisher.ant:94: The following error occurred while executing this line: /shared/jobs/buckminster-mdt-ocl-core-3.1-nightly/lastSuccessful/archive/publishroot/publisher.ant:118: Java returned: 15 Total time: 0 seconds" Is there any chance to make this folder writable. Marking as blocker since our promotion script can't actually promote our RC1, which is today BTW. Please, tell me as soon as possible if you can fix this, otherwise I should try to fix my promotion script by other means. Thanks in advance, Adolfo.
Given that many other Hudson builds run succesfully with the current Buckminster, I'm curious to what it is that you're doing that others don't. Making this folder writable creates a problem since the files that you put there are writable only to you. I can't remove them and hence not update Buckminster. To make the last update I had to move your files out of the way (they are now somewhere under /shared/common/buckminster-3.6-delete, feel free to remove them). At that time, I decided to protect the installation. It goes without saying that I want to help you get your build going, but I need to know why this is happening. Just making the folder writable isn't a good solution.
Thomas, The build succesfully completes. The problem comes when promoting (manually or automatically promoting via cron). Since the promotion script was taken from other modeling projects, they might also find the problem. I've solved the situation providing a new eclipse.home location which to be used by the promotion script, in this case: /opt/public/common/buckminster-3.6 Which currently have access to the configuration folder. I'm currently at home, so I'll try to provide a better description and/or other solution for the problem at work, ok ? P.S: If any other releng finds this bug because of the same problem, the following property for the promotion.ant script invocation solves the problem: -Dsaved.eclipse.home=/opt/public/common/buckminster-3.6 Best Regards, Adolfo.
Thomas, Link to our promotion ant and properties files of the our last stable RC1 buid: https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.1-nightly/498/artifact/publishroot/publisher.ant/*view*/ https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.1-nightly/498/artifact/publishroot/publisher.properties/*view*/ Apologies, if the information is too long, not accurate and/or the script has deficiencies, but I was not the script creator, I simply took it from another modeling project and I only made some tuning to fit our project requirements ;-) This publisher.ant file is a copy of the original file (promoter.ant) which we keep in our releng project: https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.1-nightly/ws/org.eclipse.mdt/org.eclipse.ocl/releng/org.eclipse.ocl.releng.buckminster/promoter.ant/*view*/ We need to prepare the publishing stuff (publisher.ant and publisher.properties) with every build. To do that, we use buckminster to call some tasks (ant targets) of the original publisher.ant file. Buckminster commands: https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.1-nightly/ws/org.eclipse.mdt/org.eclipse.ocl/releng/org.eclipse.ocl.releng.buckminster/scripts/ocl-buckminster.script/*view*/ The buckminster actions which match the ant targets are the following: - setup.promoter: prepares/create a promoter.properties file with some needed build-time properties (buid.id, java.home, eclipse.home, etc. ) - setup.publisher: among other things, it copies the promoter.ant and promoter.properties files as publisher.ant and publisher.properties into a publishroot folder which be later archived as part of the build's artifacts. Now that the publishing stuff (publisher.ant and publiser.properties files) is ready. I have a cron entry which tries to run the publiser.ant file of the last sucessful build. This command may also be manually executed and is the following: ant -f /shared/jobs/buckminster-mdt-ocl-core-3.1-nightly/lastSuccessful/archive/publishroot/publisher.ant -Dbuild.root=/opt/public/jobs/buckminster-mdt-ocl-core-3.1-nightly/lastSuccessful/ &> logs/mdt-ocl-publishing.log The default target from the ant file is executed "publish.build", which later calls "publish.build.stage.2" which it turns into the execution of the "publish.build.from.framework" target via a new java application launching. In this case, using the org.eclipse.equinox.launcher jar of a Eclipse-with-buckminster installation. A proper eclipse-with-buckminster installation is used by the means of the saved.eclipse.home property, which comes from the eclipse.home used during the build. Since I've configured my build via hudson to use buckminster 3.7, the following eclipse installation is used: /opt/public/common/buckminster-3.7 I guess that I strongly need an Eclipse-with-buckminster installation, to execute some buckminster-defined ant commands like the following: <!-- strip the micro version and anything following it --> <buckminster.substitute value="${version}" pattern="^(\d+\.\d+)\.\d+.*$" replacement="$$1" property="base.version" /> Once the publishing mechanism is explained, let's focus on the error we obtain when trying to execute the publisher.ant script: publish.build.stage.2: [echo] Used launcher: /opt/public/common/buckminster-3.7/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar [java] <title>Invalid Configuration Location</title>The configuration area at '/opt/public/common/buckminster-3.7/configuration' is not writable. Please choose a writable location using the '-configuration' command line option. BUILD FAILED /shared/jobs/buckminster-mdt-ocl-core-3.1-nightly/lastSuccessful/archive/publishroot/publisher.ant:94: The following error occurred while executing this line: /shared/jobs/buckminster-mdt-ocl-core-3.1-nightly/lastSuccessful/archive/publishroot/publisher.ant:118: Java returned: 15 Total time: 1 second publisher.ant:118 corresponds to the launching of the /opt/public/common/buckminster-3.7/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar java application: <java jvm="${java.executable}" jar="${launcher.jar}" fork="true" failonerror="true"> <syspropertyset> <propertyref builtin="commandline" /> <propertyref name="property.file.location" /> <propertyref name="property.load.prefix" /> </syspropertyset> <arg value="-data" /> <arg value="${publisher.workspace}" /> <arg value="-application" /> <arg value="org.eclipse.ant.core.antRunner" /> <arg value="-buildfile" /> <arg value="${ant.file}" /> <arg value="publish.build.from.framework" /> </java> It looks like the launching can't be achieved because the "configuration" folder is not writable. We couldn't for instance create a .log file. I'm not sure if we can launch our ant tasks using the /opt/public/common/buckminster-3.7/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar without any access to said configuration folder... Another solution from my side is setting in the ant file a different accessible location for this configuration folder (not only accessible by me, but by anyone who wants to launch the promotion ant script). However, I think that the natural configuration location is the one which belongs to the eclipse installation. Besides, I could change that for my script, however, as commented others who have been using this publishing mechanism will be affected by this problem until they realize that their promotion script starts to fail (which silently logs the issue in a file when we want execute via cron, BTW). Any other comment and/or correction you need and/or want to add to the explanation above, will be welcomed... Best Regards, Adolfo.
I should be able to resolve this using a cascading configuration somehow. But I'm not sure how to do that and I don't find any good examples so I've raised a question on the p2 dev list. http://dev.eclipse.org/mhonarc/lists/p2-dev/msg04168.html
Thomas, Thank you very much for facing on this. Please, keep us informed. P.S: Meanwhile, as commented, I'm still executing the promotion script using the shared buckminster 3.6 installation. Best Regards.
Is this still a problem? I'm now running an initialization as part of the install which should remove the need for your build to create additional files.
Thommas, I'm still using buckiminster 3.6 for promotion. I'll check that after having lunch... Cheers, Adolfo.
Thomas, I'm still getting the same error, when promoting with buckminster-3.7: publish.build.stage.2: [echo] Used launcher: /opt/public/common/buckminster-3.7/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar [java] <title>Invalid Configuration Location</title>The configuration area at '/opt/public/common/buckminster-3.7/configuration' is not writable. Please choose a writable location using the '-configuration' command line option. Regards, Adolfo.
please can someone helpout...this is the third weeks now i have been tryin to instal eclipse under window 7 but keep getting recieved and message like this: FAIL TO LOAD THE JNI SHARED LIBRARY C://... hw do i resolve this
Abdul, I fail to see how the problem you're describing is related to this bug. Can you please elaborate?
(In reply to comment #10) > Abdul, I fail to see how the problem you're describing is related to this bug. > Can you please elaborate? Hello Adolfo and Thomas, after switching my Xtext hudson job to buckminster-3.7 I get the same error. Pointing publisher.ant script to use the old 3.6, as Adolfo suggested, is just a temporal solution. We really have to solve this in order to keep buckminster as an eclipse build framework :) Regards, Dennis.
Dennis, I'm not sure why there's such an urgency to solve this. Correct me if I'm wrong, but the only problem here is that you're using a shared Buckminster instance. Why don't you simply use a Buckminster installation of your own?
(In reply to comment #12) > Dennis, I'm not sure why there's such an urgency to solve this. Correct me if > I'm wrong, but the only problem here is that you're using a shared Buckminster > instance. Why don't you simply use a Buckminster installation of your own? I would like to use the same buckminster instance that hudson plugin does. The shared instance is maintained (uptodate) and it's used by other projects, so if such an issue like this one occurs all the project can benefit from the found solution.
Our update site is also maintained. Your build could start with a director call that updates the features that you use (uninstall and install in the same director invocation is the same as an update).
(In reply to comment #3) > publisher.ant:118 corresponds to the launching of the > /opt/public/common/buckminster-3.7/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar > java application: > > <java jvm="${java.executable}" jar="${launcher.jar}" fork="true" > failonerror="true"> > <syspropertyset> > <propertyref builtin="commandline" /> > <propertyref name="property.file.location" /> > <propertyref name="property.load.prefix" /> > </syspropertyset> > <arg value="-data" /> > <arg value="${publisher.workspace}" /> > <arg value="-application" /> > <arg value="org.eclipse.ant.core.antRunner" /> > <arg value="-buildfile" /> > <arg value="${ant.file}" /> > <arg value="publish.build.from.framework" /> > </java> > > It looks like the launching can't be achieved because the "configuration" > folder is not writable. We couldn't for instance create a .log file. I'm not > sure if we can launch our ant tasks using the > /opt/public/common/buckminster-3.7/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar > without any access to said configuration folder... Setting configuration area to something writable solves this issue in my case: add following lines after <arg value="${publisher.workspace}" /> <arg value="-configuration" /> <arg value="${publisher.workspace}/configuration" /> I think it can be closed as wontfix. Regards, Dennis.
Dennis, Thanks for the suggestion. I've added the configuration path setting and the promotion scripts work without the workaround. I agree this bugzilla may be closed. Regards, Adolfo.
