AFAIK, Maven 3.0.4 is required.
Teo
Ok,
So that is what I tried, but when I got to build with Maven I get this exception
Exception in thread "main" java.lang.NoSuchMethodError: org.apache.maven.execution.MavenSession.getRepositorySession()Lorg/sonatype/aether/RepositorySystemSession;
at org.eclipse.tycho.core.maven.utils.PluginRealmHelper.execute(PluginRealmHelper.java:86)
at org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.getDependencyMetadata(P2TargetPlatformResolver.java:158)
at org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.setupProjects(P2TargetPlatformResolver.java:140)
at org.eclipse.tycho.core.resolver.DefaultTychoDependencyResolver.setupProject(DefaultTychoDependencyResolver.java:76)
at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:56)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:272)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:414)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357)
Any ideas?
This is Maven 3.0.1
jdk1.7.0_21 (64 bit)
We actually fork the CDT for our post Juno SR-2 changes. We clone the repo and make our local changes on a branch. We then build the CDT's p2 repo using Maven. And that feed that into the rest
of our product build chain. As long as you change the qualifier so it's after the CDT's (e.g. prefix them with a letter), you should be able to get your users to point their Eclipse at that repo to get your version.
Patching jar files is probably not the right way to do that.
Hi all,
My company has a custom Eclipse CDT integration for our development environment.
We are using Eclipse Juno with CDT version 8.1.2. We recently encountered 2 core CDT bugs (408525,
407506) which block usage of our plugin.
We have internally patched the associated CDT jars for 8.1.2, but I need a way to easily distribute them throughout our company. Right now we are just naming the jars the same and telling users that they need to
download the jar and copy it to there eclipse directory. This is quite cumbersome, and with over 300 users, it is a bit of a support nightmare.
I was wondering if anyone knew of a way to distribute these patched jars via a feature update site?
I have tried building the jars and making my plugin distribute them, but eclipse wont accept the jar if it is already in the plugin folder with the same name, and if the name is different, the CDT does not recognize
it.