This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
#134677 is the umbrella issue for utilizing maven repository content in ant based projects. a new module withc api/spi contract is necessary. It will allow bridging the ant projects and libraries code with service provided by the maven support (or other relevant providers)
Created attachment 61976 [details] javadoc and signatures
hey, guys. Could you do a initial review for me? attached is the javadoc of the current version of the api/spi contract. (Still to be changed as the implementation proceeds) the usecases are at: http://wiki.netbeans.org/ArtifactRepositoryNotes I'd like to integrate on Thu or Fri, so I'm wondering if we could do either the review meeting on Wed/early Thu (or postpone it til next week) or do it online only.
DK01: SHA1 digest token sounds to me like implementation detail of SPI. Consider changing SPI like this: RepositoryQueryImplementation.findInRepository(/*String shaHex*/ FileObject fo) and move RepositoryQuery.computeSHAHex() to SPI utilities if really needed. FileObject instead of shaHex gives SPI more flexibility. DK02: Result class - would not it be better to have just one final public Result class in API which would be simple bean with setters and getters and which would be used by SPI as well and which instead of hasJavaDoc() and downloadJavaDoc() had one method "URL[] getJavaDoc()" (and similarly for sources and artifact)? Then you could have one API helper like downloadRepositoryArtifact(URL, File destination). Using final class for Result has advantage you extensibility - you can easy add new methods in future if needed. I would not worry about public setters as long as Result is plain Java bean with no or minimal behaviours.
DK01: the sha1 as parameter is primarily for performance reasons. it shall be just computed once, not repeatedly in every implementation (if we have multiple one) btw what other (apart from sha1) means of lookup are you envisioning for the fileobject based method? I suppose we can always create another spi interface for the new parameter type when it appears. DK2: URL[] getJavadoc()/getSource() and a utility method for download sounds ok. it can be fully computed from the index result. However some future additions (like project site url, issue tracking/CI urls) need further computing that is better not done unless required. Therefore I'd rather avoid a simple bean result that doesn't allow any fine tuning.
Re. "btw what other (apart from sha1) means of lookup are you envisioning for the fileobject based method?" - having FO instead of SHA1 allows SPI to perform different hashing algorithms, perhaps just check file name or location of file or content of file (eg. reading manifest) or some other techniques. But my comments are just general - perhaps they do not make much sense in Maven repo context? Question: is this SPI just for Maven repositories or generally for any repository? (not sure whether there are some other repo types). Perhaps Result.getMavenId() should be just Result.getRepositoryId()?
not relevant anymore.