how to say its fine it misses native artifacts for a specific environment? #380

jcompagner · 2021-11-17T15:13:09Z

jcompagner
Nov 17, 2021

in the pom file in the target-platform-configuration section i add:

                        <environment>
                            <os>macosx</os>
                            <ws>cocoa</ws>
                            <arch>aarch64</arch>
                        </environment>

besides the windows,linux,macos for x86_64 which i always already had.

But when i do that and then try to build anything then the target resolvement fails:

Caused by: java.lang.IllegalStateException: com.equo.chromium.feature.feature.group 80.0.11.202110280411 cannot be installed in this environment because its filter is not applicable.
    at org.eclipse.equinox.internal.p2.director.Slicer.validateInput (Slicer.java:109)
    at org.eclipse.equinox.internal.p2.director.Slicer.slice (Slicer.java:60)
    at org.eclipse.tycho.p2.util.resolution.AbstractSlicerResolutionStrategy.slice (AbstractSlicerResolutionStrategy.java:78)
    at org.eclipse.tycho.p2.util.resolution.ProjectorResolutionStrategy.resolve (ProjectorResolutionStrategy.java:69)
    at org.eclipse.tycho.p2.util.resolution.AbstractResolutionStrategy.multiPlatformResolve (AbstractResolutionStrategy.java:52)
    at org.eclipse.tycho.p2.resolver.InstallableUnitResolver.resolve (InstallableUnitResolver.java:145)
    at org.eclipse.tycho.p2.target.TargetDefinitionResolver.resolveContentWithExceptions (TargetDefinitionResolver.java:218)
    at org.eclipse.tycho.p2.target.TargetDefinitionResolver.resolveContent (TargetDefinitionResolver.java:106)
    at org.eclipse.tycho.p2.target.TargetDefinitionResolverService.resolveFromArguments (TargetDefinitionResolverService.java:89)
    at org.eclipse.tycho.p2.target.TargetDefinitionResolverService$$Lambda$178/000000005AAC1020.apply (Unknown Source)
    at java.util.concurrent.ConcurrentHashMap.computeIfAbsent (ConcurrentHashMap.java:1705)
    at org.eclipse.tycho.p2.target.TargetDefinitionResolverService.getTargetDefinitionContent (TargetDefinitionResolverService.java:62)
    at org.eclipse.tycho.p2.target.TargetPlatformFactoryImpl.resolveTargetDefinitions (TargetPlatformFactoryImpl.java:215)
    at org.eclipse.tycho.p2.target.TargetPlatformFactoryImpl.createTargetPlatform (TargetPlatformFactoryImpl.java:157)
    at org.eclipse.tycho.p2.target.TargetPlatformFactoryImpl.createTargetPlatform (TargetPlatformFactoryImpl.java:127)
    at org.eclipse.tycho.p2.target.TargetPlatformFactoryImpl.createTargetPlatform (TargetPlatformFactoryImpl.java:1)
    at org.eclipse.tycho.p2.manager.ReactorRepositoryManagerImpl.computePreliminaryTargetPlatform (ReactorRepositoryManagerImpl.java:86)
    at org.eclipse.tycho.p2.resolver.P2DependencyResolver.computePreliminaryTargetPlatform (P2DependencyResolver.java:226)
    at org.eclipse.tycho.core.resolver.DefaultTychoResolver.resolveProject (DefaultTychoResolver.java:124)
    at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.lambda$resolveProjects$0 (TychoMavenLifecycleParticipant.java:147)
    at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant$$Lambda$161/000000005B740FE0.accept (Unknown Source)
    at java.util.stream.ForEachOps$ForEachOp$OfRef.accept (ForEachOps.java:183)
    at java.util.stream.WhileOps$1$1.accept (WhileOps.java:99)
    at java.util.ArrayList$ArrayListSpliterator.tryAdvance (ArrayList.java:1632)
    at java.util.stream.ReferencePipeline.forEachWithCancel (ReferencePipeline.java:127)
    at java.util.stream.AbstractPipeline.copyIntoWithCancel (AbstractPipeline.java:515)
    at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:501)
    at java.util.stream.AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:487)
    at java.util.stream.ForEachOps$ForEachOp.evaluateSequential (ForEachOps.java:150)
    at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential (ForEachOps.java:173)
    at java.util.stream.AbstractPipeline.evaluate (AbstractPipeline.java:239)
    at java.util.stream.ReferencePipeline.forEach (ReferencePipeline.java:497)
    at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.resolveProjects (TychoMavenLifecycleParticipant.java:178)
    at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead (TychoMavenLifecycleParticipant.java:105)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:264)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:566)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)

