Publish and fetch a modular jar to a repository

Paul Sandoz paul.sandoz at oracle.com
Mon Jul 16 03:18:23 PDT 2012


Hi Alan,

Thanks for looking at this.

Here is an update:

  http://cr.openjdk.java.net/~psandoz/jigsaw/repo-add-jar/webrev.1/


On Jul 16, 2012, at 10:53 AM, Alan Bateman wrote:

> On 13/07/2012 18:14, Paul Sandoz wrote:
>> 
>> Hi,
>> 
>> Here is a webrev to support the publishing and fetching of modular jars from a repository:
>> 
>>   http://cr.openjdk.java.net/~psandoz/jigsaw/repo-add-jar/webrev/
>> 
>> I resisted the temptation to make too many changes since I think this area will need to go through a significant redesign to generalize the storage of stuff on the repository (src, docs etc) and be extensible to support stuff like reverse indexes and provide a sprinkling of REST on the HTTP repository.
>> 
>> So it just adds the feature with minimal fuss.
>> 
>> I hacked the testing in rather quickly, it perhaps could be improved with some guidance or feedback.
>> 
>> Paul.
> Yes, the existing repository support is very much a prototype and will likely need need to be designed/replaced in time.
> 
> Off-hand, I don't see any issue with adding modular JAR files to the existing repository.

FWIW all my ant macros/targets now work :-)


> The only thing that comes to mind is that we will likely need to rev the module format soon to support platform specific modules and other attributes to indicate device features/capabilities. I'm sure that will require updating the repository catalog and we'll need to figure out what that means for modular JAR files, if anything.
> 

Yes, i think this comes down to having multiple content associated with a module id, whether that be module files for various capabilities, source or javadoc etc.

IMHO the catalog needs to be in an extensible format that is easily consumable i.e. it is something that is likely to be consumed by many clients, in various languages, for various purposes. To me that means a textual format. That does not rule out other optimized formats. One can use HTTP content negotiation and/or there can be a services document, served by the root resource, that tells the client what there is and how to get to it (no need to hard code all URIs).


> Anyway, I skimmed through the webrev and made the following notes:
> 
> ModuleFile.java - L600, I assume you meant usize.
> 

Yes, good catch.


> Repository.ModuleType - probably best for the enum values to be in uppercase.

My preference is to use symbols where possible, e.g. in this case the name of an enum corresponds directly to the file extension name. But i realize this is not to everyones taste so i changed it.


> Repository.ModuleType - L101 - typo, "consistent" -> "consists".
> 

OK.


> The fix to RemoteRepository.java to use setInstanceFollowRedirects is a good catch, that would could easily have lurked for a long time.
> 

Yes, that's a nasty one :-)


> In Resolver then you might want to rename "ms" as it's no longer a ModuleSize.
> 

OK.


> PublishedRepository.java L198, the toFile() shouldn't be necessary here, can use Files.exists(file). Same thing at L226 where you could use Files.newInputStream. One advantage here is that there is potential for a much more useful exception when there is an error.
> 

OK.

Paul.

> On testing, then given that it's likely that the repository support will be replaced then it should be okay to just have a test that exercises publishing a few modular JAR files into a repository. I see you've cloned repolist.sh so that should be sufficient for now.
> 
> -Alan.
> 
> 




More information about the jigsaw-dev mailing list