| Re: [cdt-dev] Distribution of custom patches. |
|
Maybe try 3.0.4. Not sure if 3.1 broke anything.
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Joseph Henry [Joseph.Henry@xxxxxxx]
Sent: Friday, July 19, 2013 10:36 AM To: CDT General developers list. Subject: Re: [cdt-dev] Distribution of custom patches. Sorry,
Maven is 3.1.0 not 3.0.1
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Doug Schaefer
I didn't think that but maybe.
Sent from my BlackBerry 10 smartphone on the Rogers network.
AFAIK, Maven 3.0.4 is required. Teo
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Joseph Henry
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)
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Doug Schaefer
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.
Doug.
From: Joseph Henry <Joseph.Henry@xxxxxxx>
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. |