Re: [nant-dev] ResourceFileSet

[Ian MacLean]

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

 

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
 


--
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