You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "daniel.green" <oc...@gmail.com> on 2009/05/04 18:10:54 UTC
Managing Modified Dependencies
The situation:
* Company finds a show stopping bug in dependency Foo
* Company can not wait for the owner of Foo to fix it
* Company branches the source code locally and applies patch
* Company now needs to maintained a modified third party dependency
Currently some crazy system of relative paths and fake version numbers is
being used to resolve the modified dependencies. However, this is obviously
an eye soar sore and is cluttering up our source repository. What are some
solutions for ensuring that changes don't get overwritten and our repository
stays clean?
Any suggestion will be welcomed!
I appreciate your time, thank you at least for that :-),
Daniel.
--
View this message in context: http://www.nabble.com/Managing-Modified-Dependencies-tp23371539p23371539.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Managing Modified Dependencies
Posted by Nick Stolwijk <ni...@gmail.com>.
Filename should not affect the checksum. You could take a look at the
META-INF directory inside the jar file. Sometimes there is also a
version number there.
With regards,
Nick Stolwijk
~Java Developer~
Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl
On Tue, May 5, 2009 at 9:13 PM, daniel.green <oc...@gmail.com> wrote:
> 590f45b612433a50665bc4f369fc77d0
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Managing Modified Dependencies
Posted by "daniel.green" <oc...@gmail.com>.
Fantastic! Thank you :-)
Strange, I'm using the GNU coreutils md5sum program, but I'm not getting any
search results for the checksum...
$ md5sum apache/commons-dbcp.jar
590f45b612433a50665bc4f369fc77d0 apache/commons-dbcp.jar
I've tried it with others too... Does the filename affect the sum?
Nick Stolwijk-4 wrote:
>
> If you still have the original jar, you can do an md5sum search on
> Sonatype Repository [1] or else a classname search on the same
> repository with one of the original classes.
>
> [1] http://repository.sonatype.org/index.html
>
> Hth,
>
> Nick Stolwijk
> ~Java Developer~
>
> Iprofs BV.
> Claus Sluterweg 125
> 2012 WS Haarlem
> www.iprofs.nl
>
>
>
> On Tue, May 5, 2009 at 7:21 PM, daniel.green <oc...@gmail.com> wrote:
>>
>>
>> Anders Hammar wrote:
>>>
>>> In any case, the two important things I think are to keep the original
>>> groupId and artifactId
>>>
>> I run into the sticky situation that not all of those are known. The
>> person
>> that wrote the previous versions of the poms (that I'm currently
>> renovating)
>> stored everything locally and set all the versions to '1' and the
>> artifact/groupids to something not inline with what is commonly used. How
>> would I discover the needed settings, given just a jar?
>>
>>
>> Anders Hammar wrote:
>>>
>>> As the initial scenario doesn't mention it, I would like to stress the
>>> step of submitting the patch to the owner. This should as least make
>>> it feasible to get fixed quickly at the source.
>>>
>>> In any case, the two important things I think are to keep the original
>>> groupId and artifactId (which was NOT the recommended way some time
>>> ago), and also to define dependency versions through
>>> dependencyManagament (so that there is just one place to change).
>>>
>>> /Anders
>>>
>>> On Mon, May 4, 2009 at 19:10, Geoffrey Wiseman
>>> <ge...@gmail.com> wrote:
>>>> On Mon, May 4, 2009 at 1:01 PM, Nick Stolwijk
>>>> <ni...@gmail.com>wrote:
>>>>
>>>>> Normally I just check out the source, apply my patches, update the
>>>>> deploymentManament section to point to our inhouse repository, update
>>>>> the version to x.y.z-companyname-1 and do a maven deploy. Then update
>>>>> the documentation to mention which revision you checked out
>>>>> (preferably a tag) and for which issues you have applied a patch, so
>>>>> that the build is reproducible.
>>>>>
>>>>
>>>> That'd would be roughly similar to how I would typically handle it. If
>>>> the
>>>> changes are significant, I might also check in to local source control.
>>>>
>>>> In all scenarios, I'd be hoping to get back on a public version ASAP.
>>>>
>>>> - Geoffrey
>>>> --
>>>> Geoffrey Wiseman
>>>> http://www.geoffreywiseman.ca/
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Managing-Modified-Dependencies-tp23371539p23392097.html
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
--
View this message in context: http://www.nabble.com/Managing-Modified-Dependencies-tp23371539p23394052.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Managing Modified Dependencies
Posted by Nick Stolwijk <ni...@gmail.com>.
If you still have the original jar, you can do an md5sum search on
Sonatype Repository [1] or else a classname search on the same
repository with one of the original classes.
[1] http://repository.sonatype.org/index.html
Hth,
Nick Stolwijk
~Java Developer~
Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl
On Tue, May 5, 2009 at 7:21 PM, daniel.green <oc...@gmail.com> wrote:
>
>
> Anders Hammar wrote:
>>
>> In any case, the two important things I think are to keep the original
>> groupId and artifactId
>>
> I run into the sticky situation that not all of those are known. The person
> that wrote the previous versions of the poms (that I'm currently renovating)
> stored everything locally and set all the versions to '1' and the
> artifact/groupids to something not inline with what is commonly used. How
> would I discover the needed settings, given just a jar?
>
>
> Anders Hammar wrote:
>>
>> As the initial scenario doesn't mention it, I would like to stress the
>> step of submitting the patch to the owner. This should as least make
>> it feasible to get fixed quickly at the source.
>>
>> In any case, the two important things I think are to keep the original
>> groupId and artifactId (which was NOT the recommended way some time
>> ago), and also to define dependency versions through
>> dependencyManagament (so that there is just one place to change).
>>
>> /Anders
>>
>> On Mon, May 4, 2009 at 19:10, Geoffrey Wiseman
>> <ge...@gmail.com> wrote:
>>> On Mon, May 4, 2009 at 1:01 PM, Nick Stolwijk
>>> <ni...@gmail.com>wrote:
>>>
>>>> Normally I just check out the source, apply my patches, update the
>>>> deploymentManament section to point to our inhouse repository, update
>>>> the version to x.y.z-companyname-1 and do a maven deploy. Then update
>>>> the documentation to mention which revision you checked out
>>>> (preferably a tag) and for which issues you have applied a patch, so
>>>> that the build is reproducible.
>>>>
>>>
>>> That'd would be roughly similar to how I would typically handle it. If
>>> the
>>> changes are significant, I might also check in to local source control.
>>>
>>> In all scenarios, I'd be hoping to get back on a public version ASAP.
>>>
>>> - Geoffrey
>>> --
>>> Geoffrey Wiseman
>>> http://www.geoffreywiseman.ca/
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Managing-Modified-Dependencies-tp23371539p23392097.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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
Re: Managing Modified Dependencies
Posted by "daniel.green" <oc...@gmail.com>.
Anders Hammar wrote:
>
> In any case, the two important things I think are to keep the original
> groupId and artifactId
>
I run into the sticky situation that not all of those are known. The person
that wrote the previous versions of the poms (that I'm currently renovating)
stored everything locally and set all the versions to '1' and the
artifact/groupids to something not inline with what is commonly used. How
would I discover the needed settings, given just a jar?
Anders Hammar wrote:
>
> As the initial scenario doesn't mention it, I would like to stress the
> step of submitting the patch to the owner. This should as least make
> it feasible to get fixed quickly at the source.
>
> In any case, the two important things I think are to keep the original
> groupId and artifactId (which was NOT the recommended way some time
> ago), and also to define dependency versions through
> dependencyManagament (so that there is just one place to change).
>
> /Anders
>
> On Mon, May 4, 2009 at 19:10, Geoffrey Wiseman
> <ge...@gmail.com> wrote:
>> On Mon, May 4, 2009 at 1:01 PM, Nick Stolwijk
>> <ni...@gmail.com>wrote:
>>
>>> Normally I just check out the source, apply my patches, update the
>>> deploymentManament section to point to our inhouse repository, update
>>> the version to x.y.z-companyname-1 and do a maven deploy. Then update
>>> the documentation to mention which revision you checked out
>>> (preferably a tag) and for which issues you have applied a patch, so
>>> that the build is reproducible.
>>>
>>
>> That'd would be roughly similar to how I would typically handle it. If
>> the
>> changes are significant, I might also check in to local source control.
>>
>> In all scenarios, I'd be hoping to get back on a public version ASAP.
>>
>> - Geoffrey
>> --
>> Geoffrey Wiseman
>> http://www.geoffreywiseman.ca/
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Managing-Modified-Dependencies-tp23371539p23392097.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Managing Modified Dependencies
Posted by Anders Hammar <an...@hammar.net>.
As the initial scenario doesn't mention it, I would like to stress the
step of submitting the patch to the owner. This should as least make
it feasible to get fixed quickly at the source.
In any case, the two important things I think are to keep the original
groupId and artifactId (which was NOT the recommended way some time
ago), and also to define dependency versions through
dependencyManagament (so that there is just one place to change).
/Anders
On Mon, May 4, 2009 at 19:10, Geoffrey Wiseman
<ge...@gmail.com> wrote:
> On Mon, May 4, 2009 at 1:01 PM, Nick Stolwijk <ni...@gmail.com>wrote:
>
>> Normally I just check out the source, apply my patches, update the
>> deploymentManament section to point to our inhouse repository, update
>> the version to x.y.z-companyname-1 and do a maven deploy. Then update
>> the documentation to mention which revision you checked out
>> (preferably a tag) and for which issues you have applied a patch, so
>> that the build is reproducible.
>>
>
> That'd would be roughly similar to how I would typically handle it. If the
> changes are significant, I might also check in to local source control.
>
> In all scenarios, I'd be hoping to get back on a public version ASAP.
>
> - Geoffrey
> --
> Geoffrey Wiseman
> http://www.geoffreywiseman.ca/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Managing Modified Dependencies
Posted by Geoffrey Wiseman <ge...@gmail.com>.
On Mon, May 4, 2009 at 1:01 PM, Nick Stolwijk <ni...@gmail.com>wrote:
> Normally I just check out the source, apply my patches, update the
> deploymentManament section to point to our inhouse repository, update
> the version to x.y.z-companyname-1 and do a maven deploy. Then update
> the documentation to mention which revision you checked out
> (preferably a tag) and for which issues you have applied a patch, so
> that the build is reproducible.
>
That'd would be roughly similar to how I would typically handle it. If the
changes are significant, I might also check in to local source control.
In all scenarios, I'd be hoping to get back on a public version ASAP.
- Geoffrey
--
Geoffrey Wiseman
http://www.geoffreywiseman.ca/
Re: Managing Modified Dependencies
Posted by Nick Stolwijk <ni...@gmail.com>.
Normally I just check out the source, apply my patches, update the
deploymentManament section to point to our inhouse repository, update
the version to x.y.z-companyname-1 and do a maven deploy. Then update
the documentation to mention which revision you checked out
(preferably a tag) and for which issues you have applied a patch, so
that the build is reproducible.
Hth,
Nick Stolwijk
~Java Developer~
Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl
On Mon, May 4, 2009 at 6:10 PM, daniel.green <oc...@gmail.com> wrote:
>
> The situation:
>
> * Company finds a show stopping bug in dependency Foo
> * Company can not wait for the owner of Foo to fix it
> * Company branches the source code locally and applies patch
> * Company now needs to maintained a modified third party dependency
>
> Currently some crazy system of relative paths and fake version numbers is
> being used to resolve the modified dependencies. However, this is obviously
> an eye soar sore and is cluttering up our source repository. What are some
> solutions for ensuring that changes don't get overwritten and our repository
> stays clean?
>
> Any suggestion will be welcomed!
>
> I appreciate your time, thank you at least for that :-),
> Daniel.
>
> --
> View this message in context: http://www.nabble.com/Managing-Modified-Dependencies-tp23371539p23371539.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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
Re: Managing Modified Dependencies
Posted by Brian Fox <br...@infinity.nu>.
I covered some strategies in this area here[1] and there are some other
how-tos here[2]
[1]
http://www.sonatype.com/people/2009/01/best-practices-for-releasing-with-3rd-party-snapshot-dependencies/
[2] http://www.sonatype.com/people/2009/04/summary-of-maven-how-tos/
On Mon, May 4, 2009 at 12:10 PM, daniel.green <oc...@gmail.com> wrote:
>
> The situation:
>
> * Company finds a show stopping bug in dependency Foo
> * Company can not wait for the owner of Foo to fix it
> * Company branches the source code locally and applies patch
> * Company now needs to maintained a modified third party dependency
>
> Currently some crazy system of relative paths and fake version numbers is
> being used to resolve the modified dependencies. However, this is obviously
> an eye soar sore and is cluttering up our source repository. What are some
> solutions for ensuring that changes don't get overwritten and our
> repository
> stays clean?
>
> Any suggestion will be welcomed!
>
> I appreciate your time, thank you at least for that :-),
> Daniel.
>
> --
> View this message in context:
> http://www.nabble.com/Managing-Modified-Dependencies-tp23371539p23371539.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>