Troy Laurin wrote:
Swoogan wrote:
John Cole wrote:
There was a discussion on this topic a few months ago. The main
point of
contention was installing NAnt/NAntContrib to the same directory or
not and
whether or not to include NAntContrib at all in the installer.
I was warring with the same dilema as far as NAnt/NAntContrib. My
plan was to install to the same directory as NAnt because, AFAIK, the
assemblies have to go into the NAnt bin dir (or a relative path off
of it) for NAnt to load them. I was going to make the doc directory
install as nantcontrib-doc and nant install into nant-doc or just doc.
For the record, there are currently three basic alternatives for
installing NAntContrib...
1) Install NAntContrib to the same folder as NAnt.
PRO: NAntContrib is automatically detected in all NAnt builds with no
further work
CON: The combination is fragile. NAntContrib needs to be completely
reinstalled if NAnt is reinstalled (?)
CON: Difficult to remove NAntContrib if you no longer want it (for
some reason), even for a single build script
2) Install NAntContrib to a different folder, tinker with
NAnt.exe.config to load the NAntContrib dlls
PRO: NAnt/Contrib installation decoupled
CON: Have to tinker with NAnt.exe.config
CON: Still difficult to remove NAntContrib for instances you don't
want to use it
3) Install NAntContrib to a different folder, add a <loadtasks> line
in every build script that uses NAnt tasks.
PRO: NAnt/Contrib installation decoupled
CON: Extra overhead in each build script. Currently, also creates
non-portable scripts unless this method becomes standardised.
Perhaps we should explore a new mechanism for extension libraries in
NAnt, with inspiration taken from the Java jre/lib/ext idea...
4) Install NAntContrib to a different folder, and add an xml
descriptor/locator in NAnt/bin/ext which describes the library.
NAnt could scan the bin/ext folder for descriptors on startup in a
similar fashion to the NAnt.exe.config method, but this allows for
specific support such as disabling all extension libraries, or
disabling a named library when invoking NAnt.
PRO: Libraries decoupled from NAnt installation
PRO: Libraries "automatically" discovered on NAnt startup
PRO: Libraries can be easily registered/deregistered by adding or
removing their own locator... there's no possibility of corrupting
your NAnt install by breaking the xml structure - just one library.
CON: It's not implemented yet
The other thing I like about this approach is that is allows extension
to namespaces in the future... the namespace can be specified in the
xml locator (by default uses the default namespace), or the namespace
for a named library can be overridden from the commandline when
invoking NAnt (In case of a namespace clash with a particular build
script).
Also, it would be reasonably simple to create a <registerlibrary> (and
<deregisterlibrary>?) NAntContrib task to create this locator
dynamically.
Thoughts?
Regarding installing/downloading NAntContrib in the NAnt installer,
does the Inno download feature support a local-cached copy of the
downloaded module, say if you were installing NAnt on many developer
machines you don't want to have to download NAntContrib each time...
if so, this sounds like an excellent compromise!
Inno doesn't support that natively, but that's exactly what I'm doing
with my installer at work. Inno supports Pascal scripting at install
and uninstall time. So, I've already written code that checks to see if
the downloadable component is adjacent to the installer at runtime. If
it isn't, it's added to the list of components to download. I had a
slightly different problem in mind when I wrote it, namely, CD based
installations.
Swoogan
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
