Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

with requirements, but not for all locations #47

Open
mduft opened this issue Nov 3, 2014 · 2 comments
Open

with requirements, but not for all locations #47

mduft opened this issue Nov 3, 2014 · 2 comments
Assignees

Comments

@mduft
Copy link

mduft commented Nov 3, 2014

Hey,

We have a target platform that is composed out of multiple locations. We want to go "with requirements", but there is one single site, where dependencies are not easily resolvable without a complete runtime environment. Thus we have to live without dependency resolution just because of one single stupid feature :|

I know that PDE does not support the "with requirements" per update site mode (you have it for all, or not at all), but we talked at EclipseCon and you said you might be able to come up with something - so this is your reminder :)

Cheers,
Markus

@mbarbero mbarbero self-assigned this Nov 3, 2014
@mbarbero
Copy link
Member

mbarbero commented Nov 3, 2014

Hi Markus,

Thank you for the reminder. I thought about your issue, and the DSL can be improved to help with your use case. The idea is do the resolution at generation time when the option with requirements is specified at the location level. Let's say you have the following .tpd file

location "location1" {
  org.bundle.id1
}

location "location2" {
  org.domain.my.feature
}

//for dependencies
location "location3"

you want requirements for location1, but location2 is not easy resolvable (as in your use case). I can imagine to recycle the fact that with requirements is settable for each location. Then the generated .target file would still have the option includeMode set to planner (i.e. without resolution) but the contents of the file already contains all dependencies of location1. Let's say org.bundle.id1 depends on org.bundle.id2 provided by location1 and org.bundle.id3 from location3. In addition org.domain.my.feature depends on com.commercial.feature. Currently the .targetfile would look like the given file (pseudo-XML):

<target>
  <locations>
    <location includeMode="planner">
      <unit id="org.bundle.id1"/>
      <repository location="location1"/>
    </location>
    <location includeMode="planner">
      <unit id="org.domain.my.feature"/>
      <repository location="location2"/>
    </location>
    <location includeMode="planner">
      <repository location="location3"/>
    </location>
  <locations>
</target>

Now with the behavior described above, we modify the .tpd file to make it look like this:

location "location1" {
  with requirements
  org.bundle.id1
}

location "location2" {
  org.domain.my.feature
}

//for dependencies
location "location3"

And now the generated .target would look like this:

<target>
  <locations>
    <location includeMode="planner">
      <unit id="org.bundle.id1"/>
      <unit id="org.bundle.id2"/> <!-- dependency of org.bundle.id1 -->
      <repository location="location1"/>
    </location>
    <location includeMode="planner">
      <unit id="org.domain.my.feature"/>
      <repository location="location2"/>
    </location>
    <location includeMode="planner">
      <unit id="org.bundle.id3"/> <!-- dependency of org.bundle.id1 -->
      <repository location="location3"/>
    </location>
  <locations>
</target>

Would that do the trick for you?

@mduft
Copy link
Author

mduft commented Nov 3, 2014

That would be extremely helpful! It sounds like that would solve all our problems in that area :)

@mbarbero mbarbero added this to the 3.0.0 — icy-manipulator milestone Nov 3, 2014
@mbarbero mbarbero removed this from the 3.0.0 — icy-manipulator milestone Sep 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants