First off sorry for top-posting but this thread is getting too long to reply inline. I agree that having a profusion of resource related elements isn't a good thing so lets go with the augmented fileset rather than a dedicated <namedresources> element. Now just to be clear on what we are going to need in terms of fileset types:
an augmented resourcefileset that supports explicit names ( will be used by compiler tasks )
a new type extending fileset that supports explicit names ( will be used by the al task )
resgen will change to using a regular fileset instead of a ResourceFileSet. Incidentally why does it use ResourceFileSet now ? Is it just for easier assignment from the compiler tasks ?
is that an accurate summation ?
Ian
----- 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
fileGert 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
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
Which implementation ? From the questions you've asked it doesn't soundNow, I'm not quite finished with the details of the implementation :
like you've made enough design decisions to create an implementation :)
yeah, I ment the design ofcourse ...
also- should we extend ResourceFileSet ? Not sure about this, as it doesn't
always make sense to have manifest resource names : ResourceFileSet is
names.used for the <resgen> task, which does not involve manifest resource
well we could extend ResourceFileSet with the change I outlined above.So, we might actually need a different type for the <resgen> and the compiler tasks.
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>- <al> currently uses a normal fileset, it does not try to automatically
determine manifest resource names for the resources it embeds. So for
sure - it should have the same resource compilation functionality as thewe'd need a new type (which derives from FileSet) that also supports the nested <resource> element. Right ?
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).
completely- should we extend any fileset at all ? Should this perhaps be a
it would certainly make things simpler development wise.separate collection of elements ? Not sure I like this...
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.
the- should the file be resolved to a full path using the base directory of
sure - that makes it consistent with the filesets we have now.containing fileset (or resourcefileset, or whatever) ? Guess so, right ?
Ok
think- do we automatically compile the file if its a resx/licx file ? Don't
I don't think so. Filesets should, generally speaking be containerswe should do this ...
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
--
Ian MacLean, Developer, ActiveState, a division of Sophos
http://www.ActiveState.com
------------------------------------------------------- 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