id attribute in the repository tag

[jmini]

When used in combination with Maven Tycho, it is possible to define an id attribute in the repository tag.

<location includeAllPlatforms="true" includeMode="slicer" includeSource="true" type="InstallableUnit">
  <repository id="orbit_S" location="http://download.eclipse.org/tools/orbit/downloads/drops/S20131024145017/repository/"/>

  <unit id="javax.servlet" version="3.0.0.v201112011016"/>
  <unit id="javax.servlet.source" version="3.0.0.v201112011016"/>
  <unit id="javax.wsdl" version="1.6.2.v201012040545"/>
  <!-- more units... -->
</location>

This allows applying some maven stuff (providing a password, a mirror…) for this repository
Example in the “.m2/settings.xml”:

<mirror>
  <id>orbit_S</id>
  <mirrorOf>orbit_S</mirrorOf>
  <url>{{alternative url for orbit S repository}}</url>
  <layout>p2</layout>
  <mirrorOfLayouts>p2</mirrorOfLayouts>
</mirror>

From what I can tell, it does not seems to be supported by PDE:
org.eclipse.pde.internal.core.target.IUBundleContainer#serialize()

URI[] repositories = getRepositories();
if (repositories != null) {
       for (int i = 0; i < repositories.length; i++) {
             Element repo = document.createElement(TargetDefinitionPersistenceHelper.REPOSITORY);
             repo.setAttribute(TargetDefinitionPersistenceHelper.LOCATION, repositories[i].toASCIIString());
             //I was expecting: repo.setAttribute("id", ...);
             containerElement.appendChild(repo);
       }
}

[jmini]

I have started to work on this issue on my GitHub fork.
https://github.com/jmini/fr.obeo.releng.targetplatform/tree/issue_17

It is the first time I use XText in a real example… So I hope what I did make sense.

Because id attribute in repository tag isn’t supported by PDE at all, I rewrote the export (for target file version 3.6, 3.7 and 3.8). This means that I do not have any dependency to PDE anymore (because I have re-implemented the export by myself).

For the moment to preserve the way the other fragments are working, I created a new Converter in a new fragment: fr.obeo.releng.targetplatform.pde-util_standalone (standalone == without PDE)
Of course, if this approach is validated, there is no need to keep these fragments, all the code can be in fr.obeo.releng.targetplatform. I could imagine an additional parameter somewhere in the DLL to say in which version the target should be exported.

I haven’t tested yet:

• the maven build
• an installation from the update site
• corner cases like: the repository do not contain any installable unit
  => There should be unit tests to guarantee that the export works well in the special cases.

I am also not sure about my implementation of the monitor. Because I do not know how the API should be used, I invented something, taking the existing code as example. It might be wrong…

I would appreciate to get feedback.

[mbarbero]

Hi Jérémie,

Thank you for your work. Unfortunately, I will not have time to look at it this week. Will try to do it next week. I will let you know.

Cheers,

Le 13 nov. 2013 à 21:59, Jérémie Bresson notifications@github.com a écrit :

I have started to work on this issue on my GitHub fork.
https://github.com/jmini/fr.obeo.releng.targetplatform/tree/issue_17

It is the first time I use XText in a real example… So I hope what I did make sense.

Because id attribute in repository tag isn’t supported by PDE at all, I rewrote the export (for target file version 3.6, 3.7 and 3.8). This means that I do not have any dependency to PDE anymore (because I have re-implemented the export by myself).

For the moment to preserve the way the other fragments are working, I created a new Converter in a new fragment: fr.obeo.releng.targetplatform.pde-util_standalone (standalone == without PDE)
Of course, if this approach is validated, there is no need to keep these fragments, all the code can be in fr.obeo.releng.targetplatform. I could imagine an additional parameter somewhere in the DLL to say in which version the target should be exported.

I haven’t tested yet:

the maven build
an installation from the update site
corner cases like: the repository do not contain any installable unit => There should be unit tests to guarantee that the export works well in the special cases.
I am also not sure about my implementation of the monitor. Because I do not know how the API should be used, I invented something, taking the existing code as example. It might be wrong…

I would appreciate to get feedback.

—
Reply to this email directly or view it on GitHub.

[mbarbero]

I did not took your code sample sorry (because I did not wanted to use XML API to serialize such a simple document). But the feature is there and will be shipped with 2.0 ;)

[jmini]

XML API is what PDE does... (I took the code from PDE).
I agree there are other solutions to output some XML nodes in a text file.

I will have a look at your version 2.