Bugzilla – Full Text Bug Listing
| Summary: | tycho-compiler's useProjectSettings should be on by default | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Mickael Istria <mistria> |
| Component: | Tycho | Assignee: | Project Inbox <tycho-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | daniel_megert, jan.sievers, Lars.Vogel, loskutov, malaperle, markus.kell.r, mn, sewe |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://git.eclipse.org/r/83782 https://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=b2251bc75d661eef9c455f4cace925341c7dd71e |
||
| Whiteboard: | |||
|
Description
Mickael Istria
New Gerrit change created: https://git.eclipse.org/r/83782 Not every one may be happy, see https://git.eclipse.org/r/#/c/70/ by Shawn Pearce, for instance: Further, we have contributors to JGit who aren't Eclipse users. They can't rely on Eclipse auto formatting, auto save, auto bug fix, auto whatever. If the problem here is that "match surrounding code" isn't a sufficient rule for style and a more detailed guide is needed, we need to document that for any contributor, and especially for those who prefer not to use Eclipse. Yes, that's horrible, not using Eclipse on an Eclipse hosted project, but that's the reality, JGit has contributors who aren't Eclipse users, and we'll lose them if the only way they can be an effective contributor is to switch their IDE and tools. Not sure if this statement still applicable though. Another possible problem is a CI build that checks for local modifications in the workspace. (In reply to Mykola Nikishov from comment #2) > Not every one may be happy, Everything breaks a user workflow https://xkcd.com/1172/ ;) Moreover, JGit is the corner-case here as it's not an Eclipse-only project, whereas most Tycho users are Eclipse-only. There would still be the opportunity to set this flag to false. > Another possible problem is a CI build that checks for local > modifications in the workspace. I'm not sure I understand this user-story, can you please elaborate? (In reply to Mickael Istria from comment #3) > > Another possible problem is a CI build that checks for local > > modifications in the workspace. > > I'm not sure I understand this user-story, can you please elaborate? https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers ? Gerrit change https://git.eclipse.org/r/83782 was merged to [master]. Commit: http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=b2251bc75d661eef9c455f4cace925341c7dd71e thanks for the patch! Added a note in N&N: https://wiki.eclipse.org/Tycho/Release_Notes/0.27#New_and_Noteworthy (In reply to Jan Sievers from comment #6) > thanks for the patch! Thanks for the merge! This means we will have to disable this now explicitly in our platform build. One user story is that two safety nets are better than one. If some script kiddie disables some problems in an Eclipse project, then those problems can still be caught in the platform build. A good example for this is bug 506772. Such unused imports would have been hard to hide in our build story (in a normal project -- OSGi is a special case). (In reply to Dani Megert from comment #8) > This means we will have to disable this now explicitly in our platform build. Tracked in bug 506839. In the case of Platform, it might be interesting to package the common settings as a Maven artifact and to consume them in the build (by simply adding necessary pre-compile steps removing committed settings and expanding the common ones instead). For the record: We at Eclipse Code Recommenders also don't check in .settings but only the pom.xml and rely on m2e to create the .settings on project import; that way the pom.xml is the single source of truth about compiler configuration. (In reply to Mickael Istria from comment #10) > In the case of Platform, it might be interesting to package the common > settings as a Maven artifact and to consume them in the build (by simply > adding necessary pre-compile steps removing committed settings and expanding > the common ones instead). I generally like the idea of packaging your settings in a Maven artifact, as it can then be consumed by other projects. In fact, we do this with Code Recommenders' Checkstyle configuration which is then shared with Code Recommenders' incubator projects. There is, however, one big drawback: lack of m2e support. Luckily, for the maven-checkstyle-plugin there exists a m2e connector. But the naive approach of just using dependency:unpack (has no connector) to overwrite the .settings that were just automatically derived from your pom.xml by m2e is likely to cause problems. |