[
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
|
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
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
