Hi Peter, I suppose the last part of the PR is not related to the recent Kettle issues. To me failing the build if local changes are present sounds like a good idea. But we must make sure that no plugin generates files outside of the "target" directory. Until recently the Swagger Maven plugin was writing doc files to the REST project base directory, for example.

If this is true then the PR looks good to me and it can be merged.

Cheers, Thomas Le 11/05/2015 10:44, Peter Palaga a écrit : > Hi *, > > citing from https://issues.jboss.org/browse/HAWKULAR-176 : > > == Motivation > > The proposed changes should improve the traceability of the components > delivered with kettle. Because we use SNAPSHOTs to build kettle ATM, > there is no way to find out which state of the individual component's > git repos underlie the given kettle distribution. > > In a situation when Lukáš has a working kettle distro and Thomas H. > cannot succeed to build one, they can go through the SHA1 hashes listed > in the manifest.mf files of the kettle components to find out where is > the difference. > > This proposal is not a proper solution of the problem that kettle builds > are not reproducible. It just picks some low hanging fruits to soften > the possible negative impact of our irreproducible builds. > > == Changes > > Maven should be configured in such a way that .jar, .war and *.ear files > will have the following new entries added to their manifest.mf files: > Built-From-Git-SHA1 - the last git commit's hash > Built-On - the time when the build has started > Built-From-Git-Branch - the git branch being built from > > Further, when the release profile is active, the build should fail, in > case there are uncommitted local changes. > > See https://github.com/hawkular/hawkular-parent-pom/pull/21 > > > Best, > > Peter > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

I'm not sure adding git sha's to manifests helps the situation much. For future evidence, I agree with Thomas H. that we need reproducible builds and strongly versioned components. The only disagreement we had was when to introduce them. Thomas' point for introducing strong versioning now is Kettle. Being the sum of the moving parts, it can break at random points with no traceability when using SNAPSHOTs of the components. My point for not introducing strong versioning YET is that the parts are so in flux that introducing such formal workflow would slow the development down with little added benefit (the benefit being no unpredictable unrelated breakages in Kettle at random points in time coming from the components that messed up). Of course there is a couple of questions here: 1) is the interdependence of the individual components so great that we really would have to release every other day? 2) is the UI willing to work in branches for long time to track unreleased progress in individual components? UI, really, is the biggest concern for me, because it usually needs the cutting edge functionality from the components. 3) can the release process be somehow sped up so that stuff appears in some public maven repos soon after the release is cut? (i.e. NOT 12-24 hrs) 4) is Kettle of big interest to the community? Currently it does much LESS than the individual components are capable of doing. Pinger really only scrapes the surface in the terms of the functionality being developed across the board. For me, the real question is whether we can afford 2) or solve 3). I am not 100% convinced 1) is that big of a problem anymore (despite claiming that during our f2f discussions - I've thought about it more since). Lukas On Monday, May 11, 2015 10:44:43 Peter Palaga wrote: > Hi *, > > citing from https://issues.jboss.org/browse/HAWKULAR-176 : > > == Motivation > > The proposed changes should improve the traceability of the components > delivered with kettle. Because we use SNAPSHOTs to build kettle ATM, > there is no way to find out which state of the individual component's > git repos underlie the given kettle distribution. > > In a situation when Lukáš has a working kettle distro and Thomas H. > cannot succeed to build one, they can go through the SHA1 hashes listed > in the manifest.mf files of the kettle components to find out where is > the difference. > > This proposal is not a proper solution of the problem that kettle builds > are not reproducible. It just picks some low hanging fruits to soften > the possible negative impact of our irreproducible builds. > > == Changes > > Maven should be configured in such a way that .jar, .war and *.ear files > will have the following new entries added to their manifest.mf files: > Built-From-Git-SHA1 - the last git commit's hash > Built-On - the time when the build has started > Built-From-Git-Branch - the git branch being built from > > Further, when the release profile is active, the build should fail, in > case there are uncommitted local changes. > > See https://github.com/hawkular/hawkular-parent-pom/pull/21 > > > Best, > > Peter > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

> 4) is Kettle of big interest to the community? Currently it does much LESS > than the individual components are capable of doing. Pinger really only > scrapes the surface in the terms of the functionality being developed across > the board. The Kettle *IS* Hawkular. I believe the naming does not help to see that it shouldn't be just a container where we throw in all the individual components. It's our primary project.

continuous delivery all the time? If it's difficult to release an individual component in a few minutes then there's an issue, and it should be fixed.