See my comments inline
sandraB wrote:
It's one of the solution I imagined to use. But How did you identify the
three plugins builded? I imagine to add another property like
-Declipse.version=3.3 and to use it in the artifactId ?
Not sure what you're trying to achieve. If you build your artifacts from
the same source code, why would you want to name them differently? At
least in our case, we build against multiple target platforms to ensure
code compatibility with different eclipse versions. We use results from
one of the build and discard the others (assuming there are no test
failures).
I found another issue : it's not possible to use directly the goal mvn test.
Is it normal ?
This is one of current Tycho limitations. It is theoretically possible
to share artifacts via local/remote maven repositories, but this is
rather tedious to setup. I have some ideas how to improve this, but have
not had time to prototype/implement this yet.
Igor Fedorenko-4 wrote:
This is what we have in our Hudson instance
(http://ci.sonatype.org/view/m2eclipse/) -- we setup two separate jobs,
one with -Dtycho.targetPlatform=<e33-path> and the other with
-Dtycho.targetPlatform=<e34-path>. Otherwise, job configuration is
identical.
Couple of other notes.
Hudson built-in maven support does not work with Tycho yet, so you need
to use freestyle job type and invoke tycho directly.
This is not tycho specific, but depending on how you start Hudson, you
may experience odd jvm crashes due to missing environment variables.
Also, in order to run UI tests on Linux/Unix, we use xvfb "fake" X11
server.
sandraB wrote:
Hi Igor,
I want to build an eclipse plugin in a integration continu framework
(Hudson) for three versions of eclipse (3.2, 3.3. et 3.4) with the same
src.
I'm looking for a technical solution.
Now, I can build one jar for a version (using the -Dtycho.targetPlatform
property) but I wanted to build three jars for the three versions.
Can you help me to resolve this feature ?
Sandra
Igor Fedorenko-4 wrote:
Sandra,
Can you provide more details about your plugin(s) and what you are
trying to achieve with tycho?
We are successfully using Tycho to build and test m2e against eclipse
3.3 and eclipse 3.4 target platforms, so this is certainly possible. I
can explain how these builds are setup, if you are interested.
Also, the latest Tycho DEV build already includes fix for wrong handling
of link relative paths, so this should not be a problem either.
--
Regards,
Igor
sandraB wrote:
Hi,
What's news about this issue ? I'm facing the same features : I need to
deploy plugin for eclipse 3.2, 3.3 and 3.4 with Tycho and I don't realy
know
how to do it. Could you give me more informations ?
Thanks in advance
Sandra
Igor Fedorenko-4 wrote:
Hi Igor,
here is an example of the layout I use :
http://bewarethepenguin.blogspot.com/2008/10/relative-paths-in-eclipse-link-files.html
I works very well we I use it with eclipse, but doesn't with Tycho.
If I follow your example It works with Tycho but it does not work
anymore
with eclipse.
The problem is I have to replace "path=../3.3.2" with
"path=../../3.3.2/eclipse" (as an example).
for Tycho to find the plugins.
Right, target platform basedir used by tycho to dereference relative
paths
was one level off. This should be fixed in the trunk now and the fix
will
be included in the next DEV build (hopefully day after tomorrow). If
you
still have problems with relative paths in .link files, please feel
free
to reopen MNGECLIPSE-1046 I've created to track this problem.
I agree is it not a good idea to have support for multiple
installation
eclipse installation. By the way does it make sense to "assemble"
(maven
assembly plugin) multiple binaries for multiple target Platform for a
unique
groupID/artifactID ?
I am not sure I understand what you're accomplish. Can you provide
more
details?
Have a good week end.
Igor Fedorenko-4 wrote:
tycho is expected to follow links. can you please submit a bugreport
in
JIRA [1] and provide description of your eclipse installation
layout.
Also see [2] for eclipse installation layouts we're testing tycho
with.
At this point I am reluctant to add direct support for multiple
eclipse
installation folders in pom.xml to be honest.
[1] http://jira.codehaus.org/browse/MNGECLIPSE
[2]
http://svn.sonatype.org/m2eclipse/tycho/trunk/tycho-osgi-components/src/test/resources/targetplatforms
Hi,
thanks to the "tycho164" sample i succeed in building my artifacts
using
some in the maven repo.
Now, i have an artifact containing eclipse SDK which provide my
"basic"
target platform.
I'd like to aggregate another target platform containing some
"corporate"
plugins.
I use the "link" technique to merge both directory as a target
platform.
Tycho doesn't seem to use the "links" i create.
So, as a workaround I tried to declare 2 "eclipse-installation" in
my
pom
file like this :
dependency>
<!-- needed to make maven core happy only, not
used by tycho
-->
<groupId>corporate.com</groupId>
<artifactId>mycorporateplugins</artifactId>
<version>0.0.0</version>
<!-- important stuff -->
<type>eclipse-installation</type>
<scope>system</scope>
<systemPath>H:\targetPlatforms\corp\eclipse</systemPath>
</dependency>
<dependency>
<!-- needed to make maven core happy only, not
used by tycho
-->
<groupId>eclipse.org</groupId>
<artifactId>targetplatform</artifactId>
<version>0.0.0</version>
<!-- important stuff -->
<type>eclipse-installation</type>
<scope>system</scope>
<systemPath>H:\targetPlatforms\3.3.2\eclipse</systemPath>
</dependency>
But i went trow a
"org.codehaus.tycho.osgitools.targetplatform.TargetPlatformException"
Do you plan to use the "links" or to give the possiblility to use
several
"eclipse-installation" in the pom ?
stack Trace :
org.codehaus.tycho.osgitools.targetplatform.TargetPlatformException
at
org.codehaus.tycho.osgitools.targetplatform.EclipseTargetPlatformFactory.getEclipseInstallation(EclipseTargetPlatformFactory.java:147)
at
org.codehaus.tycho.osgitools.targetplatform.EclipseTargetPlatformFactory.createTargetPlatform(EclipseTargetPlatformFactory.java:48)
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
