Gert Driesen wrote:
I agree. As you say below, having to copy files to specify an explicit name isn't ideal.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.
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 manifestSure - 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:
resource names to be set for a given resource.
<newresourcefilesetwithexplicitnames> <include name="*.resx"/> <exclude name="" /> <resource file="foo.bar" name="foobar" /> </newresourcefilesetwithexplicitnames>
obviously I'm joking about the element name.
Which implementation ? From the questions you've asked it doesn't sound like you've made enough design decisions to create an implementation :)Now, I'm not quite finished with the details of the implementation :
well we could extend ResourceFileSet with the change I outlined above. Resgen would just ignore the new element type.- 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.
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> 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 ?
it would certainly make things simpler development wise. 2 elements for resource management. <resources> and <namedresources>- should we extend any fileset at all ? Should this perhaps be a completely separate collection of elements ? Not sure I like this...
like <csc ...>
<resources> <include name="*.resx"/> </resources>
<namedresources> <resource file="foo.bar" name="foobar" /> </namedresources>
</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. It also means we wouldn't need to burden the current ResourceFileset with detail that isn't required wherever its used.
- 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.
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.- do we automatically compile the file if its a resx/licx file ? Don't think we should do this ...
So I guess I'm leaning to the 2nd option - new non-fileset element to hold the explicitly named resources. Whats your opinion ? Does my description of the problem above match your understanding ?
Ian
------------------------------------------------------- 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
