You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Michał Zegan <we...@poczta.onet.pl> on 2012/07/17 15:28:51 UTC
best practices
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello.
What is the best way to do things like:
Some artifact exists in a central repository and it's a transitive
dependency of some of my project's direct dependencies.
Then, I have a really good reason to modify the artifact and store it in
my own repository.
Should I distinguish the new version of it using a classifier, a version
like 0.0-modified, or I should make the coordinates the same as in central?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJQBWiTAAoJEIm05B02l8E6S6YP/i2OTRi04zHS/8yEBMabeI6g
e0BVVir6EI/l8+0NvuOVj0WI6gBxFDvajr6NHaQC/Eg1C6NHyTdCXrMXjeHLxcst
Z8Fqe+dOSF3zkvjUFpgU4NgvSxiuUKPc/2hcezYBMF/Q8IIDUJpR2sZpHmp0JdH+
iZIpcxPp1wzqwtWUvherMtjI351vyBSVWaPfoRPNFTeOXxCyR4WQmXeGQkMnG+9S
MpMAAACfdT6Hsjhvnq4CzrzItBpfIrgXWcXtM6mmyN92t2CumYTvpwWlF2iHNWyS
VvoIOoSntm6TBtk8vPtrMvC0vDTVJ6Cd3YdWAFacByy9kh+cjeATTUMKc/W+lbMn
FfTK4FAxQNqRUUa93MBBZydw0dKeLg4w+YulI4u6p219HtBNjtq1UuMAyXrEn/xk
xRysKjqpM2d2kkUiPvCJde/p6AarLpUK1GfVvzF9a/tff6nkOlt9AgaBmiJ/OiTt
o0yXIjo3ovJcBoGoPUC60qswDH5goKYJH1vkVaAj2ey8cFuwGNPrqGbjEiGgDtij
xU9KSzUOoOLxB6feskXEivgL+gxDK8+okJ4vLgglLezRaFMX5CXF+yttybXVyuK+
kE/mnl4Yx8gIIcogZLb1+kHsFqp1VHQvyfrzOadplOLTchbQUDfWpaS2EwztODQk
JtJsjfipQYirRjF5RfnD
=WGSq
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: best practices
Posted by Michał Zegan <we...@poczta.onet.pl>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
THere are many dependencies using that one as a transitive, so I don't
want to be in a situation when I would forget to exclude them.
Changing a version using dependency management works for all.
W dniu 2012-07-17 16:40, Ron Wheeler pisze:
> Sometimes a best practice requires you to do things that you don't want to do for short term reasons.
>
> Why not add an exclusion for stuff you want Maven to exclude?
>
> Ron
>
> On 17/07/2012 10:02 AM, Michał Zegan wrote:
> 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/
iQIcBAEBAgAGBQJQBYDKAAoJEIm05B02l8E6sx8P/0KDjRu5k0dh7dB3z2IFsMOq
u3tHIPInudanW+yLtvRL98NQ8twJ+pfwpq4t6pxtwKoFCU0LYxqgK4n7JOtHF2c1
IVLQMQK2GGN+NlSQGRPIhf5vCc23q4aXOx5slQavDbkR/tAF/AdB/hecwhd3N4G0
Y3t/oYLEW8x9heSxf5Z3+nVJhu4/dfRD2GRTR0IwKLZ3sPORZ/GeZmxza9jEn1+M
0S8NVHxgKPv0KTlJuVpZ+VOsqzYUZw5b/6Cxm5vqbMgM5RrVCuSe05PdJdyt+U9r
iKDpzxrO/b3WmfU+VvgMD/W538hq2uy2AHO2//oSpA7aQpeq3LR03JfguYIRFCwG
VgoFihkZcs9WcaVqLxY65Wkd5FXJYvETgktornCqDdxMsm/hiMxi8PLn7zVrsmvI
bz66GpBTdByoUPotEv66d5jBONhmHIjVDnNKqhZcwDMd7M+pWFwdpz4oqM8aUwPS
oifn+NBee/fFNNKRVFSoKZjrSKEBWcS72+4JTVdKs7w+/s4Q8QHGg8baoz22odaq
7SexT4e/ItlA/fo8qr7mdsyeof6STnWPvP14SDXttYBP0U7PvMssee+ZQGljVKfi
tCliK80wNYxECRgwMuOhnaYXmjwtwyqpzn5hQQx/tplrddzt+2tv2phtNiOT/e+t
quAhpbvI0jrdBnqAwUlU
=/LKX
-----END PGP SIGNATURE-----
Re: best practices
Posted by Ron Wheeler <rw...@artifact-software.com>.
Sometimes a best practice requires you to do things that you don't want
to do for short term reasons.
Why not add an exclusion for stuff you want Maven to exclude?
Ron
On 17/07/2012 10:02 AM, Michał Zegan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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/
>
> iQIcBAEBAgAGBQJQBXB7AAoJEIm05B02l8E6VdUP/2yMZaMfDuf9QOPQty1B9Fo+
> hJ53Zn/anEIadj+TyWQKEkBRPzxP6WgZdP2eXJhEA6GeZAaSmjqOq6cePLycJ/bM
> yRabZ9mlWFb6DTw5Dc7wQ7snpJPIZRnA760tvNTwxFS/lb/7kjkLbTfJfTLfaVp6
> HvFbJgs72CTazUBiJabZx8ryVVQMUEwzTRdlr7p/w9VdKqN11Q2JCzJmcrH++Tk5
> AYInsKYgInlQjluYEpTfXSqAfQj9oJz9T1UXihS6dUzpd8DIbYLdcwUkQYB+bWUv
> pQJsGQmB14q8eXM2xtDkbIu5cpoJTncFMpnA/3ht4CKTbbFV+3hXLx3s9r638bbQ
> g6jK6LnH4kxoIWNBizm8I1eHpk25SwzK/mSZKmr2p4acma3naNn7qxastdApjbWu
> IqKXRMukhyOeXS8XM5C4j0aoHEpMYiVWDbVjCSkG0ptLTUoGoKYWOl1C84J8Jbpd
> 2gnnMOSHvucV8+jxHq3Zh0rXoR4z9r3jRoCsopEE3UPy/r6YqxO3A5PTwK2RIYHN
> ZsGRnpHzjyn/GK7YteZ48KwbC6Sl1TE3expL3gCPQNbI2t/zDvk6XSgzGuf+t+gY
> hXhnYBjwMcUSfC7eoLLE7chYiMr0g3yWNEII4iyj8VnqP6dlnETudFyrQvOsY+6h
> rwN/9SRuRuwqpRiGSI31
> =znFZ
> -----END PGP SIGNATURE-----
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: best practices
Posted by Stephen Connolly <st...@gmail.com>.
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 <we...@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 <we...@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-----
>
>
Re: best practices
Posted by Michał Zegan <we...@poczta.onet.pl>.
-----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 <we...@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-----
Re: best practices
Posted by Stephen Connolly <st...@gmail.com>.
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 <we...@poczta.onet.pl> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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/
>
> iQIcBAEBAgAGBQJQBXB7AAoJEIm05B02l8E6VdUP/2yMZaMfDuf9QOPQty1B9Fo+
> hJ53Zn/anEIadj+TyWQKEkBRPzxP6WgZdP2eXJhEA6GeZAaSmjqOq6cePLycJ/bM
> yRabZ9mlWFb6DTw5Dc7wQ7snpJPIZRnA760tvNTwxFS/lb/7kjkLbTfJfTLfaVp6
> HvFbJgs72CTazUBiJabZx8ryVVQMUEwzTRdlr7p/w9VdKqN11Q2JCzJmcrH++Tk5
> AYInsKYgInlQjluYEpTfXSqAfQj9oJz9T1UXihS6dUzpd8DIbYLdcwUkQYB+bWUv
> pQJsGQmB14q8eXM2xtDkbIu5cpoJTncFMpnA/3ht4CKTbbFV+3hXLx3s9r638bbQ
> g6jK6LnH4kxoIWNBizm8I1eHpk25SwzK/mSZKmr2p4acma3naNn7qxastdApjbWu
> IqKXRMukhyOeXS8XM5C4j0aoHEpMYiVWDbVjCSkG0ptLTUoGoKYWOl1C84J8Jbpd
> 2gnnMOSHvucV8+jxHq3Zh0rXoR4z9r3jRoCsopEE3UPy/r6YqxO3A5PTwK2RIYHN
> ZsGRnpHzjyn/GK7YteZ48KwbC6Sl1TE3expL3gCPQNbI2t/zDvk6XSgzGuf+t+gY
> hXhnYBjwMcUSfC7eoLLE7chYiMr0g3yWNEII4iyj8VnqP6dlnETudFyrQvOsY+6h
> rwN/9SRuRuwqpRiGSI31
> =znFZ
> -----END PGP SIGNATURE-----
>
>
Re: best practices
Posted by Michał Zegan <we...@poczta.onet.pl>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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/
iQIcBAEBAgAGBQJQBXB7AAoJEIm05B02l8E6VdUP/2yMZaMfDuf9QOPQty1B9Fo+
hJ53Zn/anEIadj+TyWQKEkBRPzxP6WgZdP2eXJhEA6GeZAaSmjqOq6cePLycJ/bM
yRabZ9mlWFb6DTw5Dc7wQ7snpJPIZRnA760tvNTwxFS/lb/7kjkLbTfJfTLfaVp6
HvFbJgs72CTazUBiJabZx8ryVVQMUEwzTRdlr7p/w9VdKqN11Q2JCzJmcrH++Tk5
AYInsKYgInlQjluYEpTfXSqAfQj9oJz9T1UXihS6dUzpd8DIbYLdcwUkQYB+bWUv
pQJsGQmB14q8eXM2xtDkbIu5cpoJTncFMpnA/3ht4CKTbbFV+3hXLx3s9r638bbQ
g6jK6LnH4kxoIWNBizm8I1eHpk25SwzK/mSZKmr2p4acma3naNn7qxastdApjbWu
IqKXRMukhyOeXS8XM5C4j0aoHEpMYiVWDbVjCSkG0ptLTUoGoKYWOl1C84J8Jbpd
2gnnMOSHvucV8+jxHq3Zh0rXoR4z9r3jRoCsopEE3UPy/r6YqxO3A5PTwK2RIYHN
ZsGRnpHzjyn/GK7YteZ48KwbC6Sl1TE3expL3gCPQNbI2t/zDvk6XSgzGuf+t+gY
hXhnYBjwMcUSfC7eoLLE7chYiMr0g3yWNEII4iyj8VnqP6dlnETudFyrQvOsY+6h
rwN/9SRuRuwqpRiGSI31
=znFZ
-----END PGP SIGNATURE-----
Re: best practices
Posted by Ron Wheeler <rw...@artifact-software.com>.
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 SIGNED MESSAGE-----
> Hash: SHA1
>
> But it would not work for transitive ependencies if I'll put it in a
> different group id, I think. because they are different projects.
> W dniu 2012-07-17 15:39, Anders Hammar pisze:
>> I think it would depend on what kind of changes you make. But if it's
>> a patch or similar, you should just change the version to
>> a.b.c-PATCH123 or something (keep artifactId and groupId as the
>> original).
>>
>> But if you make bigger changes to it, it would probably make sense to
>> put it under your groupId.
>>
>> /Anders
>>
>> On Tue, Jul 17, 2012 at 3:28 PM, Michał Zegan
>> <we...@poczta.onet.pl> wrote:
>> Hello.
>>
>> What is the best way to do things like:
>> Some artifact exists in a central repository and it's a transitive
>> dependency of some of my project's direct dependencies.
>> Then, I have a really good reason to modify the artifact and store it in
>> my own repository.
>> Should I distinguish the new version of it using a classifier, a version
>> like 0.0-modified, or I should make the coordinates the same as in
> central?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJQBW12AAoJEIm05B02l8E6x4oP/27oOsR5oOw5qYqYc/HSjs6z
> awbD/mw9MFocKF3XnzWbkF/AnxAK+kxxyJAtFjQ6dY9e6xEMrZKVGJ61ahuzz7hn
> H//PlXavX9tyRE0eqmmauanNFZaohr6SoXOgHAvTeCh5HAizHf8nAT0FT4HJTb9J
> LCMbpcE1ZFdSJ+rQMFS+IGPtYBYNQKylEaG1C9eP7os2hxIrwuxe0SVOPdrhmzrB
> KbFaORYbVa5660AcX/i7F6DZae8Bnp1AShLYa/2ecyDx6352z/olKju9iFbwkoEb
> 3WtFrzhIdDtKEPh7NzU2wCYPwXwhhkgTgGjDkLkC6/WjRTfZQoQJzMo/nGQn0uGB
> GY7uuGT82VpqI6IhubhKzJh4ddFmucu2AtCnxpuwhQ3q09h8UaHCCVmA3QLcnBVg
> moLbHGk/4bnub+sspoSH4gHPdhNiLWJbWXoj2SpR8v6IyeSenGxwndjrrf1j/bHX
> bplkMmAINlyaPhOBmt41iy1kzLhz4BNbBSaFCUbS71yyNh0AUBRNC1HDgzA8VSe+
> J4lBv/UFcI+gWZjyN3ih+S35oIVymjSUwjeU32XJq7zWkdLGi5x9AqhsEsTYzKyf
> zGLhIxdKMDIirTvX4nS2dlv7F8fx+8X06Vg1JgR1F0zZRnuGk+Sw1sPyy67aSlhj
> kjk+CPQAjzMTS5xKkdig
> =/tS3
> -----END PGP SIGNATURE-----
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: best practices
Posted by Michał Zegan <we...@poczta.onet.pl>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
But it would not work for transitive ependencies if I'll put it in a
different group id, I think. because they are different projects.
W dniu 2012-07-17 15:39, Anders Hammar pisze:
> I think it would depend on what kind of changes you make. But if it's
> a patch or similar, you should just change the version to
> a.b.c-PATCH123 or something (keep artifactId and groupId as the
> original).
>
> But if you make bigger changes to it, it would probably make sense to
> put it under your groupId.
>
> /Anders
>
> On Tue, Jul 17, 2012 at 3:28 PM, Michał Zegan
> <we...@poczta.onet.pl> wrote:
>>
> Hello.
>
> What is the best way to do things like:
> Some artifact exists in a central repository and it's a transitive
> dependency of some of my project's direct dependencies.
> Then, I have a really good reason to modify the artifact and store it in
> my own repository.
> Should I distinguish the new version of it using a classifier, a version
> like 0.0-modified, or I should make the coordinates the same as in
central?
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJQBW12AAoJEIm05B02l8E6x4oP/27oOsR5oOw5qYqYc/HSjs6z
awbD/mw9MFocKF3XnzWbkF/AnxAK+kxxyJAtFjQ6dY9e6xEMrZKVGJ61ahuzz7hn
H//PlXavX9tyRE0eqmmauanNFZaohr6SoXOgHAvTeCh5HAizHf8nAT0FT4HJTb9J
LCMbpcE1ZFdSJ+rQMFS+IGPtYBYNQKylEaG1C9eP7os2hxIrwuxe0SVOPdrhmzrB
KbFaORYbVa5660AcX/i7F6DZae8Bnp1AShLYa/2ecyDx6352z/olKju9iFbwkoEb
3WtFrzhIdDtKEPh7NzU2wCYPwXwhhkgTgGjDkLkC6/WjRTfZQoQJzMo/nGQn0uGB
GY7uuGT82VpqI6IhubhKzJh4ddFmucu2AtCnxpuwhQ3q09h8UaHCCVmA3QLcnBVg
moLbHGk/4bnub+sspoSH4gHPdhNiLWJbWXoj2SpR8v6IyeSenGxwndjrrf1j/bHX
bplkMmAINlyaPhOBmt41iy1kzLhz4BNbBSaFCUbS71yyNh0AUBRNC1HDgzA8VSe+
J4lBv/UFcI+gWZjyN3ih+S35oIVymjSUwjeU32XJq7zWkdLGi5x9AqhsEsTYzKyf
zGLhIxdKMDIirTvX4nS2dlv7F8fx+8X06Vg1JgR1F0zZRnuGk+Sw1sPyy67aSlhj
kjk+CPQAjzMTS5xKkdig
=/tS3
-----END PGP SIGNATURE-----
Re: best practices
Posted by Anders Hammar <an...@hammar.net>.
I think it would depend on what kind of changes you make. But if it's
a patch or similar, you should just change the version to
a.b.c-PATCH123 or something (keep artifactId and groupId as the
original).
But if you make bigger changes to it, it would probably make sense to
put it under your groupId.
/Anders
On Tue, Jul 17, 2012 at 3:28 PM, Michał Zegan
<we...@poczta.onet.pl> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello.
>
> What is the best way to do things like:
> Some artifact exists in a central repository and it's a transitive
> dependency of some of my project's direct dependencies.
> Then, I have a really good reason to modify the artifact and store it in
> my own repository.
> Should I distinguish the new version of it using a classifier, a version
> like 0.0-modified, or I should make the coordinates the same as in central?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJQBWiTAAoJEIm05B02l8E6S6YP/i2OTRi04zHS/8yEBMabeI6g
> e0BVVir6EI/l8+0NvuOVj0WI6gBxFDvajr6NHaQC/Eg1C6NHyTdCXrMXjeHLxcst
> Z8Fqe+dOSF3zkvjUFpgU4NgvSxiuUKPc/2hcezYBMF/Q8IIDUJpR2sZpHmp0JdH+
> iZIpcxPp1wzqwtWUvherMtjI351vyBSVWaPfoRPNFTeOXxCyR4WQmXeGQkMnG+9S
> MpMAAACfdT6Hsjhvnq4CzrzItBpfIrgXWcXtM6mmyN92t2CumYTvpwWlF2iHNWyS
> VvoIOoSntm6TBtk8vPtrMvC0vDTVJ6Cd3YdWAFacByy9kh+cjeATTUMKc/W+lbMn
> FfTK4FAxQNqRUUa93MBBZydw0dKeLg4w+YulI4u6p219HtBNjtq1UuMAyXrEn/xk
> xRysKjqpM2d2kkUiPvCJde/p6AarLpUK1GfVvzF9a/tff6nkOlt9AgaBmiJ/OiTt
> o0yXIjo3ovJcBoGoPUC60qswDH5goKYJH1vkVaAj2ey8cFuwGNPrqGbjEiGgDtij
> xU9KSzUOoOLxB6feskXEivgL+gxDK8+okJ4vLgglLezRaFMX5CXF+yttybXVyuK+
> kE/mnl4Yx8gIIcogZLb1+kHsFqp1VHQvyfrzOadplOLTchbQUDfWpaS2EwztODQk
> JtJsjfipQYirRjF5RfnD
> =WGSq
> -----END PGP SIGNATURE-----
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org