Eclipse Community Forums: Oomph » Targlet requirement filter with oomph variable

Help

Home

Home » Eclipse Projects » Oomph » Targlet requirement filter with oomph variable

Show: Today's Messages :: Show Polls :: Message Navigator

Targlet requirement filter with oomph variable [message #1763394]

Mon, 15 May 2017 08:30

Felix Dorner

Messages: 392
Registered: December 2015

Senior Member

Hi,

I try to use an oomph variable in a targlet requirement filter, but it doesn't work. Does the filter attribute for targlet requirement not support references to oomph variables?

Report message to a moderator

Re: Targlet requirement filter with oomph variable [message #1763424 is a reply to message #1763394]

Mon, 15 May 2017 16:52

Ed Merks

Messages: 33133
Registered: July 2009

Senior Member

Well, only attributes of type String (and URI I think) directly support variables... Of course a ${x} is not syntactically convertible to a Version instance so you have to use a substitution annotation. The URI is http://www.eclipse.org/oomph/setup/FeatureSubstitution and the key must be the name of the attribute (as spelled in the *.ecore) you're substituting. The value is evaluated as normally expected and the result is then converted to an instance of the EDataType of the EAttribute.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Targlet requirement filter with oomph variable [message #1763430 is a reply to message #1763424]

Mon, 15 May 2017 21:02

Felix Dorner

Messages: 392
Registered: December 2015

Senior Member

I didn't explain too well. I wanted to do something like this:

<?xml version="1.0" encoding="UTF-8"?>
<setup:VariableTask
    xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI"
    xmlns:setup="http://www.eclipse.org/oomph/setup/1.0"
    name="groovy.version"
    defaultValue="2.1"
    storageURI="scope://Workspace"
    label="Groovy Compiler Version">
  <choice value="1.8"
      label="1.8"/>
  <choice value="2.0"
      label="2.0"/>
  <choice value="2.1"
      label="2.1"/>
  <choice value="2.3"
      label="2.3"/>
  <choice value="2.4"
      label="2.4"/>
  <choice value="2.5"
      label="2.5"/>
  <description>Select Groovy Version</description>
</setup:VariableTask>
[...]
<?xml version="1.0" encoding="UTF-8"?>
<targlets:Targlet
    xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:targlets="http://www.eclipse.org/oomph/targlets/1.0"
    xsi:schemaLocation="http://www.eclipse.org/oomph/targlets/1.0 http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/models/Targlets.ecore"
    name="Groovy Compiler">
  <requirement
      name="org.codehaus.groovy21.feature.feature.group"
      filter="(groovy.version=2.1)"/>
  <requirement
      name="org.codehaus.groovy22.feature.feature.group"
      filter="(groovy.version=2.2)"/>
[...]
</targlets:Targlet>

This doesn't work. But I found an alternative: I created multiple targlet tasks and set the filter attribute on the task rather than the requirement:

<?xml version="1.0" encoding="UTF-8"?>
<xmi:XMI xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:setup.targlets="http://www.eclipse.org/oomph/setup/targlets/1.0"
    xsi:schemaLocation="http://www.eclipse.org/oomph/setup/targlets/1.0 http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/models/SetupTarglets.ecore">
  <setup.targlets:TargletTask
      filter="(groovy.version=2.1)">
    <targlet
        name="Groovy 2.1">
      <requirement
          name="org.codehaus.groovy21.feature.feature.group"
          filter=""/>
    </targlet>
  </setup.targlets:TargletTask>
  <setup.targlets:TargletTask
      filter="(groovy.version=2.3)">
    <targlet
        name="Groovy 2.3"
        activeRepositoryList="">
      <requirement
          name="org.codehaus.groovy23.feature.feature.group"
          filter=""/>
    </targlet>
  </setup.targlets:TargletTask>
  <setup.targlets:TargletTask
      filter="(groovy.version=2.4)">
    <targlet
        name="Groovy 2.4"
        activeRepositoryList="">
      <requirement
          name="org.codehaus.groovy24.feature.feature.group"
          filter=""/>
    </targlet>
  </setup.targlets:TargletTask>
</xmi:XMI>

Report message to a moderator

Re: Targlet requirement filter with oomph variable [message #1763465 is a reply to message #1763430]

Tue, 16 May 2017 12:41

Ed Merks

Messages: 33133
Registered: July 2009

Senior Member

Though what I described for the requirement's version should work also for the requirement's filter...

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Targlet / P2Task requirement filter with oomph variable [message #1860830 is a reply to message #1763430]

Tue, 05 September 2023 11:46

Markus Hoffrogge

Messages: 7
Registered: March 2020

Junior Member

Felix Dorner wrote on Mon, 15 May 2017 10:30

I try to use an oomph variable in a targlet requirement filter, but it doesn't work. Does the filter attribute for targlet requirement not support references to oomph variables?

It works - but with an additional configuration:
Via a debug session I learned, that filtering within the <requirement/> node requires to provide custom setup variable names via P2Task attribute profileProperties to the scope of <requirement/> filter evaluation implementation:

  <setupTask
      xsi:type="setup:VariableTask"
      name="groovy.compiler.version"
      value="2.5"
      defaultValue=""
      storageURI="scope://Installation"
      label="Groovy Compiler Version">
    <description>Set the Groovy compiler version to use</description>
  </setupTask>
  <setupTask
      xsi:type="setup.p2:P2Task"
      label="Groovy ${groovy.compiler.version}"
      filter="(|(groovy.compiler.version=2*)(groovy.compiler.version=3*))"
      licenseConfirmationDisabled="true"
      profileProperties="groovy.compiler.version=${groovy.compiler.version}">
    <requirement
        name="org.codehaus.groovy.eclipse.feature.feature.group"/>
    <requirement
        name="org.codehaus.groovy25.feature.feature.group"
        filter="(groovy.compiler.version=2*)"/>
    <requirement
        name="org.codehaus.groovy30.feature.feature.group"
        filter="(groovy.compiler.version=3*)"/>
    <requirement
        name="org.codehaus.groovy.m2eclipse.feature.feature.group"/>
   <repository
        url="https://groovy.jfrog.io/artifactory/plugins-release-local/org/codehaus/groovy/groovy-eclipse-integration/4.9.0/e4.21/"/>
  </setupTask>

Summary:
Filtering within the <requirement/> node requires to provide custom setup variable names via P2Task attribute profileProperties like:

 <setupTask
    xsi:type="setup.p2:P2Task"
    profileProperties="variableName=${variableName},variableName2=${variableName2}
    [...]

This must be configured as a comma separated list of property key=value patterns.
Otherwise the custom variables to filter on are not visible for the <requirement/> nodes inside filter evaluation.

There are a few variables that do NOT require that explicit variable "transfer" - those variables can be used for filtering within <requirement/> out of the box:

osgi.os
osgi.arch
osgi.ws
org.eclipse.equinox.p2.roaming
org.eclipse.equinox.p2.environments
org.eclipse.equinox.p2.installFolder
org.eclipse.equinox.p2.cache
org.eclipse.update.install.features
org.eclipse.oomph.p2.profile.shared.pool
org.eclipse.oomph.p2.profile.definition
org.eclipse.oomph.p2.profile.type

Report message to a moderator

Re: Targlet / P2Task requirement filter with oomph variable [message #1860842 is a reply to message #1860830]

Tue, 05 September 2023 22:15

Markus Hoffrogge

Messages: 7
Registered: March 2020

Junior Member

Hi Ed,

IMO the before mentioned behavior looks to me more like a workaround rather than a solution.

I'd prefer to get the P2 requirement filters being considered like the SetupTask filters.
For this the following enhancements would be required:

Add P2 task requirement filter variables to all filter variables collected in SetupTaskPerformer during filter phase
Provide these filter variables with their values as properties to the P2Task profile context
Would the requirement filters in addition to be considered for macro replacements?

Report message to a moderator

Re: Targlet / P2Task requirement filter with oomph variable [message #1860847 is a reply to message #1860842]

Wed, 06 September 2023 05:00

Ed Merks

Messages: 33133
Registered: July 2009

Senior Member

The filtering used to enable/disable tasks just reuses the syntax/infrastructure that p2 uses for filters. Only profile properties can be (are) used to affect how p2 interprets filters on requirements, and, as you noticed, some "built-in" system properties have special treatment in p2 for that purpose (or are properties used by Oomph to record additional information in the profile).

I'm not sure what exactly you are proposing, to introduce some special type of variable, or attribute on a variable, that it will be used as a profile property without explicitly mentioning it via profileProperties="groovy.compiler.version=${groovy.compiler.version}"?

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Targlet / P2Task requirement filter with oomph variable [message #1860870 is a reply to message #1860847]

Wed, 06 September 2023 20:51

Markus Hoffrogge

Messages: 7
Registered: March 2020

Junior Member

Well, why then don't we pass all variable values resolved by SetupTaskPerformer as profile properties to the P2 infrastructure?

That would simplify the configuration and the requirements filter evaluation would behave "as expected".

Is there a reason why it is not implemented like this?

Report message to a moderator

Re: Targlet / P2Task requirement filter with oomph variable [message #1860880 is a reply to message #1860870]

Thu, 07 September 2023 06:31

Ed Merks

Messages: 33133
Registered: July 2009

Senior Member

Profile properties have a specific purpose. I don't think it's appropriate to just dump all variables into the profile. Just have a look at the Outline view when you have a Setup open and see the very large number of variables that are in scope. Also, variables aren't prompted unless they are actually used so such usage analysis would then need to consider if some filter from some requirement is intended to refer to a variable or not to know whether that variable requires promoting. I don't see that specifying the profileProperties attribute is all that onerous to justify building additional specialized infrastructure to make it less onerous.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Previous Topic:	oomph setup plugin not working in eclipse 2020-06
Next Topic:	Specifying restrictions on a P2 director

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 16 15:38:20 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter