Re: [nant-dev] target run[after|before]=.../

2003-11-22 Thread Wenig, Stefan
Matt,
 
i like this idea, since these were among the first things i had to manually code into 
my nant files. specifying dependencies like this would certainly be valuable.
however, as for your first idea, i think that grouping these targets would be 
necessary in any but the most simple build files, so that nant can actually ensure 
that one of *these* targets must be done first. e.g.:
 
group
  target name=debug runbefore=build,test,deploy /
  target name=release runbefore=build,test,deploy /
/group
 
another group might do framework selection or whatever.
 
but then you can do the same thing much easier using your 2nd idea anyway:
 
target name=debug provides=projectconfig /
target name=release provides=projectconfig /
 
target name=build depends=projectconfig /
 
Stefan
 
--__--__--

Message: 2
Date: Fri, 21 Nov 2003 09:29:07 -0700
From: Matthew Mastracci [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [nant-dev] target run[after|before]=.../

I've been thinking about some of the target dependency functionality,
and I was wondering what people thought about having some extra
specification of target ordering.  There's a couple of types in here, so
I've broken them up.  I'm interested in hearing opinions of what people
think of these.

1.  Explicit ordering of user-passed targets

One of the patterns seen in the NAnt buildfile is the property target.
  Examples of this include the framework selection, release/debug
selection, etc.  It would be nice to specify the explicit ordering of
these targets, without introducing a dependency.  For instance,
something like this could be possible:

target name=debug runbefore=build,test,deploy /
target name=release runbefore=build,test,deploy /

This would tell the dependency engine that the debug/release targets
must run before any of build/test/deploy.

2.  Allowing targets to provide a virtual dependency

This would allow one or more targets to provide a virtual target that
could be used as a dependency in later targets.  For instance:

target name=modulea-config1 provides=modulea /
target name=modulea-config2 provides=modulea /

target name=deploy-modulea-generic depends=modulea /

Any comments/suggestions/flames?  :)

Matt.


winmail.dat

[nant-dev] Licensing

2003-11-06 Thread Wenig, Stefan
Hello all,

after browsing the developer list's archive for some discussions about
licensing, I felt like contributing one or two thoughts. I hope nobody
minds my entering the discussion, although I just started using nant,
with no code contributions so far.

1) I feel that one major point was not mentioned in the licensing thread
from last month: the GPL has two two major goals.
one is obviously to make sure that free software stays free. the other
one however seems to be to give the free software community an advantage
over commercially licensed software. that of course is only possible by
putting things in the way of anyone who wants to charge for their
software. 

the following quote is from a discussion about whether to use GPL or
LGPL: http://www.fsf.org/licenses/why-not-lgpl.html

Proprietary software developers have the advantage of money; free
software developers need to make advantages for each other. Using the
ordinary GPL for a library gives free software developers an advantage
over proprietary developers: a library that they can use, while
proprietary developers cannot use it.

without reading the fine print, this statement alone says to me: don't
use the GPL if you don't share that intention. (or if you want your
product to be an alternative to comercially available stuff, that's what
the lesser GPL seems to be about.)

it also says to me as a potential NAnt user: if you want to charge for
your software *and* use NAnt, this product's license goes out of its way
to make this harder.


2) another perspective I'd like to add: I understand the problem with
producing tools for Nant (GUI designers etc.) and intergrating it woth
other products (IDEs). we're not into tool-building, but I may still
face the following problem:

say I develop a project that has little to do with Nant, but I'd like to
distribute Nant to use its functionality not only for building, but for
installing too. (an idea I grabbed from the SDC sample on gotdotnet:
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=2
CB20E79-D706-4706-9EA0-26188257EE7D )
NAnt may one day choose to add specific support for integrating .build
file sections in MSI install scripts. However, AFAIU the GPL could be a
major obstacle in using this stuff. (and switching licenses won't
getting any easier, should you choose to do this at a later point.)

I have no problem contributing whatever enhancements I might come up
with, be it modificatiosn or new tasks. neither would my company. it
makes my life easier, and it's just fair. however, if I get the feeling
that the GPL could 'infect' my product just because it *uses* Nant (as
opposed to extend), I'd have to drop it like a hot stone.


3) msbuild. it's going to take its time, but one day it will compete
with Nant (and I believe there will be a need for NAnt even if msbuild
is available). I imagine that the NAnt developers will be trying to make
sure both are as compatible as possible - in both build files and custom
tasks. choosing a too strict license could lead to a situation where
custom tasks that could be available for NAnt will not. being msbuild
compatible does not require source-disclosure, while being NAnt
compatible would. We all know where the big market is going to be, so
dropping NAnt support would not be a hard decision for some companies.
without the licensing problems, adding it could be an even easier
decision.


4) if some or all of my concerns should be invalid, it just goes two
show how GPL fear works against Nant adoption. maybe some clear words on
the project homepage from someone who really understands open source
licensing could help then.


I hope I'm not too negative on the GPL, and I'm no licensing expert
either. just my two cents.

Regards,
Stefan


---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers


[nant-dev] replace task

2003-10-31 Thread Wenig, Stefan
hi everyone

I just installed nant (by far the best build tool I ever used btw) and
could not find a simple text replacement task, so I took the opportunity
to play around with user-defined tasks. the result is a very simple task
that processes the following xml instructions:

replace
  filterset
filter token=keyfile value=${build.keyfile} / 
  /filterset
  fileset
includes name=CooNetBase/NantAssemblyInfo.cs /
  /fileset
/replace

(the struggle with keyfile paths seems to be a constant source of pain
as far as I can tell from varios lists...)

right now I don't have time to get into the details of contributing, but
if anyone finds this useful I'll provide the source code (just a few . 

How are the chances that the core team implements Ant-like filter tasks
(which have to be supported by the copy task, version control tasks etc,
so contributing this is not an option, right?)


thanks
stefan


---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers