Closed rotty3000 closed 8 years ago
this should show where what and how semantic versioning was broken and offer suggestions on how to solve the issue. this could either fail or warn the build.
Guess we could move the BaselineCommands code to bndlib and allow the generation of a report depending the parameters to baselining? This would generate a file in the generated directory then.
It is not completely clear what actions this should contain
I've noted in a bndtools mail list that someone recently demonstrated baseline output from bnd [1]
which looks suspiciously close to customizations I had made, which I hadn't yet contributed [2] but which were open source of course
Peter did you copy our baseline report output? If so, I'm flattered.
If I can get this same output from a standalone baseline operation then this takes us already very close to what I was hoping for.
I guess the only thing to do now is to investigate how to actually achieve "baselineing light" with this detailed reporting from any of the common build tools.
The next step would be to add some "fail the build" heuristics around what the report contains, and perhaps enhance the reports with the most common suggestions for how the issue could be resolved
OR
perhaps by configuration cause the common solution to occur by default (actually apply changes to the source)
[1] https://groups.google.com/forum/#!topic/bndtools-users/twvc8N5sCa8 [2] https://www.liferay.com/web/raymond.auge/blog/-/blogs/semantic-version-reporting-tool-in-liferay-s-build
a) I am sorry not to have flattered you, haven't touched that code in a long time :-) b) Your error report need to be more concrete so we an assign it to someone that is interested or not, or we can help you. I tend to hate open issues, which is good because when I can I fix them, but if I cannot action on them they tend to be moved to abeyance or closed ... :-)
love to brainstorm in a couple of weeks though on the f2f ...
Peter is the processing of the baseline report plugable?
That's the gist of this request. If it was, then anyone could format the output as they see fit and we could come up with some nice plugins to do potentially more than just report semver issues. We might be able to actively react to them.
Currently bndlib has the engine, it delivers an Info array, where the Info contains the details. You can then act on them, bndlib is available and has support for editing the project structure. I don't think a plugin model would be appropriate, think that in this case the baseliner is controlled from the outside.
We could of course make a baseline listener that receives the Info[], no problem to add such a plugin.
Kind regards,
Peter Kriens
On 17 okt. 2014, at 19:28, Raymond Augé notifications@github.com wrote:
Peter is the processing of the baseline report plugable?
That's the gist of this request. If it was, then anyone could format the output as they see fit and we could come up with some nice plugins to do potentially more than just report semver issues. We might be able to actively react to them.
— Reply to this email directly or view it on GitHub.
A listener would be great.
Would the listener be able to suppress/replace existing output?
On Fri, Oct 17, 2014 at 1:38 PM, Peter Kriens notifications@github.com wrote:
Currently bndlib has the engine, it delivers an Info array, where the Info contains the details. You can then act on them, bndlib is available and has support for editing the project structure. I don't think a plugin model would be appropriate, think that in this case the baseliner is controlled from the outside.
We could of course make a baseline listener that receives the Info[], no problem to add such a plugin.
Kind regards,
Peter Kriens
On 17 okt. 2014, at 19:28, Raymond Augé notifications@github.com wrote:
Peter is the processing of the baseline report plugable?
That's the gist of this request. If it was, then anyone could format the output as they see fit and we could come up with some nice plugins to do potentially more than just report semver issues. We might be able to actively react to them.
— Reply to this email directly or view it on GitHub.
— Reply to this email directly or view it on GitHub https://github.com/bndtools/bnd/issues/633#issuecomment-59548241.
Raymond Augé http://www.liferay.com/web/raymond.auge/profile (@rotty3000) Senior Software Architect Liferay, Inc. http://www.liferay.com (@Liferay)
It is still a bit vague .... Currently the only report generated is from the bnd command line, which is then also available from ant and gradle. However, this is a task in gradle/ant that could easily be replaced by your code; not sure it has any value to 'plugin' to the gradle/ant task for this? Both gradle, and, and other tools are much better in this kind of pluggability?
Can you give some use case scenarios how you want to use this?
As you stated, this is a task.
I'm arguing for this to not be a separate task, but virtually a default behaviour. I think the problem is that it's optional AND it's even difficult to setup. However, I believe we could bootstrap a reasonable setup that in most cases would make it simpler for developers to work with.
However, if it's still unclear what I'm suggesting, we can discuss it face to face in the coming weeks.
See https://github.com/bndtools/bnd/wiki/Baselining-Light-%5Bbeta%5D
I suspect that this should be a separate gradle task since not all builds want or care about baselining. Although, the presence of -baseline
in the bnd file could be the trigger for this additional behavior of the jar task.
Also, we would need to handle a project building multiple jars. That is, the current jar task can build multiple jars (-sub). So the baseline support would need to now what is the baseline jar for each built jar. So this may need to be specified in the subbundle bnd file.
Finally, the real work should probably not be in the gradle plugin but rather be a method on Project which can then be invoked by the gradle plugin.
In fact bnd files don't matter. A baseline operation doesn't need a bnd file at all!
Well it does matter for the current gradle plugin which is workspace based and bnd file driven. And this issue is about the workspace based build.
Issue #632 is for the non-workspace based builds.
@rotty3000 can we close this?
enhance the baseline reporting so it can provide richer feedback to developers from the command line (i.e. from standard build tools, not bndtools)