[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [tracecompass-dev] Moving the test traces to a separate project
|
Oh by the way, I hit another problem with the new approach:
https://hudson.eclipse.org/tracecompass/job/tracecompass-gerrit/4027/
The StandardImportAndReadSmokeTest makes uses of one the .tar.gz to test
importing an archive directly. With the new test-traces project, there
are no archives anymore, the jars contain the traces directly. The
tar.gz were just distribution artifacts.
However it's very useful to have a test that tries opening an archive. I
see 2 options:
- Ship a .tar.gz version of that particular trace as part of the
test-traces project.
- Build the tar.gz at the start of the test, and use that for the test
itself.
First option seems like the easiest and most reproducible, however it
would waste a bit of space as a trace would be present twice.
Thoughs?
Cheers,
Alex
On 2015-09-23 10:20 AM, Bernd Hufmann wrote:
Hi Alex
Sorry, for the late response, but I had to work on some other things
that couldn't wait. Thanks for trying to simplify the test traces
handling.
I tried your patch and the new git repository, but I had a hard time
to actually get the Trace Compass (test) projects to compile. First of
all I had to install m2e. I haven't used it for years because of many
issues I ran into. I hope m2e is in much better shape than at that
time. Then I had to figure out how to make the test projects aware of
the test traces. Based on your message on the mailing list, I finally
was able to import it as a maven project. After doing this, a tycho
connector plug-in or something similar needed to be installed (luckily
this was more or less automated). After a full build I didn't have any
compilation error anymore. But, right now I have an issue with EGit
that notifies me that the ctf-testsuite directory has been deleted
which actually is not. Every Trace Compass developer will have to go
through these steps.
I'm not a big fan of depending on m2e directly. It's probably a good
tool for developers to use, but Trace Compass shouldn't depend on it
directly.
Then I was thinking about an alternative. Since you've created a new
git repository for the test traces, why don't you clone the repository
as part of the build process as it is done for the ctf-testsuite? This
could be done as part of a separate test plug-in in the Trace Compass
repository and the Trace Compass test projects can depend on this.
If you want to use the test traces in another project through a maven
dependency, you still can do that by keeping the maven artifacts. The
advantage of this would be that Trace Compass would not be dependent
on m2e and there is no impact of for the developers.
Please let me know what you think about this approach.
Thanks
Bernd
On 09/22/2015 04:26 PM, Alexandre Montplaisir wrote:
Some updates,
I've created a new git repo at:
http://git.eclipse.org/c/tracecompass/tracecompass-test-traces.git/
along with a matching Hudson job:
https://hudson.eclipse.org/tracecompass/view/Misc/job/tracecompass-test-traces-nightly/
which then deploys the jars to:
http://archive.eclipse.org/tracecompass/tracecompass-test-traces/
so far so good!
I then pushed a commit to Gerrit to have Trace Compass depend on the
new project:
https://git.eclipse.org/r/#/c/56466/
The traces are found, however some tests are failing. I can reproduce
it locally when running All*Tests targets. However if I run those
failing tests individually they work fine. There must be something in
one of the early tests that affects the state and makes the rest
fail. I'll look into that next.
Cheers,
Alex
On 2015-09-21 06:14 PM, Alexandre Montplaisir wrote:
Hi Marc-André,
I thought for a bit about using Maven artifacts, aka
<packaging>jar</packaging>, vs
<packaging>eclipse-plugin</packaging>. The second option makes it
easier to integrate on our side, but in the end I still prefer the
first option. I also don't know how to do the equivalent of
"src/main/resources" with Tycho.
The test traces are not specific to Eclipse, they are just a bunch
of files. It's possible to depend on jars from eclipse-plugin's, but
not the other way around AFAIU. By using jar packaging, standard
non-Eclipse projects using Maven can also depend on the test traces.
I had one example in mind: the LTTng-UST Java agent could,
eventually, be such a user.
I would not publish this to Maven Central / Nexus / etc, at least
not initially. Turns out it's very easy to define a custom Maven
repository: you just setup the <distributionManagement> part in the
pom.xml, then "mvn deploy" just copies to the results to the
configured location.
When depending on "jar" packages, you put the dependency directly in
the pom.xml of the projects that need it. I don't it's even possible
to put those in a .target file, the Target Editor only talks about
Plugins. If we changed our "skip build" command (a new profile
maybe?) to completely skip over the test modules, then it should
skip downloading the test traces too, no?
As for use within Eclipse, locally I just import them as a Maven
Project using m2e. It's slightly more setup, but you keep the
flexibility of a basic Maven artifact.
Cheers,
Alex
On 2015-09-21 05:20 PM, Marc-André Laperle wrote:
I don't know about using a Maven artifact. We don't have much
experience in deploying them and it means we will depend on m2e.
Perhaps it would be easier deploying to Eclipse's Nexus, but
getting something in Sonatype's Nexus and promoting it was a lot of
effort when I did a while ago (tycho-eclipserun).
Another concern (even if we don't use the maven artifact) is that
we will have to download traces all the time with this method. I
thought about this: even if we put the plugins as optional, we will
put them in the target, which means they will always be downloaded
anyway.
Perhaps we're OK with both "issues". This is something we'd have to
agree on.
Personally, I think going with Eclipse plugins and downloading them
as part of the target would be probably be OK.
Marc-Andre
________________________________________
From: tracecompass-dev-bounces@xxxxxxxxxxx
[tracecompass-dev-bounces@xxxxxxxxxxx] on behalf of Alexandre
Montplaisir [alexmonthy@xxxxxxxxxxxx]
Sent: Monday, 21 September 2015 5:08 PM
To: tracecompass-dev@xxxxxxxxxxx
Subject: [tracecompass-dev] Moving the test traces to a separate
project
Hi all,
I've struggled with adding a new test trace recently (for the
debug-info
unit tests), and realized that the process is very cumbersome.
Basically
one has to:
- Manually copy the trace to the archive.eclipse.org directory
- Add the trace in about 5 locations in the get-traces.xml script
- Add it to the deletion command in the pom.xml
- Add it to the gitignore
- Expose it in the CtfTestTrace and CtfTmfTestTraces files
It's also quite messy, some are compressed with tar.bz2, others with
zip, which don't require the same Ant commands. Some traces are not
named the same as the archive they are in. Some archives contain more
than one trace. There is also no easy way of just downloading the test
traces without running the tests.
I came to the realization we could instead ship the test traces as a
separate project, a standalone Maven artifact. The test traces
would be
put in a jar, which also does compression. We could then use the
concept
of Java resources to access them. This will, after all, allow using
FileLocator from within the Eclipse code!
This will also allow removing all the assumeTrue(trace.exists()) calls
we do now, since if the plugin is there the trace will necessarily be
present.
I've done some initial prototyping and the dependency resolution seems
to work well. Next I'll make sure the tests still actually pass...
Any thoughts before I continue moving forward with this?
Cheers,
Alexandre