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 <[email protected]> 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 >>> <[email protected]> wrote: >>>> On Mon, May 4, 2009 at 1:01 PM, Nick Stolwijk >>>> <[email protected]>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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> >> -- >> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > -- 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: [email protected] For additional commands, e-mail: [email protected]
