Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-dev] Extending Tycho to support more Eclipse Plugins Types

So I made decent progress on this today. You may notice my configuration for the plexus-component-metadata was wrong. I had the goals, but needed to wrap them in <executions><execution> tags. After that I saw the info in components.xml was auto-generated, which is what I had expected originally.

So now I see my class is being invoked. I had to make a change in P2DependencyResolver to skip trying to resolve dependency metadata for projects it does not understand, as P2GeneratorImpl only works if invoked on a standard Eclipse packaging type, otherwise it throws IllegalArgumentException. I would share a patch for this, but before I do that, I am hitting a ClassCastException, which as far as I can tell implies my Maven plugin Mojo is running in a different Classpath container from Tycho classes.

In my Maven plugin Mojo I call TychoProjectUtils.getDependencyArtifacts(project) line 174:

173 EquinoxInstallationDescription generationRuntime = new DefaultEquinoxInstallationDescription();
174 DependencyArtifacts dependencyArtifacts = TychoProjectUtils.getDependencyArtifacts(project);
175 for (ArtifactDescriptor descriptor : dependencyArtifacts.getArtifacts()) {
176   addArtifact(generationRuntime, descriptor);
177   getLog().info("Adding dependency artifact: " + descriptor + " type="+ descriptor.getKey().getType());
178 }
179
180 EquinoxInstallation install = installationFactory.createInstallation(generationRuntime, work);
181 boolean succeeded = execRuntime(install);


But this line throws a ClassCastException internally:
Caused by: java.lang.ClassCastException: org.eclipse.tycho.core.osgitools.targetplatform.MultiEnvironmentDependencyArtifacts cannot be cast to org.eclipse.tycho.artifacts.DependencyArtifacts
	at org.eclipse.tycho.core.utils.TychoProjectUtils.getDependencyArtifacts(TychoProjectUtils.java:37)
	at org.eclipse.tigerstripe.maven.generation.TigerstripeGenerationMojo.execute(TigerstripeGenerationMojo.java:174)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)


But looking at tycho-core source code I see MultiEnvironmentDependencyArtifacts does implement DependencyArtifacts class, hence why I imagine the two classes must be on different class loaders.

Can you share any background on the Tycho classloader, and why a Maven mojo is not able to access the Tycho classes in this way? I will keep doing some digging to see if I can find what the two class loaders are.

Thanks,
Daniel



On 7/29/15, 11:20 AM, "Daniel Johnson (danijoh2)" <danijoh2@xxxxxxxxx> wrote:

