spideruci / tacoco

Integrated Software Analysis Framework
https://github.com/spideruci/tacoco
MIT License
8 stars 7 forks source link

Running Maven Install/GradleBuild from tacoco on SUTs with no target folders present #67

Open tariq1890 opened 8 years ago

tariq1890 commented 8 years ago

Can we add logic to invoke Maven install or Gradle Build on target projects that don't have a target folder with generated classes? We can achieve this using Maven Embedder and Gradle Tooling API.

I think this would be a nice-to-have feature when you have to navigate to and build/install your project that was cleaned or just checked out.

junghuk commented 8 years ago

I have a bash script, which downloads a project from github, build it and run Tacoco. I think building project is separated process from Tacoco.

Because when build a project, some requires more than "mvn compile". So build part should be flexible and scripting is more suitable to handle this flexibility.

tariq1890 commented 8 years ago

Two reasons why I am suggesting this

  1. Implementing a build/compile task invocation via tacoco is a cross-platform solution. Bash scripts would work only on UNIX-based OS's.
  2. For Build Probe test cases, we may need to run such scripts, which is fine if we run test cases only on our local systems. Should we need to have these test cases run on a CI system (like Travis, Coveralls etc.) I believe building via tacoco would be a better solution. Please let me know if I have missed anything here.

I understand more flexibility is required here. But a simple compile/build task would suffice for 95% of the projects out there. It certainly makes a tacoco user's life easier :)

VijayKrishna commented 8 years ago

One thing to consider for this feature is the whole point and promise of Tacoco. Tacoco promises that given an already successful build for a given project, it will enable the platform to create analyses of the build and the execution of the build.

That said, if we very carefully craft this feature to clearly reflect it as a utility only and not a central feature, then i think we can have this feature.

tariq1890 commented 8 years ago

Sure, Vijay. Tacoco can always recommend that the SUTs are fully built. So keeping that in mind, We can trigger compile tasks as fire-and-forget.

If there are no generated classes, we can trigger the compile tasks. The end result of this operation would be of no consequence to the other workflows of tacoco. Exceptions, if at all they appear while invoking the compile/build task, will be ignored in this case.

VijayKrishna commented 8 years ago

I am not sure what you mean by "fire-and-forget" or "end result of this operation would be of no consequence to the other workflows of tacoco". Tacoco's workflow is highly dependent on the output of a project build -- if the build is faulty the subsequent analysis ought to be meaningless.

Running an automated project build with the help of a shell script has the advantage that it is clear that is a utility (the running of the project build), and not an actual feature of Tacoco.

Also, using a scripting language allows us to quickly experiment with strange build processes that may require us to run more than mvn compile && mvn test.

So, perhaps if we can find a way to program this in such a way that it still looks like a utility and has the flexibility of quick experimentation. Perhaps using a cross platform scripting language like groovy/python/ruby?

tariq1890 commented 8 years ago

I was thinking of using MavenEmbedder and Gradle Tooling API to invoke the build tasks. My intention is to just generate the classes and test classes if they are not present. So that tacoco analysis may continue despite their absence

tariq1890 commented 8 years ago

and of course make unit testing of the BuildProbes possible. If we do use a script utility , would we able to integrate it into a CI system ?

(I see that we have different goals in mind here)

junghuk commented 8 years ago

It would be nice if we integrate Tacoco with CI, such as TravisCI. @tariq1890 you may create travis.yml if you want.

About the build support, I think it is related to GIT Analyzer, on issue #63. Here's a scenario,

  1. choose a SUT.
  2. probe git and grep commits and diffs.
  3. build each commits
  4. compare differences.

in step2, we may utilize Tacoco's building ability.

tariq1890 commented 8 years ago

@junghuk Have a look at this project .https://github.com/MetricsGrimoire/CVSAnalY.

Would this help ?

junghuk commented 8 years ago

@tariq1890 thanks for the link. I originally think about this one, JGIT. http://www.eclipse.org/jgit/

CVSAnalY seems feasible, but it is python and may have integration issues with Tacoco.