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

>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



Back to the top