Clean Initial setup has clone with changes

[merks]

Is it normal/expected that the initial clone has changes?

How are warnings managed for the project? We just don't worry about them? Should we change preferences to ignore ones we don't care about?

[laeubi]

Is it normal/expected that the initial clone has changes?

It depends a bit about used m2e version, java installation, so in general you can "assume unchanged" them in git, or look if it makes sense to have these settings and commit them along with your PR.

How are warnings managed for the project? We just don't worry about them? Should we change preferences to ignore ones we don't care about?

We try to fix them when one comes along but in general don't worry about them (much) not sure if they are even suppressible as some refer to the build config of maven, where we need to still cleanup things after some larger refactorings..

[Bananeweizen]

Ed, one of the main problems for the modification state is that if you have some Java version problem or maven dependency resolution issue during the very first (automatically triggered) build, then m2e will modify the .classpath files wrongly, basically removing the parts that don't resolve etc. For the m2e.prefs, I believe those should be checked in, but there are different opinions by others here, AFAIK.

You already see much less warnings than some weeks ago, trust me. :) But I still have trouble finding solutions for some of them.

[merks]

When I got rid of all the .classpath changes my workspace was a mess of errors and after that a clean build did not fix the errors. I deleted the projects and performed the maven import task again to get back to a non-error state...

[HannesWell]

I think we should enhance M2E to generate all the .classpath (and .settings) files properly so that they can be fully ignored.
Haven't checked it yet, but the recent changes in M2E are maybe already sufficient to remove the recently added metadata again.

[HannesWell]

Created #1740.
With that my Git staging area remains empty when importing all projects.

[merks]

Do you have any idea what this would fail? I'd like to be able to do the whole build locally...

[INFO] --- maven-invoker-plugin:3.3.0:run (integration-test) @ tycho-document-bundle-plugin ---
[INFO] Building: additionalDepsTest\pom.xml
[INFO] run post-build script verify.groovy
[INFO]   java.io.FileNotFoundException: D:\Users\merks\tycho-master\git\tycho\tycho-extras\tycho-document-bundle-plugin\target\it\additionalDepsTest\doc.bundle\target\javadoc.options.txt (The system cannot find the path specified)
[INFO]           additionalDepsTest\pom.xml ....................... FAILED (4.0 s)
[INFO] Building: test1\pom.xml
[INFO] run post-build script verify.groovy
[INFO]   java.io.FileNotFoundException: D:\Users\merks\tycho-master\git\tycho\tycho-extras\tycho-document-bundle-plugin\target\it\test1\docbundle1\target\javadoc.options.txt (The system cannot find the path specified)
[INFO]           test1\pom.xml .................................... FAILED (4.9 s)
[INFO] -------------------------------------------------

[laeubi]

There should be a hint to a logfile somewhere around this error that (hopefully) contains more details.

Beside that, running the full integration test suite normally takes very long and requires some special setup (e.g. you should configure Java 8, 11, 17 in your toolchains for best interoperability).

It is therefore acceptable to run mvn clean install -T1C -Dtycho.localArtifacts=ignore first and let the Jenkins/Github verify the full suite of tests. If then only a few fail, one can better run them individually. Also we sadly have sometimes test that (randomly?) fail on windows just in case ...

[merks]

I ran what you suggested and that worked... Yeah, one step forward.

I'd like to make changes to org.eclipse.tycho.gpg.SignRepositoryArtifactsMojo and of course I'd like to test them locally to verify the changes are correct and to refine the implementation details. Best would be to be able to run it under debug control. Is there such a test that I've overlooked? And a way to debug too?

I read about how to run tests in the CONTRIBUTING.md but no tests run for and neither of m2 launches work. Copying and pasting console text is not nice because of the ANSI characters. It looks pretty though. I think this needs to work before I can run a test...

I feel a bit lost when nothing seems to just work. Probably there are many things that should be obvious that are to me a mystery...

[laeubi]

You can disable color output in the run config of m2e.

The usual way for running/debugging I uses is the following:

1. Build with the mentioned command so I have everything build.
2. The go to tycho-its/projects and create a new demo-project that is as small as possible to test my changes.
3. Then wen I need to debug, I add options to the maven run that enables java remote debugging and then I attach the debugger to it (running my created demo project like it would run a usual maven build)
4. When I'm fine with that, I look for a testcase in tycho-its/src/... where I can add a new method or just create a new one (see
   provide an integration-test for a template), add what I think should be asserted (e.g. produced files or output in the log)
5. Then you can run this individual test with (working folder = tycho-its) mvn clean install -Pits -Dtest=<fqn class name of test> to see it passes.

[merks]

@laeubi Thanks! I got it working and am happily debugging now!!

[laeubi]

@merks It would be great to enhance the CONTRIBUTING.MD with any information you might find useful for other contributors as well! It is often better if documentation is written by users as they better know what needs explained in what detail.

[merks]

A very good point!