Skip to main content

[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

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


Back to the top