>Hi Jan, Igor,
>
>I created a new class:
>package org.eclipse.tigerstripe.tycho.resolver;
>…
>
>@Component(role = P2MetadataProvider.class, hint = "tigerstripe-module")
>public class TigerstripeP2MetadataProvider implements P2MetadataProvider, Initializable {
>
>  @Requirement
>  EquinoxServiceFactory equinox;
>
>  @Requirement
>  Logger logger;
>
>  private DependencyMetadataGenerator generator;
>
>  @Override
>  public Map<String, IDependencyMetadata> getDependencyMetadata(MavenSession session, MavenProject project,
>    List<TargetEnvironment> environments, OptionalResolutionAction action) {
>
>      logger.info("Configuring Tigerstripe Project: “ + project.getBasedir().getAbsolutePath());
>      Map<String, IDependencyMetadata> metadata = new LinkedHashMap<String, IDependencyMetadata>();
>      return metadata;
>  }
>
>  public void initialize() throws InitializationException {
>      this.generator = equinox.getService(DependencyMetadataGenerator.class,
>        "(role-hint=dependency-only)");
>  }
>
>}
>
>
>And defined in my components.xml:
><component>
>  <role>org.eclipse.tycho.p2.resolver.P2MetadataProvider</role>
>  <role-hint>tigerstripe-module</role-hint>
>  <implementation>org.eclipse.tigerstripe.tycho.resolver.TigerstripeP2MetadataProvider</implementation>
>  <isolated-realm>false</isolated-realm>
>  <requirements>
>    <requirement>
>      <role>org.eclipse.sisu.equinox.EquinoxServiceFactory</role>
>      <role-hint />
>      <field-name>equinox</field-name>
>    </requirement>
>    <requirement>
>      <role>org.codehaus.plexus.logging.Logger</role>
>      <role-hint></role-hint>
>     <field-name>logger</field-name>
>    </requirement>
>  </requirements>
>		</component>
>
>
>I have my build plugins components.xml under src/main/resources/META-INF/plexus/components.xml, and have defined the following build plugin:
><plugin>
>  <groupId>org.codehaus.plexus</groupId>
>  <artifactId>plexus-component-metadata</artifactId>
>  <goals>
>    <goal>generate-metadata</goal>
>  </goals>
></plugin>
>
>
>But still when building a project with this plugin I do not see my metadata resolver class being invoked during project scanning:
>DANIJOH2-M-V0MA:Test danijoh2$ mvn clean install
>[INFO] Scanning for projects...
>[INFO]                                                                         
>[INFO] ------------------------------------------------------------------------
>[INFO] Building Test 0.0.1-SNAPSHOT
>[INFO] ------------------------------------------------------------------------
>[INFO] 
>[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ Test ---
>...
>
>
>I expected to see the info printout "Configuring Tigerstripe Project: …”. Any idea what I missed that is not having my custom provider to be invoked for a POM with packaging type ‘tigerstripe-module’?
>
>Thanks,
>Daniel
>
>
>
>
>
>On 7/29/15, 8:22 AM, "tycho-dev-bounces@xxxxxxxxxxx on behalf of Daniel Johnson (danijoh2)" <tycho-dev-bounces@xxxxxxxxxxx on behalf of danijoh2@xxxxxxxxx> wrote:
>
>>Yes, that bug sounds like it is meant to address this sort of thing. I will do some digging into what Igor has provided so far, and see if I can’t figure out where this stands.
>>
>>Thanks!
>>Daniel
>>
>>
>>
>>
>>On 7/29/15, 12:36 AM, "tycho-dev-bounces@xxxxxxxxxxx on behalf of Sievers, Jan" <tycho-dev-bounces@xxxxxxxxxxx on behalf of jan.sievers@xxxxxxx> wrote:
>>
>>>>My question then, is there any way to provide contributions to customize Tycho’s dependency resolution capabilities for third-party eclipse project types?  
>>>
>>>The enhancement https://bugs.eclipse.org/bugs/show_bug.cgi?id=364983 is still open (and it looks like noone has been working on it for a long time)
>>>Not sure if this would fit your usecase.
>>>
>>>For now you essentially forked Tycho and I'm afraid we can't help you maintain the fork.
>>>
>>>Regards
>>>Jan
>>>
>>>
>>>From: tycho-dev-bounces@xxxxxxxxxxx [mailto:tycho-dev-bounces@xxxxxxxxxxx] On Behalf Of Daniel Johnson (danijoh2)
>>>Sent: Mittwoch, 29. Juli 2015 00:58
>>>To: tycho-dev@xxxxxxxxxxx
>>>Cc: tycho-user@xxxxxxxxxxx
>>>Subject: [tycho-dev] Extending Tycho to support more Eclipse Plugins Types
>>>
>>>Hi,
>>>
>>>I suspect this will be more a question for tycho-dev folks, but cc’ing tycho-user mailer in case some of you have encountered this use-case before.
>>>
>>>~5 years ago, around tycho 0.11.0 release, a fellow co-worker of mine developed a maven plugin for building Tigerstripe eclipse plugins leveraging Tycho. He was able to extend Tycho to support projects with packaging type ‘tigerstripe-module’ by creating a new Plexus Component of type OsgiBundleProject with a component role of TychoProject and a hint of 'tigerstripe-module’:
>>>----------------
>>>import org.codehaus.plexus.component.annotations.Component;
>>>import org.eclipse.tycho.core.TychoProject;
>>>import org.eclipse.tycho.core.osgitools.OsgiBundleProject;
>>>@Component(role = TychoProject.class, hint = "tigerstripe-module")
>>>public class TigerstripeModuleProject extends OsgiBundleProject {
>>>
>>>    public void setupProject(MavenSession session, MavenProject project) {
>>>        getLogger().info(
>>>                "Configuring Tigerstripe Project: "
>>>                        + project.getBasedir().getAbsolutePath());
>>>        ...    
>>>    }
>>>    ...
>>>}
>>>----------------
>>>
>>>This type of project is unique in that some dependency information is listed in a Tigerstripe specific file called tigerstripe.xml, so during the set-up of the project and during classpath resolution some code was introduced to parse the tigerstripe.xml and introduce the correct classpath entries.
>>>
>>>Likewise the plexus components.xml was updated to define the new artifact handler and lifecycle mapping:
>>>---------------- 
>>><component>
>>>    <role>org.apache.maven.artifact.handler.ArtifactHandler</role>
>>>    <role-hint>tigerstripe-module</role-hint>
>>>    <implementation>org.apache.maven.artifact.handler.DefaultArtifactHandler</implementation>
>>>    <configuration>
>>>        <classifier />
>>>        <extension>jar</extension>
>>>        <type>tigerstripe-module</type>
>>>        <packaging>tigerstripe-module</packaging>
>>>        <language>java</language>
>>>        <addedToClasspath>true</addedToClasspath>
>>>        <includesDependencies>false</includesDependencies>
>>>    </configuration>
>>></component>
>>><component>
>>>    <role>org.apache.maven.lifecycle.mapping.LifecycleMapping</role>
>>>    <role-hint>tigerstripe-module</role-hint>
>>>    <implementation>org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping</implementation>
>>>    <configuration>
>>>      <lifecycles>
>>>        <lifecycle>
>>>            <id>default</id>
>>>            <phases>
>>>...
>>>            </phases>
>>>        </lifecycle>
>>>      </lifecycles>
>>>    </configuration>
>>></component>
>>>---------------- 
>>>
>>>Finally, it contained a ArtifactKeyFactory implementation to define the tigerstripe-module type:
>>>---------------- 
>>>import org.codehaus.plexus.component.annotations.Component;
>>>import org.codehaus.tycho.osgitools.DefaultArtifactKeyFactory;
>>>import org.sonatype.tycho.ArtifactKeyFactory;
>>>
>>>@Component( role = ArtifactKeyFactory.class )
>>>public class TigerstripeArtifactKeyFactory extends DefaultArtifactKeyFactory {
>>>
>>>    public static final String TYPE_TIGERSTRIPE_MODULE = "tigerstripe-module";
>>>
>>>    public static final String[] PROJECT_TYPES = { TYPE_TIGERSTRIPE_MODULE };
>>>
>>>    public String[] getEclipsePluginTypes() {
>>>        return PROJECT_TYPES;
>>>    }
>>>}
>>>---------------- 
>>>
>>>With the old version of the plugin using tycho 0.11 I see that the project is configured right at the beginning of the build, just as Maven is scanning for projects to build:
>>>DANIJOH2-M-V0MA:Test2 danijoh2$ mvn clean install
>>>[INFO] Scanning for projects...
>>>[INFO] Configuring Tigerstripe Project: /Users/danijoh2/Workspaces/Fault/Test2
>>>[WARNING] No explicit target runtime environment configuration. Build is platform dependent.
>>>[INFO] Resolving target platform for project MavenProject: com.cisco.xmp:Test2:0.0.1-SNAPSHOT @ /Users/danijoh2/Workspaces/Fault/Test2/pom.xml
>>>[INFO] Starting resolution of Tigerstripe Implementation Model
>>>[INFO]                                                                         
>>>[INFO] ------------------------------------------------------------------------
>>>[INFO] Building Test2 0.0.1-SNAPSHOT
>>>
>>>
>>>However, after trying to upgrade to Tycho 0.23.0 (and re-factoring a lot of code, since tycho classes had moved under org.eclipse namespace) , I see that the project is not set-up at all, and it doesn’t even seem that Tycho is running its magic:
>>>DANIJOH2-M-V0MA:Test danijoh2$ mvn clean install
>>>[INFO] Scanning for projects...
>>>[INFO]                                                                         
>>>[INFO] ------------------------------------------------------------------------
>>>[INFO] Building Test 0.0.1-SNAPSHOT
>>>
>>>My question then, is there any way to provide contributions to customize Tycho’s dependency resolution capabilities for third-party eclipse project types?  
>>>
>>>It seems that the DefaultArtifactKeyFactory and ArtifactKeyFactory classes have been removed and replaced with ArtifactType and PackagingType in tycho.embedder.shared - http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.tycho/org.eclipse.tycho.embedder.shared/0.23.0/org/eclipse/tycho/PackagingType.java
>>>So I had to remove that class from the source code, but other than that the transformation went pretty smooth.
>>>
>>>I just don’t understand what I changed/broke that causes the build to no longer invoke the setupProject() method of the contributing TychoProject (read: TigerstripeModuleProject) class, unless newer versions of Tycho simply cannot be extended in this way?
>>>
>>>Thanks,
>>>Daniel
>>>
>>>
>>>_______________________________________________
>>>tycho-dev mailing list
>>>tycho-dev@xxxxxxxxxxx
>>>To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>>>https://dev.eclipse.org/mailman/listinfo/tycho-dev
>>_______________________________________________
>>tycho-dev mailing list
>>tycho-dev@xxxxxxxxxxx
>>To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>>https://dev.eclipse.org/mailman/listinfo/tycho-dev

Back to the top