Change versions to 0.1.0

Change-Id: I58549b2ca6ef460cc3a0e073c62194a3053ac7fa
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/36166
Tested-by: Hudson CI
Reviewed-by: Bernd Hufmann <bernd.hufmann@ericsson.com>
Tested-by: Bernd Hufmann <bernd.hufmann@ericsson.com>
tmf: Add element to its parent's children automatically and remove setChildren

Also, add a few useful setters.

Change-Id: I8ae7cff34d9a066d0ce9d17ef555e5539a3dc55c
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/35916
Tested-by: Hudson CI
Reviewed-by: Matthew Khouzam <matthew.khouzam@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/36177
Add some missing NonNull annotation "imports"

Now needed indirectly by some analysis modules in plugins that
didn't have it before.

Change-Id: I56bbf6e39290b83f9dce7a6852e7529fbd46c15b
Signed-off-by: Alexandre Montplaisir <alexmonthy@voxpopuli.im>
Reviewed-on: https://git.eclipse.org/r/36206
Tested-by: Hudson CI
Reviewed-by: Matthew Khouzam <matthew.khouzam@ericsson.com>
lttng: Do not rebuild the SS in every single state system test

At some point we changed the state system tests to rebuild the whole
thing in the @Before, because at that point AssumeTrue() inside a
@BeforeClass did not work very well. Unfortunately this made running
the tests much longer.

Instead, really build the analysis/state system once per test class,
but only keep the AssumeTrue() in the main @Before that is ran every
test. That check will test a static boolean set by the @BeforeClass.

tl;dr Make the state system tests ~20 times faster.

Change-Id: I96a137e0d2ec871f92efe586ba6456aca0a61129
Signed-off-by: Alexandre Montplaisir <alexmonthy@voxpopuli.im>
Reviewed-on: https://git.eclipse.org/r/36184
Tested-by: Hudson CI
Reviewed-by: Matthew Khouzam <matthew.khouzam@ericsson.com>
Tested-by: Matthew Khouzam <matthew.khouzam@ericsson.com>
Use archive.eclipse.org for the test traces

Change-Id: I871e2ec18b2d385bf9289d33d0b368919cc9da21
Signed-off-by: Alexandre Montplaisir <alexmonthy@voxpopuli.im>
Reviewed-on: https://git.eclipse.org/r/36203
Tested-by: Hudson CI
Reviewed-by: Matthew Khouzam <matthew.khouzam@ericsson.com>
tmf: Consolidate constructors in TmfEvent

The default constructor can be used by the ITmfEvent extension
point, so should remain available, but should not be used by
normal code.

Change-Id: Id0e5e6d35d5593852b2a89672efea4fcbcd5b948
Signed-off-by: Alexandre Montplaisir <alexmonthy@voxpopuli.im>
[RFC] tmf: Remove source and reference from ITmfEvent

Those two notions were originally meant to have every trace type give
them a specific meaning, but to have some "common" concepts tha
 would be shown in the default event table.

Now that we have the possibility to aggregate columns in the event
table from multiple trace types, there is no need for those vague
concepts anymore. Every trace is free to implement and show any
specific item it wants. The base interface should be for the absolute
minimum that is required by the framework.

In fact, the notions of "source" and "reference" already meant different
things for different trace types (the Source of a CTF event was the source
CPU, while the source of a pcap event was the source address). So these
should *not* be aggregated in the same event columns since they do not
represent the same concepts.

Note: For the trace types that did make use of the source and reference
fields, this patch simply adds new fields to those traces, with the
names "source" and "reference" for now. But now that they will be decoupled
from the interface, we will be free to rename them accordingly.

Change-Id: I84f9729edee64233893779ca9c375a0a157bfc84
Signed-off-by: Alexandre Montplaisir <alexmonthy@voxpopuli.im>
WIP tmf: Introduce the core concept of event criterion

A criterion (plural criteria), in the sense of a "characterizing mark
of something", is a piece of information that can be extracted, directly
or indirectly, from a trace event.

Simple examples could be timestamp, or event fields. But it could also
be something like a state system request, at the timestamp of the given
event.

This patch introduces the base ITmfEventCriterion interface, some basic
criterion implementations, and simplifies the TmfEventTableColumns to
use criteria instead, since part of it is now redundant.

Change-Id: Ib045439d6084a6e6c7c276f1eddccfb13fe01be0
Signed-off-by: Alexandre Montplaisir <alexmonthy@voxpopuli.im>