[
https://issues.apache.org/jira/browse/LUCENE-3945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated LUCENE-3945:
-----------------------------
Attachment: LUCENE-3945.patch
bq. Isn't any of these simpler?
FWIW that code was basically verbatim from ant's Checksum.java, but yeah: your
way is better
bq. Isn't this locale-sensitive? I think it should be explicit UTF-8
Also verbatim, but it actually caught my eye and I thought it was intentional
to deal with line ending differences in diff OSes, but your comment makes me
realize thta makes no sense -- and BufferedReader chomps all possible endings
equally regardless of locale/encoding.
bq. we can just name it DependencyCheckTask.
I think in the long run we should do that, and rename the taskdef, and rename
the macrodef, ... but for 3.6 it might be better to keep the changes to a
minimum and just add the logic to the existing class and add the SHA1 files but
not rename anything.
...updated patch with those changes ... going to start compiling the list of
all SHA1s files on trunk
> we should include checksums for every jar ivy fetches in svn & src releases
> to verify the jars are the ones we expect
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-3945
> URL: https://issues.apache.org/jira/browse/LUCENE-3945
> Project: Lucene - Java
> Issue Type: Task
> Reporter: Hoss Man
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3945.patch, LUCENE-3945.patch
>
>
> Conversation with rmuir last night got me thinking about the fact that one
> thing we lose by using ivy is confidence that every user of a release is
> compiling against (and likely using at run time) the same dependencies as
> every other user.
> Up to 3.5, users of src and binary releases could be confident that the jars
> included in the release were the same jars the lucene devs vetted and tested
> against when voting on the release candidate, but with ivy there is now the
> possibility that after the source release is published, the owner of a domain
> where these dependencies are hosted might change the jars in some way w/o
> anyone knowing. Likewise: we as developers could commit an ivy.xml file
> pointing to a specific URL which we then use for and test for months, and
> just prior to a release, the contents of the remote URL could change such
> that a JAR included in the binary artifacts might not match the ones we've
> vetted and tested leading up to that RC.
> So i propose that we include checksum files in svn and in our source releases
> that can be used by users to verify that the jars they get from ivy match the
> jars we tested against.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
