Hi Niclas, Thanks a lot for the clarifications... ..observations attd. below...
One extra query re. the Repository API - is there anyway I can query/read the already loaded information from the .meta file? Basically what I need to do is to display a list of files that need to be downloaded, etc. to the user... ..the details are in the .meta file - starting from an Artifact instance, can I ask the Repository API to download this file and give me the parsed details? Thanks, and Brgds, R. Saravanan On Fri, 17 Sep 2004 03:24:54 +0800, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > On Friday 17 September 2004 02:57, Rajamani Saravanan wrote: > > Thanks a lot, Steve... > > Steve seems to be missing in action today... > > > I tried with a snapshot version as well, but the behaviour is still > > the same, the jar gets downloaded once, but if the file has changed on > > the server, it does not get downloaded again... > > This is something Steve has been fooling around with yesterday. Unfortunately, > I am not up-to-date with the current status, but there were problems > yesterday that timestamps were checked when not expected. > > I think the algorithm should be that artifacts that are declared with > <project> should not check the timestamp, only <resource> artifacts. I am not > sure that this is what currently is the case. I was just thinking yesterday - either way, if I'm uploading a new file to the repository, I will be updating the version number... ..so do I really need this check?? (Sorry..) > > One other query re. file based repository - if I add a file-based > > repository to the list of hosts to search for, the block installed > > using the code below does NOT get copied to the user's avalon cache... > > ..if the repository is a HTTP server, it gets downloaded... > > Is this the current behaviour?? And you want the files always be copied to the > local cache?? The behaviour I've described is what is happening currently - (for the code mentioned, anyway) - but yes, we do need the file copied always to the local user's cache... (reason being that the file server may be behind a slow link - each time I access the file, it shouldn't be loaded from the file server)... I haven't yet tried ctx.install() - maybe this will help? > > Re. the block.xml file vs. the jar's .meta file : the jar's .meta file > > has the list of dependent jars generated using the artifact:install > > maven goal. Do I need to explicitly specify this list in the > > <classloader> section in the block.xml file or will this list be > > automatically added to the block's classloader from the .meta file? If > > I have to specify this in the block.xml file, is there any way to auto > > generate this from maven's project.xml? > > Hmmm... I should know this, but... > 1. Maven can not generate it. We have tried to make such marvel with Maven > plugins, and the end result of trying to create Maven plugins was MAGIC - The > new age of build systems. > > 2. I am almost certain that Repository will read the .meta file and place each > of the dependencies in the proper classloaders. But that is for Jars. Block > files doesn't have .meta files. I'm downloading the block's Jar dynamically and installing it from code using the Repository API... ..the .meta file is being used to automatically download the dependency Jar files.. ..this is the reason I expected the Jars to be automatically in the block's classpath when the block is instantiated... > 3. Magic can generate block files, with all the proper dependencies in the > <classloader> section, provided that the index.xml file is correctly set up. I'm trying Magic out now... ..will bore you with some more questions once I've done... :) > I hope Steve can provide some additional answers. > > Cheers > Niclas > -- > +------//-------------------+ > / http://www.bali.ac / > / http://niclas.hedhman.org / > +------//-------------------+ > > > > > --------------------------------------------------------------------- > 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]