it seems that this is purely the target resolvement, doesn't really have yet anything todo with what it exactly builds (in this case purely the feature)

but i know that one doesn't have native artifacts for the aarch64, i will work around that by making stuff optional

that feature that it tries to resolve is:

<feature
      id="com.equo.chromium.feature"
      label="Chromium SWT Browser Feature"
      version="80.0.11.202110280411"
      provider-name="Equo"
      os="linux,macosx,win32"
      ws="cocoa,gtk,win32"
      arch="x86_64,x86">

so yes its only for x86...

how can i force Tycho that it just needs to resolve this and just not include it in the final build for aarch64?

Answered by laeubi

Dec 5, 2021

As mentioned and discussed on the PR this is due to the usage of planner mode but there is no solution for the target configuration aarm64.
Using a separate target file is a possible workaround.

View full answer

laeubi · 2021-11-17T15:39:01Z

laeubi
Nov 17, 2021
Maintainer

Currently, if you configure an env it will be tried to resolve all defined ones. You can circumvent that by only specify the additional environment only for the product build.

BTW environments are not native artifacts ... these are different things.

7 replies

jcompagner Nov 18, 2021
Author

thats the problem, there is no aarch64 for chromium yet and that can take a while to be there.

But code wise for me that is not a problem i can make that optional and if i detect i can't use chromium then i fallback to the default SWT Browser.. (we already have that switch in place also on other platforms, which by default go to chromium but that can be turned off)

So i made the chromium feature that i include in my feature already an optional feature there, also in the plugins that use the chromium plugin i made those optional also.

i now have it build with a target that doesnt include that chromium repo, and it builds for all 4 platforms but ofcourse without chromium right now in any one.

So now first i want to see if i can make it that it will be included in the 3 platforms where we do have support for Chromium (not sure what all that option will do, will it then not install it at all at first?)

laeubi Nov 18, 2021
Maintainer

If chromium is really optional, it might be an option to install it on demand into the product?

jcompagner Nov 18, 2021
Author

hmm thats not good, now i made it optional its really optional.. (its not installed in the product)

will try some other ways how can can trick the system todo this (install the native part if it has one, if not then just ignore it)
it does do that for the other native parts that i have, but thats really plugins are not 3rd party, but from us
(like the jvm plugin and the nodejs plugin)

jcompagner Nov 18, 2021
Author

If chromium is really optional, it might be an option to install it on demand into the product?

for windows its not really optional... because the embedded browser (IE) that eclipse still depends on is useless for us.
So we do want to ship it if it is there. but if not then fine.

jcompagner Nov 18, 2021
Author

i think i have it,
in the feature i have now

   <includes
         id="com.equo.chromium.cef.feature"
         version="0.0.0"
         arch="x86_64"/>

   <includes
         id="com.equo.chromium.feature"
         version="0.0.0"
         arch="x86_64"/>

so i force the 2 chromium features to just be installed only when x86_64 arch
That seems to build the product for windows just fine and then when using a different target and a different profile for the aarch64 build it seems to work, but i need to check a bit more.

So its really annoying that i need a different target for this and a profile because of that.
For me the target resolvement is just to smart why does it care, let the product builder later on bomb out if it is not ok. For me the target will be fine for that platform....

jcompagner · 2021-11-29T08:47:47Z

jcompagner
Nov 29, 2021
Author

hmm i am kind of stuck with this. very weird build errors are happening like:

