It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,787
×10,826

question asked: Jan 13 '14, 8:02 a.m.
question was seen: 4,647 times
last updated: Jan 16 '14, 3:55 a.m.

Related questions

FAQ - How this Forum works

Error building RTC plug-in with plug-in code checked-in to jazz source control

0
Dan Sevcenco (50●2●19●23) | asked Jan 13 '14, 8:02 a.m.
edited Jan 13 '14, 8:06 a.m.
I am having a difficulty doing RTC plug-in development with the source code checked-in to jazz source control. The error is below: 

/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!

Comments
Dan Sevcenco commented 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 commented Jan 14 '14, 1:08 p.m. | edited Jan 14 '14, 2:58 p.m.
JAZZ DEVELOPER
Is this a local build or a build on a server? If this is server based how are you providing the dependencies? (If it's local it will pull the dependencies from the client automatically.)

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 commented 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.

2 answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Dan Sevcenco (50●2●19●23) | answered Jan 14 '14, 9:55 a.m.
edited Jan 14 '14, 10:00 a.m.
Looking at the temporary files that are generated during the update-site build process, I can see that, in the referenced XML file, the error occurs at the point where the ant target "generate.p2.metadata" is being executed. 
<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.
0
permanent link
sam detweiler (12.5k●6●195●201) | answered Jan 14 '14, 10:02 a.m.
edited Jan 14 '14, 10:03 a.m.
 I don't see this on 4.0.4.

I build the plugin/feature/update site on 3.x, checked into my stream,
loaded from 4.0.4 client, opened site.xml in the update site project and hit build. 
worked perfectly

I don't see the problem on 3.x either. 
Comments
Dan Sevcenco commented Jan 14 '14, 10:10 a.m.

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.

sam detweiler commented Jan 14 '14, 1:12 p.m.

 My servers are on Linux and my clients are on Windows. 

Dan Sevcenco commented Jan 14 '14, 1:46 p.m.

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.

Krzysztof Kaźmierczyk commented Jan 16 '14, 3:50 a.m. | edited Jan 16 '14, 3:55 a.m.

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?

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.