What happens if any dependencies are looking for that support? Will they bomb out or fail gracefully?
I.O.W. if you can still drop it in as a generic replacement => version change If you cannot use it as a generic replacement => different artifact => change groupId for example... I have https://github.com/stephenc/redmine-java-api which is https://github.com/taskadapter/redmine-java-api switched to use slf4j in place of some crappy piece of sh1t logging adapter code they rolled themselves. Because I have altered the API contract by removing their logging adapter code I maintain that at a different groupId. It is otherwise API compatible, but the changes I have made are breaking changes so I moved the groupId (never mind I needed a working version in central so I had to change the groupId anyway... I *could* have got away with pushing an alternative version number to our corp maven repo) On 17 July 2012 15:09, Michał Zegan <webczat_...@poczta.onet.pl> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > For example recompiling to drop compatibility with unsupported jsr14 > (namely osgi 4.3). > > W dniu 2012-07-17 16:05, Stephen Connolly pisze: > > What none of us know is the scope of changes between this artifact and > the > > original... > > > > if all you are doing is rolling a cut from the latest SCM head because > you > > cannot wait for the next release => just change the version > > > > if you are majorly refactoring in such a way that the API or behaviour > > contract will be changed => change the groupId > > > > if you are somewhere in between, you are going to have to make that call > > > > -Stephen > > > > On 17 July 2012 15:02, Michał Zegan <webczat_...@poczta.onet.pl> wrote: > > > >> > > I don't want to add exclusions for everything that requires that. > > > > W dniu 2012-07-17 15:57, Ron Wheeler pisze: > > >>> If you exclude the stock version from the direct dependencies and add > > your version as a > > dependency, you: > > >>> a) get the configuration that you want > > >>> b) you have documented in your POM, the exact configuration of > > software bits and pieces that are required to build what you want (your > > friends will someday love you for doing this or hate you if you don't) > > >>> > > >>> Being sneaky sometimes looks efficient but seldom is in the long > term. > > >>> > > >>> Ron > > >>> On 17/07/2012 9:49 AM, Michał Zegan wrote: > > >>>> > > >>>> > > >>> > > >>> > > > >> > >> > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.19 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJQBXH8AAoJEIm05B02l8E6CKsP/RBlMDopk2hlWwkZGd3WkWyU > zNiBSW0HPaAVffsr6aniscYBhPviqywOd/IklRhuqBtPtszrCGyO1SXem4zuW1jq > FZTTG5Zj+NzsIIG/FVYZKhudIc99eBRrgkuy5VM+cutpuq1+NyWdEZLDtYGR+bGy > YlO9qGB59sWTxXbk2Om5C2z5+1QreNT8soCMHPbULg+SxyLI8yNCD1N6+bx7zvhU > JRsrA51fA76kQx2ch31I/pIxTdK3c9f9mttB7Wuf1zGXkmhv9NTDljZ03DzlD4IW > XxahO6E5KC79NN16q+fvUwFPcjw2HR3FmyYQGiOc5XmqUC/fUBySFTj9G9mKwQGn > BRl8K2jO0C3X44hscEJjhXS204nGlwGpH0IUQTLGyF2f+dz+7meE4i6GqlvwEjaT > ZENnLzX0eS0dbQYem3FJeUXIoUjjUp70myq4rq7bvKHerrRQFHlGL7f+ApLStJX5 > Ps0qTH/xGtsU+PjPTNd3RJKyWfk4WvbXNVWjT+kLrlqL6pXommgI5/MZrAozot8m > jR3Slbhy/J1KI7xcu4yL6aEyWVDU7qwZHXVvyVj6SjFAMvlMX3YwtcpilG2P1Ljh > en/MKDTdUF8GKO4M/iOk59QJ7IPlD1FJq88UEiL/M6k0CuZzY/nRIZ6MnXTDBVoa > +KHubq8FPLWhrg3Ma3Al > =eu/j > -----END PGP SIGNATURE----- > >
