Lb issue 16 xtext maven plugin its #17
Conversation
I think it's better to fail immediately instead of the end of long build
and run integration tests against the segregated local repository
looks like we save a few minutes
I think it's better to fail immediately instead of the end of long build
This way, we are sure we using our JARs in ITs.
This reverts commit 612117e.
| @@ -110,6 +115,21 @@ | |||
| <version>${project.version}</version> | |||
| <scope>test</scope> | |||
| </dependency> | |||
| <!-- Needed by some of our IT projects: | |||
There was a problem hiding this comment.
wonder why these are not accessible if just mention in the tests pom
There was a problem hiding this comment.
is this cause of upstream repos not availble in mono build
There was a problem hiding this comment.
My intention and understanding of integration tests for maven plugins are that our artifacts should NOT be downloaded from remote repositories; this way, we're sure we're testing the integration projects with our current artifacts (the ones built from the current sources). Now that we're on a single project, this makes sense.
That's why we use the invoker plugin to create a self-contained .m2 repo with the needed Xtext artifacts.
Note that in the IT projects I've disabled completely sonatype snapshots, I only left lsp4j taken from JIRO.
This way, we're sure that we are self-contained concerning our artifacts.
In general, despite split or mono repo, we made a terrible mistake in not using another .m2 repository for running integration tests, risking of corrupting the current .m2 repo.
Does that answer your question? Or did you mean something else?
|
@cdietrich @szarnekow I'd like to merge this ASAP so that I can go experimenting with the release process |
|
@LorenzoBettini propose to merge. @szarnekow also can comment "after the fact" |
Closes #16