[INFO] Reactor Summary:
[INFO]
[INFO] servoy-eclipse 2021.12.0.3720_rc ................... SUCCESS [ 0.498 s]
[INFO] com.servoy.eclipse.jre.linux.x86_64 17.0.1 ......... SUCCESS [ 12.454 s]
[INFO] com.servoy.eclipse.jre.macosx.x86_64 17.0.1 ........ SUCCESS [ 11.012 s]
[INFO] com.servoy.eclipse.jre.macosx.aarch64 17.0.1 ....... SUCCESS [ 11.701 s]
[INFO] com.servoy.eclipse.jre.win32.x86_64 17.0.1 ......... SUCCESS [ 10.887 s]
[INFO] com.servoy.eclipse.nodejs.linux.gtk.x86_64 16.11.1 . SUCCESS [ 2.758 s]
[INFO] com.servoy.eclipse.nodejs.macosx.cocoa.x86_64 16.11.1 SUCCESS [ 3.334 s]
[INFO] com.servoy.eclipse.nodejs.macosx.cocoa.aarch64 16.13.0 SUCCESS [ 3.333 s]
[INFO] com.servoy.eclipse.nodejs.win32.win32.x86_64 16.11.1 SUCCESS [ 2.949 s]
[INFO] com.servoy.eclipse.feature 2021.12.0.3720_rc ....... FAILURE [ 0.422 s]
[INFO] com.servoy.eclipse.product 2021.12.0.3720_rc ....... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:49 min
[INFO] Finished at: 2021-11-29T09:11:19+01:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:2.5.0:package-feature (default-package-feature) on project com.servoy.eclipse.feature: Execution default-package-feature of goal org.eclipse.tycho:tycho-packaging-plugin:2.5.0:package-feature failed: eclipse-plugin artifact with ID "com.servoy.eclipse.jre.macosx.aarch64" and version matching "17.0.1" was not found in the target platform -> [Help 1]

so it complains about a artifact that it JUST build above it...

And the weird thing is if i just go to the feature and i do mvn install it works..

But all the workarounds that i try to do will in the end also break i think the update site that is generated (i really want to have 1 with all the artifacts in it..)

But i don't see a way to do this. I guess i need to start forking tycho :(

How else can i build my full product for 4 platforms where for 1 platforms the native artifacts are not there and that is fine because those native artifacts are marked as only to install for 3 platforms in my feature and the plugins form those native artifacts are optionally marked in the plugins that needs them...

This is all because i know the native artifacts are not for all platforms, but our product is fine with that..

But the target platform resolver is just to smart and way to soon, it seems to not even check what it tries to install, it just wants all artifacts for all platforms to be there. I just don't understand why that is, let the feature/plugins/product decide that...

4 replies

laeubi Nov 29, 2021
Maintainer

But i don't see a way to do this. I guess i need to start forking tycho :(

Contributions are always welcome

This is all because i know the native artifacts are not for all platforms, but our product is fine with that..

As mentioned above, there is no problem with any native artifact but with your are building for a product for a platform(!) where not all dependencies could be satisfied. (at least what I can guess from the error).

but our product is fine with that..

You could simply provide an empty bundle that matches the given platform and has the same ID if you want...

mickaelistria Nov 29, 2021
Collaborator

This issue seems different from the initial one. I suggest you start a new discussion focused on it, or -if you have some hints that it is actually a bug in Tycho- report it in an issue ticket with mininal project and steps to reproduce.

jcompagner Nov 29, 2021
Author

But i don't see a way to do this. I guess i need to start forking tycho :(

You could simply provide an empty bundle that matches the given platform and has the same ID if you want...

hmm can i do that...
its a feature: com.equo.chromium.feature.feature.group 80.0.14.202111290455 cannot be installed in this environment because its filter is not applicable.

and that feature says:

<feature
      id="com.equo.chromium.feature"
      label="Chromium SWT Browser Feature"
      version="80.0.6.202108260514"
      provider-name="Equo"
      os="linux,macosx,win32"
      ws="cocoa,gtk,win32"
      arch="x86_64,x86">

can i create a feature in my own source that is exactly that id but then for just the macosx,aarch64 platform?

i will try this.

This issue seems different from the initial one. I suggest you start a new discussion focused on it, or -if you have some hints that it is actually a bug in Tycho- report it in an issue ticket with mininal project and steps to reproduce.

no, its still exactly the same issue,

jcompagner Nov 29, 2021
Author

doesn't seem to work:

