Error building RTC plug-in with plug-in code checked-in to jazz source control
/home/dan/workspace/RTCv4_DEV/.metadata/.plugins/org.eclipse.pde.core/temp/org.eclipse.pde.container.feature/assemble.org.eclipse.pde.container.feature.p2.xml:35: The following error occurred while executing this line: /home/dan/workspace/RTCv4_DEV/.metadata/.plugins/org.eclipse.pde.core/temp/org.eclipse.pde.container.feature/assemble.org.eclipse.pde.container.feature.p2.xml:89: Unable to find: Installable Unit [ id=com.ibm.team.process.common.jfs.feature.feature.group version=1.1.1000.v20120518_2049 ]
The following error occurred while executing this line:
/home/dan/workspace/RTCv4_DEV/.metadata/.plugins/org.eclipse.pde.core/temp/org.eclipse.pde.container.feature/assemble.org.eclipse.pde.container.feature.p2.xml:89: Unable to find: Installable Unit [ id=com.ibm.team.process.common.jfs.feature.feature.group version=1.1.1000.v20120518_2049 ]
However, the same projects, if local to my development machine lead to successful update site build execution.
I have placed in source control only the projects that are related to plugin development, i.e., the advisors, the participants, the features and the update site. The other projects which are related to the setup of the development environment are still local to my computer.
Has anyone seen this kind of message? It looks to me as if there is a problem with the visibility of different resources in the Eclipse workspace. What could be the cause for this behaviour?
Thank you!
2 answers
<target name="generate.p2.metadata">
<property name="p2.flavor" value="tooling"/>
<delete dir="${assemblyTempDir}/p2.branding"/>
<p2.mirror>
<slicingOptions includeNonGreedy="false"/>
<source location="${p2.build.repo}"/>
<destination location="${p2.build.repo}" kind="metadata"/>
<destination location="${p2.build.repo}" kind="artifact"/>
<iu id="com.ibm.team.process.common.jfs.feature.feature.group" version="1.1.1000.v20120518_2049"/>
<iu id="com.ibm.team.repository.common.jfs.feature.feature.group" version="1.0.1000.v20120522_1716"/>
<iu id="com.ibm.team.repository.services.jfs.feature.feature.group" version="1.0.1000.v20120518_2049"/>
<iu id="com.ibm.team.workitem.common.rtc.feature.feature.group" version="3.1.0.v20120510_2207"/>
<iu id="com.ibm.team.workitem.server.rtc.feature.feature.group" version="3.1.0.v20120601_0115"/>
<iu id="com.ibm.team.process.server.jfs.feature.feature.group" version="1.1.1000.v20120518_2049"/>
</p2.mirror>
</target>
The question is, how can this target be disabled and eliminated from the build execution process. Since these are temporary generated files, clearly, they are created by taking some templates and instantiating them with the data specific to the build that is to be kicked off. So, any disabling would need to be done by altering the templates, if at all possible.
Obviously, this is the approach for the case that the broken references cannot be fixed by changing the workspace configuration, or something along these lines.
Comments
I wish I did not have to see this behaviour. However, I have a problem that looks to be a showstopper for me, not for the development itself, but for the implementation of a configuration management policy inside the project.
I cannot but wonder if it might be related to the RTC server deployment configuration and RTC client use, the server being deployed on AIX and my client being a Linux box. I am saying this because I discussed the matter with Ralph Schoon and he does not have this problem either. But as far as I know, he is using RTC deployed on Windows, with apache and derby.
My servers are on Linux and my clients are on Windows.
Then maybe it is something related to the particular version of RTC I am using...
Maybe I should consider performing a system upgrade to 4.0.5.
Hi Dan,
What is the value of p2.build.repo property? Could you simply add
<echo> ${ p2.build.repo } </echo>
to check the path?
What is the file structure there?
Also what is the reason of mirroring p2 where you have the same source and destination?
Comments
Dan Sevcenco
Jan 14 '14, 3:47 a.m.I have researched the matter a bit and discovered that the error is generated by a process called P2 which is linked with the Eclipse PDE build mechanism. This process is responsible for the generation of the artifacts.jar and content.jar files. These files are not mandatory for the deployment of the plug-in on the RTC server.
So, my question is : how do I deactivate the invocation of the P2 mechanism for the publishing of the metadata?
Note: I am using RTC v4.0 and the RTC Client bundled with Eclipse 3.6 for plug-in development.
Alex Fitzpatrick
JAZZ DEVELOPER Jan 14 '14, 2:58 p.m.Either way I don't think this is an RTC issue, this is an Eclipse plugin build issue. You should raise it on the Eclipse mailing lists.
Dan Sevcenco
Jan 14 '14, 1:44 p.m.This is a local build. It cannot be a plugin build issue since it is successful if the source code is not checked in and suddenly it fails if I check it in.
In my opinion, checking the code in, for some reason breaks the links between the projects (source code, feature and update-site) and between the projects and the RTC SDK and visibility on referenced resources is broken.
I do think it is something related to PDE and P2 but I do not have any clue how to investigate it.