[
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
|
On 09/23/2015 01:11 PM, Alexandre Montplaisir wrote:
Hi Bernd,
Thanks for trying it out!
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.
Since it's a Maven project, if you want to load these projects in
Eclipse, m2e is the easiest solution. I also had very bad experiences
with m2e years ago, but it didn't seem too bad this time around.
However, if a developer does not want to modify the test-traces
project directly, ideally they should not have to load it in Eclipse
at all. I'm wondering if there could be a way where the in-Eclipse
build process somehow gets these traces. Something like Java Build
Path -> Add External Jar ?
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.
That's probably because your EGit was previously aware of the .git in
ctf.core.tests/traces/ctf-testsuite that was there before, which has
now been moved to the new project.
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.
What do you mean by "depending directly" here? m2e is not required at
build time, and won't be part of the RCP etc.
If a developer wants to load the tracecompass-test-traces source into
Eclipse, they will have to install m2e, that is pretty much unavoidable.
But if a developer only wants to load the Trace Compass source,
ideally they should not have to use m2e either, I agree.
When loading your patch, then all relevant test projects have
compilation errors in Eclipse. The only way I was able to get rid of
these error to clone the tracecompass-test-traces git and import them as
maven project. This requires m2e. Is there another way?
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.
Which build process are you referring to here? The Maven one, of the
in-Eclipse (PDE) one?
That's not the point here. Maven has for sure advantages. The point is
that, don't there shouldn't be any compilation errors when importing the
Trace Compass source code into the workspace and the only way to fix it
is using m2e.
For Maven I think it's handled very well, the dependency and
repository are defined in the project's pom.xml, and it gets
downloaded automatically when needed.
For Eclipse it's a bit more problematic. I don't think it's very
useful to clone the source git tree, the test code needs the jars so
we can use getClass().getResource() and FileLocator (which was the
main drive behind this change!). And we have jars built already.
Having a separate git is probably a good start. Building an update site
for that and adding them to the target definition could be another way
(I think Marc-Andre mentioned that)
I'll try to find a solution. I have a couple ideas in mind.
Cheers,
Alex