[INFO] Computing target platform for MavenProject: com.servoy:com.equo.chromium.feature:80.0.14.202111290455 @ C:\Users\jcomp\git\servoy_master\servoy-eclipse\com.equo.chromium.feature\pom.xml
[INFO] Resolving dependencies of MavenProject: com.servoy:com.equo.chromium.feature:80.0.14.202111290455 @ C:\Users\jcomp\git\servoy_master\servoy-eclipse\com.equo.chromium.feature\pom.xml
[INFO] Resolving class path of MavenProject: com.servoy:com.equo.chromium.feature:80.0.14.202111290455 @ C:\Users\jcomp\git\servoy_master\servoy-eclipse\com.equo.chromium.feature\pom.xml
[INFO] Computing target platform for MavenProject: com.servoy:com.servoy.css.core:2021.12.0.3720_rc @ C:\Users\jcomp\git\servoy_master\servoy-eclipse\com.servoy.css.core\pom.xml
[ERROR] Cannot resolve target definition:
[ERROR] Problems resolving provisioning plan.:
[ERROR] com.equo.chromium.feature.feature.group 80.0.14.202111290455 cannot be installed in this environment because its filter is not applicable.

i added to our own that exact same feature id and then only applicable for osx/aarch64:

<feature
      id="com.equo.chromium.feature"
      label="Feature"
      version="80.0.14.202111290455"
      provider-name="Equo"
      os="macosx"
      arch="aarch64">

and yes you see it does pick it up above it calculates it depedencies
then goes to the next and there it bombs out because it can't find that feature...

i think this is all because of the same reason, the target/environment resolvement of target-platform-configuration doesn't really look at the "outside" world yet, it really seems to look at "ok this is my target file and all my locations, and i need to generate for these environments that are configured"

Seems to me it doesn't look outside of that yet it expect that everything resolves "internally"

jcompagner · 2021-11-29T10:34:50Z

jcompagner
Nov 29, 2021
Author

the problem is in this area:

Caused by: java.lang.IllegalStateException: com.equo.chromium.feature.feature.group 80.0.14.202111290455 cannot be installed in this environment because its filter is not applicable.
at org.eclipse.equinox.internal.p2.director.Slicer.validateInput (Slicer.java:109)
at org.eclipse.equinox.internal.p2.director.Slicer.slice (Slicer.java:60)
at org.eclipse.tycho.p2.util.resolution.AbstractSlicerResolutionStrategy.slice (AbstractSlicerResolutionStrategy.java:78)
at org.eclipse.tycho.p2.util.resolution.ProjectorResolutionStrategy.resolve (ProjectorResolutionStrategy.java:69)
at org.eclipse.tycho.p2.util.resolution.AbstractResolutionStrategy.multiPlatformResolve (AbstractResolutionStrategy.java:52)
at org.eclipse.tycho.p2.resolver.InstallableUnitResolver.resolve (InstallableUnitResolver.java:145)
at org.eclipse.tycho.p2.target.TargetDefinitionResolver.resolveContentWithExceptions (TargetDefinitionResolver.java:218)
at org.eclipse.tycho.p2.target.TargetDefinitionResolver.resolveContent (TargetDefinitionResolver.java:106)
at org.eclipse.tycho.p2.target.TargetDefinitionResolverService.resolveFromArguments (TargetDefinitionResolverService.java:89)

that Slicer is p2 itself that triggers the first exception
But if i read this quickly this is because Tycho tries to resolve the full "multiPlatform"

so i guess its this loop:

        for (TargetEnvironment environment : environments) {
            result.addAll(resolve(getEffectiveFilterProperties(environment), monitor));
        }

maybe i just have to try catch inside the for loop to just ignore it?

1 reply

laeubi Nov 29, 2021
Maintainer

maybe i just have to try catch inside the for loop to just ignore it?

that doesn't make sense, as this would be the same as not specify aarch64 and this could be done in the pom of course.
So if that's desired for your, simply add a target-configuration to this particular feature project that excludes the aarch64

laeubi · 2021-11-29T10:46:35Z

laeubi
Nov 29, 2021
Maintainer

doesn't seem to work

Because first you said a plugin is missing for aarm64 now you actually want a feature and in the end you complain about missing target resolution ... its a bit hard to guess what is the actual problem/configuration to give advice.

