Community
Participate
Working Groups
There is no good reason to have missing entries in build.properties.
trying to make the requirements more precise: - at packaging time (PackagePluginMojo), each bin.includes value must match at least one existing file or dir (except for "." for which an entry "source..=" must exist). Note that values can be ant file patterns. Check is done after any nested jars are already created. - at packaging time (OsgiSourceMojo), each value of "src.includes" must match at least one existing file or dir. Note that values can be ant file patterns. - at compile time (OsgiCompilerMojo), values of all entries starting with "source." must be existing directories Failure of these validations will fail the build.
(In reply to comment #1) > - at compile time (OsgiCompilerMojo), values of all entries starting with > "source." must be existing directories non-existing source dirs are ignored with a warning by maven-compiler-plugin so probably no point to be any stricter here.
(In reply to comment #2) > (In reply to comment #1) > > - at compile time (OsgiCompilerMojo), values of all entries starting with > > "source." must be existing directories > > non-existing source dirs are ignored with a warning by maven-compiler-plugin so > probably no point to be any stricter here. Why tolerate garbage in build.properties? Can you think of a usecase when this would be of any benefit?
What does the PDE headless build do in such a case? @Igor: Are there projects with missing source folders in the Eclipse Platform? Do these have correct build.properties?
(In reply to comment #4) > What does the PDE headless build do in such a case? I don't see why PDE/build behaviour is relevant here. There are many cases where Tycho is more strict about validating project configuration and I strongly believe this is a good thing. > @Igor: Are there projects with missing source folders in the Eclipse Platform? > Do these have correct build.properties? I don't believe there are projects with missing bin.includes in Eclipse Platform, but I am not 100% sure.
(In reply to comment #5) > (In reply to comment #4) > > What does the PDE headless build do in such a case? > I don't see why PDE/build behaviour is relevant here. There are many cases where > Tycho is more strict about validating project configuration and I strongly > believe this is a good thing. I thought that the PDE build behaviour this may serve as argument for being more strict than we are now. But you are right, we can always be more strict - and we should where it makes sense. As long as the error messages are good, I think being strict is the right thing to do. With the good feedback we are getting on ldi-users, we should notice if we ever should overdo it...
http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=1a043f098ced2f6f1e1a532f836b0db68bc4f397 implements bin.includes/src.includes validation source folder existence check still open.
I tried to migrate pretty large build to 0.14. Finding all projects that have bad bin/src .includes entries proved to be very time consuming job. Only one problem is reported during each build and it takes over 5 minutes for this particular build to reach the next problem. I think we need a way to report all problems for entire reactor or an option to downgrade bad bin/src .includes entries from failures to warnings. I'll have a look into this.
(In reply to comment #8) from the previous comments I got the impression we want to be more strict here which is why I implemented it this way. mvn -fae does not help in this case?
(In reply to comment #9) > (In reply to comment #8) > from the previous comments I got the impression we want to be more strict here > which is why I implemented it this way. > > mvn -fae does not help in this case? thinking about it again, -fae won't help. A quick fix would be to introduce the warning switch (default should be error or warning then?). Accumulating errors up to the end of the reactor is probably more effort.
(In reply to comment #9) > (In reply to comment #8) > from the previous comments I got the impression we want to be more strict here > which is why I implemented it this way. > I still believe we should be strict by default, but I now think option not to break the build is needed to help migrate existing projects. FYI, it was easier to add "strictBin(Src)Includes" parameter than to introduce a separate validation logic. Let me know if you see this as a problem. > mvn -fae does not help in this case? "mvn -fae" does not built modules that depend on modules that failed to build. (In reply to comment #10) > > A quick fix would be to introduce the warning switch (default should be error > or warning then?). > Accumulating errors up to the end of the reactor is probably more effort. Yup, a switch to turn errors into warnings. All warnings can be easily located with grep afterwards.
> > (In reply to comment #8) > I still believe we should be strict by default, but I now think option not to > break the build is needed to help migrate existing projects. > > FYI, it was easier to add "strictBin(Src)Includes" parameter than to introduce > a separate validation logic. Let me know if you see this as a problem. sure just go ahead. I see the point that with big reactors we need to be able to turn this into a warnings, otherwise we cause too much frustration for too little benefit.
implemented <strictBinIncludes> and <strictSrcIncludes> parameters. http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=1e1d160c5b9031e9ccc4f9ccacc2a74ddb3b6cc5
validation of missing source folders should be tracked in a separate bug
