----- Original Message ----- From: "Ian MacLean" <[EMAIL PROTECTED]> To: "Gert Driesen" <[EMAIL PROTECTED]> Cc: "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]> Sent: Friday, July 23, 2004 5:46 PM Subject: Re: [nant-dev] ResourceFileSet
> Gert Driesen wrote: > > >I think we need to add a <resource> child element that would allow the > >manifest resource name of a given resources file to be explicitly set. > > > > > > > I agree. As you say below, having to copy files to specify an explicit > name isn't ideal. > > >We actually need this ourselves in several places : > > > >- <al> : right now, we're forced to pass embedded resources from > >CompilerBase to the <al> task as command line arguments > >- NAntContrib : just found a major issue with the msi task / schema > >validated tasks, to fix it I have to embed the msi xsd file directly into > >the assembly, but in order to match the manifest resource name that the > >schema validator expects I actually have to copy the xsd to give it a file > >name that matches the manifest resource name, which is kinda of a hack. > > > > > not just kinda :) It is a hack. > > >Would be better if the <resourcefileset> type allowed explicitly manifest > >resource names to be set for a given resource. > > > > > Sure - do you have a design to do this ? The fundamental problem is that > to add explicit manifest names you need to be able to provide a name for > each file in the set. This obviously conflicts with how filesets work - > ie you can't use explicit names with wildcard include patterns. Perhaps > one way to get around this is to define a fileset type with an > additional child element that takes a filename and its matching resource > name so somthing like: > > <newresourcefilesetwithexplicitnames> > <include name="*.resx"/> > <exclude name="" /> > <resource file="foo.bar" name="foobar" /> > </newresourcefilesetwithexplicitnames> This matches what I had in mind ... > > obviously I'm joking about the element name. I kinda liked the name though, seems like the best name we've come up with so far ;-) lol > > >Now, I'm not quite finished with the details of the implementation : > > > > > > > Which implementation ? From the questions you've asked it doesn't sound > like you've made enough design decisions to create an implementation :) yeah, I ment the design ofcourse ... > > >- should we extend ResourceFileSet ? Not sure about this, as it doesn't > >always make sense to have manifest resource names : ResourceFileSet is also > >used for the <resgen> task, which does not involve manifest resource names. > >So, we might actually need a different type for the <resgen> and the > >compiler tasks. > > > > > > > well we could extend ResourceFileSet with the change I outlined above. > Resgen would just ignore the new element type. Not sure I like that, could be confusing for users ... Resgen really just needs a plain old fileset, it doesn't need the resourcefileset at all ... > > >- <al> currently uses a normal fileset, it does not try to automatically > >determine manifest resource names for the resources it embeds. So for <al> > >we'd need a new type (which derives from FileSet) that also supports the > >nested <resource> element. Right ? > > > > > > > sure - it should have the same resource compilation functionality as the > compiler tasks. Why would we need a new type for <al> ? wouldn't it use > the same type as the compiler tasks ? <al> doesn't need resource compilation support, and it can't really support it anyway as it has no notion of which compiler (naming scheme) you want. <al> doesn't need to know anything about resx or non-resx files. It just embeds files as is ... So we dont' need a resourcefileset for <al> (it currently uses a normal fileset for the resources, which is correct), but we do need to be able to specify explicit names for files that need to be embedded (or linked, but we don't support this yet). > > >- should we extend any fileset at all ? Should this perhaps be a completely > >separate collection of elements ? Not sure I like this... > > > > > > > it would certainly make things simpler development wise. Not sure about this. Don't even think much development will be involved at all ... > 2 elements for resource management. <resources> and <namedresources> > > like > <csc ...> > > <resources> > <include name="*.resx"/> > </resources> > > <namedresources> > <resource file="foo.bar" name="foobar" /> > </namedresources> Don't think I like this, when we add support for linked resources then we end up with four elements for resources ... > > </csc> > > namedresources wouldn't need to be a fileset since wildcards don't make > sense. Sure it would be nicer/cleaner to keep all resource stuff in a > single element, however the fundamental disconnect between the goals of > filesets ( ie wildcards ) and the need to have an explicit name for each > file means that it will be difficult to do in a way that doesn't look a > bit odd. I'm not saying that I'm 100% convinced that extending (resource)fileset is the perfect solution, but I do think that its better than possibly having four separate elements for resources. I agree that its a bit odd, but still ... it remains a set of files ... > It also means we wouldn't need to burden the current > ResourceFileset with detail that isn't required wherever its used. ResourceFileSet should (and will once we switch resgen over to a normal fileset) only be used for for the compiler tasks For <al>, we need an extra (fileset) derived class that just adds support for named resource files. > > >- should the file be resolved to a full path using the base directory of the > >containing fileset (or resourcefileset, or whatever) ? Guess so, right ? > > > > > > > sure - that makes it consistent with the filesets we have now. Ok > > >- do we automatically compile the file if its a resx/licx file ? Don't think > >we should do this ... > > > > > > > I don't think so. Filesets should, generally speaking be containers > rather than classes that take explicit action using the contents of > those containers. We do some clever auto-resolution of paths in fileset > code but I think thats of a different order to having the fileset > perform the compilation. I think its best to keep compilation in the > resgen, licx tasks. Sure, but I actually meant to say : do we even check whether any of these named resource files need to be compiled, and compile them automatically ? I don't think we should. Users can just use <resgen> for the compilation, because there's no need for the compiler tasks to determine the manifest resource name of these resources, as its supplied explicitly. > So I guess I'm leaning to the 2nd option - new non-fileset element to > hold the explicitly named resources. Whats your opinion ? As always I'm still in doubt, but I'd lean toward extending resourcefileset (for the compiler tasks) and creating a new class that derives from fileset for <al>. > Does my description of the problem above match your understanding ? Yeah, definitely. Gert ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