As said at the very beginning all environments you declare need to be resolvable and the error message clearly states that this is not possible because com.equo.chromium.feature.feature.group is incompatible, so you can't use com.equo.chromium.feature.feature.group in your target platform if you want to resolve it as aarch64.

You effectively has the following options:

ask the provider of com.equo.chromium.feature.feature.group to support aarch64 as well
use the director mojo to install the feature after tycho has assembled the product (that's similar on how root features work in tycho) with an exclusion for unsupported platforms.

0 replies

jcompagner · 2021-11-29T11:34:03Z

jcompagner
Nov 29, 2021
Author

platformresolvement.zip

i uploaded a very small example that already fails, so are you guys saying yes this is how it works this is not a bug or a feature that could be implemented better? (to handle this scenario way better?)

you do do first in the target dir: mvn install
then in the com.sample.feature: mvn install

if fails right away because, for me that should just install,

why would the target resolvement be so smart? let the fail if needed down the line, not that high up...
Why should the target platform care about this stuff? why is the purpose that it fails already this early?

ask the provider of com.equo.chromium.feature.feature.group to support aarch64 as well

already asked, but this can take quite some time, its out of my hands, could even be that it is maybe there in about a year...

use the director mojo to install the feature after tycho has assembled the product (that's similar on how root features work in tycho) with an exclusion for unsupported platforms.

So this means the target file should not have that chromium location at all?
And then just before the actual product is build i need to provision the generated repository with the native chromium artifacts?
(and from that i can generate the actual native builds? and that repository can be used as a upgrade for older installs?)

Because you do see "after assembled the product" that doesn't mean all the 3 actual product builds that i already have at the end?

i guess this:

https://github.com/Servoy/servoy-eclipse/blob/master/com.servoy.eclipse.product/pom.xml#L109

generated the actual repository?

and then this:

https://github.com/Servoy/servoy-eclipse/blob/master/com.servoy.eclipse.product/pom.xml#L120

makes the actual products?

so i need something in between that?

1 reply

laeubi Nov 29, 2021
Maintainer

Your feature project simply should not list

<environment>
	<os>macosx</os>
	<ws>cocoa</ws>
	<arch>aarch64</arch>
</environment>

as your target can't be resolved as such.

If I remember right, the <phase>install</phase> is the correct place to modify the product before it gets packed:

https://wiki.eclipse.org/Equinox/p2/Director_application

jcompagner · 2021-11-29T12:03:11Z

jcompagner
Nov 29, 2021
Author

my above test case is fixed by this patch:

diff --git a/tycho-bundles/org.eclipse.tycho.p2.resolver.impl/src/main/java/org/eclipse/tycho/p2/util/resolution/ProjectorResolutionStrategy.java b/tycho-bundles/org.eclipse.tycho.p2.resolver.impl/src/main/java/org/eclipse/tycho/p2/util/resolution/ProjectorResolutionStrategy.java
index 71b26c9..406fbe0 100644
--- a/tycho-bundles/org.eclipse.tycho.p2.resolver.impl/src/main/java/org/eclipse/tycho/p2/util/resolution/ProjectorResolutionStrategy.java
+++ b/tycho-bundles/org.eclipse.tycho.p2.resolver.impl/src/main/java/org/eclipse/tycho/p2/util/resolution/ProjectorResolutionStrategy.java
@@ -52,7 +52,12 @@
 
     @Override
     protected Slicer newSlicer(IQueryable<IInstallableUnit> availableUnits, Map<String, String> properties) {
-        return new Slicer(availableUnits, properties, false);
+        return new Slicer(availableUnits, properties, false) {
+            @Override
+            protected boolean isApplicable(IInstallableUnit iu) {
+                return true;
+            }
+        };
     }
 
     @Override

so for Tycho the sliver always validates (isApplicatable always just returns true)

Can this somehow be made an option? So that i can force tycho to not try to resolve at the target level already stuff?
I am not sure if this fully helps my problem, and how it now fully works, i will try that now.

8 replies

laeubi Nov 29, 2021
Maintainer

because the real validation happens down the line when the plugin,feature or product is really build

Just for the record: It is not tychor or "the target" that fails here but the P2-Planner mode, and that is supposed to validate as in PDE a target resolution also can fail if not all requirements (from the target or the bundles itself) could be satisfied and that is what fails here.

The usual recommendation is to have a feature that only optionally includes the native features, so it will always resolve successful. This could on the other side lead to the undesirable situation that actually nothing is included but this seems fine here.

My impression is that it would be more suitable to build a fixed version of that offending feature (is there a link from its sources?) instead of changing tycho here.

jcompagner Nov 30, 2021
Author

no chromium is for the most part i think a closed source thing that we buy in. (because it was removed from eclipse when they donated it again)

they have 2 features that i include 1 is

<?xml version="1.0" encoding="UTF-8"?>
<feature
      id="com.equo.chromium.cef.feature"
      label="CEF binaries for Chromium SWT Browser"
      version="80.0.9.202110280424"
      provider-name="Equo">

   <description>
      CEF binaries for Chromium SWT Browser
   </description>

   <copyright>
      Copyright (c) Equo.  
      All rights reserved. 
      https://www.equoplatform.com
   </copyright>

   <license>
    Equo Chromium.SWT License

    Copyright (c) 2020 Equo.
    All rights reserved.

    THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
    CONTRIBUTORS &quot;AS IS&quot; AND ANY EXPRESS OR IMPLIED WARRANTIES,
    INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
    MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
    DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
    CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
    SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
    NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
    LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
    HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
    CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
    OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
    SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
    
    This product includes the following third party libraries:
    * Chromium Embedded Framework licensed under the BSD 3-clause
      license. Website: https://bitbucket.org/chromiumembedded/cef
        * Redistributions of source code must retain the above
        copyright notice, this list of conditions and the
        following disclaimer.
        * Redistributions in binary form must reproduce the above
        copyright notice, this list of conditions and the
        following disclaimer in the documentation and/or other
        materials provided with the distribution.
        * Neither the name of Google Inc. nor the name Chromium
        Embedded Framework nor the names of its contributors may 
        be used to endorse or promote products derived from this
        software without specific prior written permission.
   </license>

   <plugin
         id="com.equo.chromium.cef.win32.win32.x86_64"
         os="win32"
         ws="win32"
         arch="x86_64"
         download-size="72618"
         install-size="173610"
         version="80.0.9.202110280424"
         fragment="true"/>

   <plugin
         id="com.equo.chromium.cef.gtk.linux.x86_64"
         os="linux"
         ws="gtk"
         arch="x86_64"
         download-size="84645"
         install-size="236235"
         version="80.0.9.202110280424"
         fragment="true"/>

   <plugin
         id="com.equo.chromium.cef.cocoa.macosx.x86_64"
         os="macosx"
         ws="cocoa"
         arch="x86_64"
         download-size="92294"
         install-size="232722"
         version="80.0.9.202110280424"
         fragment="true"/>

</feature>

so that is just a feature that just has some plugin for the 3 environments they support (thats kind of the chromium dll's)

the other is this one, and i think this is the one that is more problematic:

<?xml version="1.0" encoding="UTF-8"?>
<feature
      id="com.equo.chromium.feature"
      label="Chromium SWT Browser Feature"
      version="80.0.14.202111290455"
      provider-name="Equo"
      os="linux,macosx,win32"
      ws="cocoa,gtk,win32"
      arch="x86_64,x86">

   <description url="https://www.equoplatform.com">
      Chromium SWT Browser
   </description>

   <copyright>
      Copyright (c) Equo.  
      All rights reserved. 
      https://www.equoplatform.com
   </copyright>

   <license>
    Equo Chromium.SWT License

    Copyright (c) 2020 Equo.
    All rights reserved.

    THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
    CONTRIBUTORS &quot;AS IS&quot; AND ANY EXPRESS OR IMPLIED WARRANTIES,
    INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
    MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
    DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
    CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
    SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
    NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
    LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
    HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
    CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
    OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
    SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
    
    This product includes the following third party libraries:
    * Chromium Embedded Framework licensed under the BSD 3-clause
      license. Website: https://bitbucket.org/chromiumembedded/cef
        * Redistributions of source code must retain the above
        copyright notice, this list of conditions and the
        following disclaimer.
        * Redistributions in binary form must reproduce the above
        copyright notice, this list of conditions and the
        following disclaimer in the documentation and/or other
        materials provided with the distribution.
        * Neither the name of Google Inc. nor the name Chromium
        Embedded Framework nor the names of its contributors may 
        be used to endorse or promote products derived from this
        software without specific prior written permission.
   </license>

   <plugin
         id="com.equo.chromium"
         download-size="356"
         install-size="703"
         version="80.0.14.202111290455"
         unpack="false"/>

</feature>

thats a feature that by itself already filters for stuff... (and has then a "normal" plugin)

akurtakov Nov 30, 2021
Maintainer

no chromium is for the most part i think a closed source thing that we buy in. (because it was removed from eclipse when they donated it again)

It was removed from eclipse because what was donated was not working and was used to as a way to exploit FOSS project to get free release engineering for your business. I've been involved in all that including getting chromium support initially, trying to talk to contributors to get things continued (and being totally ignored for a year!) and end up with emails trying to sell me an actually working version!!! This is definitely not the way one does contributions and more than sure a way to piss off people you're supposed to work with!
P.S. Sorry for this off-topic comment for Tycho but I can't allow even the smallest possibility for your statement to be interpreted by people without the details.

laeubi Nov 30, 2021
Maintainer

I can understand the intend of this but it is kind of too restrictive to be used if the feature would be used in a (optional) way.

The more generic way would be to have one feature for each platform

com.equo.chromium.cef.win32.feature
com.equo.chromium.cef.linux.feature
com.equo.chromium.cef.mac.feature
com.equo.chromium.cef.aarch64.feature

all of these would include com.equo.chromium + only the platform relevant part + a filter

com.equo.chromium.feature (or com.equo.chromium.cef.feature if there are different implementations) should include all these features with optional=true

jcompagner Nov 30, 2021
Author

no chromium is for the most part i think a closed source thing that we buy in. (because it was removed from eclipse when they donated it again)

It was removed from eclipse because what was donated was not working and was used to as a way to exploit FOSS project to get free release engineering for your business. I've been involved in all that including getting chromium support initially, trying to talk to contributors to get things continued (and being totally ignored for a year!) and end up with emails trying to sell me an actually working version!!! This is definitely not the way one does contributions and more than sure a way to piss off people you're supposed to work with! P.S. Sorry for this off-topic comment for Tycho but I can't allow even the smallest possibility for your statement to be interpreted by people without the details.

yeah i know, i already warned them about that, but yeah they wanted to make money (it think its there main product)

For us it doesn't matter to much if it shipped with eclipse (or partly) or not, we just need to have a "real" browser in eclipse especially under windows. because the embedded IE is completely unusable.
And for us its also nice to have the same browser over all platforms, that means a lot less testing (because we also have some smaller issues with the embedded safari browsers on the mac)
In our product we have a few editors and other stuff that are al just using html (mostly angular apps) that we run in an embedded tomcat browser. So we really need a consistent browser experience in our product.

For me embedding, especially under windows, the right browser component in eclipse (WebView2, based on Edge i guess now) would be one of my highest prio's when i was a product manager of eclipse)

jcompagner · 2021-11-29T14:12:48Z

jcompagner
Nov 29, 2021
Author

ok tested our product everything perfectly builds now without many changes in poms or that kind of stuff
The only thing i really needed todo is to tell Tycho to also build for that macosx,aarch64 environment.

So i really need to have this patch to be able to build our product nicely without much fuss.

I guess i need to fork then and push our own build of Tycho on our mvn repo.

2 replies

mickaelistria Nov 29, 2021
Collaborator

I guess i need to fork then and push our own build of Tycho on our mvn repo.

If you think this patch is good in general, you may try to submit it as a PR and committers will evaluate whether it's worth being merged in mainstream Tycho.

mickaelistria Nov 29, 2021
Collaborator

I just looked at platformresolvement.zip , and I think Tycho's current behavior can be seen as a bug or a limitation. A .target element that does resolve against 1 environment but not against some others should be reported as a warning -or even debug info-, but let build continue despite the delta between different environments. I believe the issue is really the target-platform resolution that interprets all requirements as very strict requirements while it could be seen all as optional+greedy.
One workaround is to have a "proxy" feature referenced in your .target file, and this "proxy" feature would reference the platform-restricted one as "optional" so it would allow to resolve the .target on every platform.
Your change proposal can be a good solution, but it's too early to say; so moving it to a PR and having tests to run against it would allow to bring discussion to the next stage.

jcompagner · 2021-11-29T15:13:18Z

jcompagner
Nov 29, 2021
Author

i made a pull request: #400

i added a info log:

            protected boolean isApplicable(IInstallableUnit iu) {
                if (!super.isApplicable(iu)) {
                    logger.info(
                            "InstallableUnit " + iu.getId() + " isn't applicable for all the selected environments");
                }
                return true;
            }

not sure if i can get more info, because that is i think all hidden away in the filters and matchers

By the way, how do you make a release for tycho?
lets say i want to create a release called 2.6.0.s1, i updated all poms and manifest but then i get a very weird error when building Tycho core:
[ERROR] Failed to execute goal org.codehaus.plexus:plexus-component-metadata:2.1.0:generate-metadata (default) on project tycho-core: Error generating metadata: : Failed to extract descriptors: Can't load class EquinoxServiceFactory -> [Help 1]
[ERROR]

i guess i miss something and a version push needs to be done through mvn?

0 replies

laeubi · 2021-12-05T17:54:21Z

laeubi
Dec 5, 2021
Maintainer

As mentioned and discussed on the PR this is due to the usage of planner mode but there is no solution for the target configuration aarm64.
Using a separate target file is a possible workaround.

0 replies

how to say its fine it misses native artifacts for a specific environment? #380

jcompagner Nov 17, 2021

Replies: 9 comments · 23 replies

laeubi Nov 17, 2021 Maintainer

jcompagner Nov 18, 2021 Author

laeubi Nov 18, 2021 Maintainer

jcompagner Nov 18, 2021 Author

jcompagner Nov 18, 2021 Author

jcompagner Nov 18, 2021 Author

jcompagner Nov 29, 2021 Author

laeubi Nov 29, 2021 Maintainer

mickaelistria Nov 29, 2021 Collaborator

jcompagner Nov 29, 2021 Author

jcompagner Nov 29, 2021 Author

jcompagner Nov 29, 2021 Author

laeubi Nov 29, 2021 Maintainer

laeubi Nov 29, 2021 Maintainer

jcompagner Nov 29, 2021 Author

laeubi Nov 29, 2021 Maintainer

jcompagner Nov 29, 2021 Author

laeubi Nov 29, 2021 Maintainer

jcompagner Nov 30, 2021 Author

akurtakov Nov 30, 2021 Maintainer

laeubi Nov 30, 2021 Maintainer

jcompagner Nov 30, 2021 Author

jcompagner Nov 29, 2021 Author

mickaelistria Nov 29, 2021 Collaborator

mickaelistria Nov 29, 2021 Collaborator

jcompagner Nov 29, 2021 Author

laeubi Dec 5, 2021 Maintainer

jcompagner
Nov 17, 2021

Replies: 9 comments 23 replies

laeubi
Nov 17, 2021
Maintainer

jcompagner Nov 18, 2021
Author

laeubi Nov 18, 2021
Maintainer

jcompagner Nov 18, 2021
Author

jcompagner Nov 18, 2021
Author

jcompagner Nov 18, 2021
Author

jcompagner
Nov 29, 2021
Author

laeubi Nov 29, 2021
Maintainer

mickaelistria Nov 29, 2021
Collaborator

jcompagner Nov 29, 2021
Author

jcompagner Nov 29, 2021
Author

jcompagner
Nov 29, 2021
Author

laeubi Nov 29, 2021
Maintainer

laeubi
Nov 29, 2021
Maintainer

jcompagner
Nov 29, 2021
Author

laeubi Nov 29, 2021
Maintainer

jcompagner
Nov 29, 2021
Author

laeubi Nov 29, 2021
Maintainer

jcompagner Nov 30, 2021
Author

akurtakov Nov 30, 2021
Maintainer

laeubi Nov 30, 2021
Maintainer

jcompagner Nov 30, 2021
Author

jcompagner
Nov 29, 2021
Author

mickaelistria Nov 29, 2021
Collaborator

mickaelistria Nov 29, 2021
Collaborator

jcompagner
Nov 29, 2021
Author

laeubi
Dec 5, 2021
Maintainer