Hi Emily and David,
I think requiring that the developer actually change the package-info files
makes him/her more aware of what (s)he's doing and will give the developer
a better understanding of semantic versioning in the end. Otherwise, even
if you have a separate step of committing, you could
With David (Jencks)'s help, I managed to integrated the versioning maven
plugin into a few projects. At the moment, the plugin will display the
versioning report in the build and then overwrite the wrong version in the
package-info.java. If the bundle version is incorrect, it just lists what
the
I think it would be better to fail the build and suggest the proper version
to the user in all cases where version information is incorrect. It could
be the case that the user unintentionally made a change that would bump the
version and may want to review those changes in the code instead of
Just reading my mail again and notice that I wasn't too clear in cases
where version information is missing. In any case I would not be so much in
favour of autocorrection and think that failing the build with suggested
fixes would be better.
On 29 November 2012 16:03, David Bosschaert
Hi David,
You can turn off the automatic packageinfos with a plugin flag. But I'm not
sure what your problem with them is. They aren't committed to your version
control system, they just show you what the correct version is for your current
code. If you changed something unintentionally you
Hi David,
Thanks for your reply. I quite like the feature of overwriting the
package-info version:o. When you run the maven build, there will be report
telling why you need to change to the recommended version. It is still up
to you to review the changes and then commit them. If it fails build,
Hi all,
As promised, I've started work on our next batch of releases. This one
should be way easier than the last batch I did, because it's way smaller.
However, one thing which is harder is that last time I knew what the
package and bundle versions were (1.0.0 across the board). This time I have
Hi Holly,
On 26 November 2012 15:46, Holly Cummins holly.k.cumm...@googlemail.comwrote:
(b) Longer term, wouldn't it be great to get the tool integrated into the
release plugin? I know we've discussed this before, so I'm mostly chipping
in again with a yes please, +1 :)
It would be great if
I turned Emily's code into a maven plugin, but I'm not sure I succeeded in
documenting it. Mostly it puts correct packaginfo files into the source tree
and generates a sort-of report of problems. I don't think it fails the build.
You have to specify what the base you are comparing against
Further to David J's comments, in order to fail a build, I think we can
parse the report xml doc. If there is an entry, we can fail the build,
which is trivial thing to do. David, if you can supply the snippet of your
maven plugin, I can help to integrate this tool in our trunk. Sorry. It has
been
10 matches
Mail list logo
