You are viewing a plain text version of this content. The canonical link for it is here.
Posted to nmaven-dev@incubator.apache.org by Wendy Smoak <ws...@gmail.com> on 2008/09/26 03:05:33 UTC
Re: Directory structure conventions
Coming back to this with some revisions... comments appreciated,
particularly in the area of the "nested" project-within-project
structure.
This is what you get if you leave the "Create directory for solution"
checkbox un-checked when creating a solution in Visual Studio, and
then add another project to it. You end up with source code in the
top directory as well as in the sub-directory.
What 'type' do you put in the top-level pom? If it's 'exe' then you
can't have <modules>. If it's 'pom' then you can't compile the source
and build an artifact.
Is this something NMaven should attempt to support? To what extent?
... and here's the new version:
http://docs.codehaus.org/display/MAVENUSER/NMaven+Project+Directory+Structure
The following directory structures should be supported by NMaven
1. Typical Maven single-module structure, single pom with separate
source trees for code and tests.
2. Typical Maven multi-module structure, parent pom with modules,
subdirectories for modules, each module containing source and tests as
in 1.
3. Visual Studio flat structure with .sln, .csproj and source code all
in the same directory. Source code is not typically put in a
subdirectory under the module, but it might be. If present, NUnit test
code should be in a directory named "Tests", which is not packaged in
the main artifact. See note below about "nested" projects. The "flat"
structure is only supported as a single project with no sub-modules.
4. Visual Studio multi-module solution with a parent pom containing
modules, then a subdirectory for each module, which equates to a VS
"project". The .sln file sits beside the parent pom, and each
subdirectory contains a .csproj, pom.xml and source code. Source code
is not typically put in a subdirectory under the module, but it might
be. NUnit test code may be within each module in a directory named
"Tests", or it may be in a separate module.
Note: Some versions of NMaven have limited support for a "nested"
project-within-project structure with source code in the parent
directory. This structure will have a .sln and .vbproj file at the
top, then directories for additional modules beneath, each containing
a .vbproj file. This structure is NOT RECOMMENDED and not likely to be
fully supported by Maven tools such as the Release plugin.
TODO: ADO .NET project structure
TODO: ASP .NET project structure (may involve links outside the
project to web content?)
NOTE: In the examples, .vbproj and .csproj are interchangeable, each
structure should work for any language, and a solution may be composed
of different modules using different languages.
Thanks,
--
Wendy
Re: Directory structure conventions
Posted by Wendy Smoak <ws...@gmail.com>.
On Thu, Oct 9, 2008 at 5:05 PM, Brett Porter <br...@apache.org> wrote:
>
> On 10/10/2008, at 10:52 AM, Wendy Smoak wrote:
>> 3. Visual Studio Web Site Project
>
> What directory are the aspx files in?
By default, the same directory as the .sln file... this is what I get
from File -> New -> Website (after moving the .sln file from where VS
puts it, which is NOT with the project.)
C:\PROJECTS\WEBSITE2
│ Default.aspx
│ Default.aspx.cs
│ WebSite2.sln
│ pom.xml
│
└───App_Data
>> Note: There is an issue with
>> building this type of project twice in a row: you must 'clean' before
>> building again.
>
> I don't understand that - is it a necessity of the format, or a bug of the
> current implementation?
I'm not sure-- Bong wrote about this on Oct 1st.
--
Wendy
Re: Directory structure conventions
Posted by Brett Porter <br...@apache.org>.
On 10/10/2008, at 10:52 AM, Wendy Smoak wrote:
>
> 3. Visual Studio Web Site Project
>
> Visual Studio "Web Site" (File -> New -> Web Site) project with .sln
> file copied into the project directory and modified to normalize
> paths. NMaven will build a zip file containing the aspx files and
> compiled dlls (in a bin/ directory).
What directory are the aspx files in?
> Note: There is an issue with
> building this type of project twice in a row: you must 'clean' before
> building again.
I don't understand that - is it a necessity of the format, or a bug of
the current implementation?
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: Directory structure conventions
Posted by Wendy Smoak <ws...@gmail.com>.
One more time... see the wiki for some directory trees that may be
easier to understand than my descriptions of them. :)
http://docs.codehaus.org/display/MAVENUSER/NMaven+Project+Directory+Structure
The following directory structures should be supported by NMaven
1. Multi-module Projects
Multi-module project with a parent pom containing one or more modules,
then a subdirectory for each module, which equates to a VS "project".
The .sln file sits beside the parent pom, and each subdirectory
contains a .csproj, pom.xml and source code. Source code is not
typically put in a subdirectory under the module, but it might be.
NUnit test code may be within each module in a directory named
"Tests", or it may be in a separate module.
TODO: When generating poms, is a solution with a single project a
special case? Should it have a parent pom with one module and a child
pom, or should it have only one pom?
2. Flat Single Module Project
Flat structure with pom.xml, .sln, .csproj and source code all in the
same directory. Source code is not typically put in a subdirectory
under the module, but it might be. If present, NUnit test code should
be in a directory named "Tests", which is not packaged in the main
artifact. See note below about "nested" projects. The "flat" structure
is only supported as a single project with no sub-modules, for
projects of type 'library' (dll) and 'exe'.
3. Visual Studio Web Site Project
Visual Studio "Web Site" (File -> New -> Web Site) project with .sln
file copied into the project directory and modified to normalize
paths. NMaven will build a zip file containing the aspx files and
compiled dlls (in a bin/ directory). Note: There is an issue with
building this type of project twice in a row: you must 'clean' before
building again.
4. Visual Studio ASP.NET Web Application
Visual Studio "ASP.NET Web Application" (File -> New -> Project,
"ASP.NET Web Application"). Structure is similar to (1) with a parent
pom and .sln file at the top, plus a subdirectory for each
project/module. NMaven should build a .zip file as in (3) containing
pages and dlls.
Note: Some versions of NMaven have limited support for a "nested"
project-within-project structure with source code in the parent
directory. This structure will have a .sln and .vbproj file at the
top, then directories for additional modules beneath, each containing
a .vbproj file. This structure is NOT RECOMMENDED and not likely to be
fully supported by Maven tools such as the Release plugin.
TODO: ASP.NET Web Service Application
TODO: ADO.NET project structure
NOTE: In the examples, .vbproj and .csproj are interchangeable, each
structure should work for any language, and a solution may be composed
of different modules using different languages. In addition, tests
within a module may be written in a different language than the main
artifact.
Comments and changes are welcome, here or on the wiki...
--
Wendy
Re: Directory structure conventions
Posted by Wendy Smoak <ws...@gmail.com>.
On Tue, Sep 30, 2008 at 8:10 PM, Shane Isbell <sh...@gmail.com> wrote:
> I think we should go with VS defaults. After the VS addin, I changed my mind
> about trying to support two different directory structures for VS, the Maven
> structure being an unnatural fit. So there may be some archetypes and ITs of
> each structure as this transition was going on.
That means source code in the same directory as the pom...
<sourceDirectory>.</sourceDirectory>
... which is quite odd for a Maven project. As long as NMaven can
figure out what is source and what isn't, it should be okay. I gather
VS does this by listing every file in .csproj.
--
Wendy
Re: Directory structure conventions
Posted by Shane Isbell <sh...@gmail.com>.
NMaven still supports whatever sourceDirectory you define for it. The issue
is what format we will use for the trunk and given that most people will
probably be using VS studio (and possibly the Maven addin), the VS defaults
make sense. This would not preclude you from using some other structure for
your project. Or am I missing something in your requirements?
An additional VS addin could also be created specifically for web projects,
if needed.
Shane
On Wed, Oct 1, 2008 at 9:52 PM, Leopoldo Agdeppa <la...@exist.com> wrote:
> Hello
>
> The problem when having a target in side the web application is that it is
> compiled by aspnet_compiler, a simple solution for this is, aspmojo should
> delete the target folder before calling aspnet_compiler,
> then aspnet_compiler's targetdirectory should be pointed to a temporary
> path, then after the execution
> the temporary path is then copied in the target folder,
>
> in this way we can support what is Visual Studio's Default way and still
> have the maven-style.
> and not forcing users who may have already a very large project to do some
> major refactor on there part.
> which might cause bad side effects.
>
> remember Visual studio web projects doesn't have a project file like
> (*.csproj/*.vbproj), its dll dependencies are stored in Bin/ directory
> and each *.dll has a *.dll.refresh which stores the relative path of the
> dependency dll, this means that changing a folder
> for the web project could make the relative paths of the *.dll.refresh file
> unreachable.
>
> thanks
> bong
>
> On Wed, Oct 1, 2008 at 4:08 PM, Leopoldo Agdeppa <la...@exist.com>
> wrote:
>
> > +1 with VS defaults
> >
> >
> > On Wed, Oct 1, 2008 at 11:10 AM, Shane Isbell <shane.isbell@gmail.com
> >wrote:
> >
> >> On Tue, Sep 30, 2008 at 7:59 PM, Wendy Smoak <ws...@gmail.com> wrote:
> >> >
> >> >
> >> > What is the convention on trunk exactly? Does it want a directory for
> >> > the source code, or is it fine if source is in the same directory as
> >> > the pom and .csproj file (the VS default)?
> >>
> >> I think we should go with VS defaults. After the VS addin, I changed my
> >> mind
> >> about trying to support two different directory structures for VS, the
> >> Maven
> >> structure being an unnatural fit. So there may be some archetypes and
> ITs
> >> of
> >> each structure as this transition was going on.
> >>
> >> Shane
> >>
> >
> >
> >
> > --
> > Leopoldo L. Agdeppa III
> > Software Engineer | Exist Global | +6332 4121155 xtn 103. +639195686024 |
> > YM: exst_lagdeppa | www.exist.com | Innovation Delivered
> >
>
>
>
> --
> Leopoldo L. Agdeppa III
> Software Engineer | Exist Global | +6332 4121155 xtn 103. +639195686024 |
> YM: exst_lagdeppa | www.exist.com | Innovation Delivered
>
Re: Directory structure conventions
Posted by Leopoldo Agdeppa <la...@exist.com>.
Hello
The problem when having a target in side the web application is that it is
compiled by aspnet_compiler, a simple solution for this is, aspmojo should
delete the target folder before calling aspnet_compiler,
then aspnet_compiler's targetdirectory should be pointed to a temporary
path, then after the execution
the temporary path is then copied in the target folder,
in this way we can support what is Visual Studio's Default way and still
have the maven-style.
and not forcing users who may have already a very large project to do some
major refactor on there part.
which might cause bad side effects.
remember Visual studio web projects doesn't have a project file like
(*.csproj/*.vbproj), its dll dependencies are stored in Bin/ directory
and each *.dll has a *.dll.refresh which stores the relative path of the
dependency dll, this means that changing a folder
for the web project could make the relative paths of the *.dll.refresh file
unreachable.
thanks
bong
On Wed, Oct 1, 2008 at 4:08 PM, Leopoldo Agdeppa <la...@exist.com> wrote:
> +1 with VS defaults
>
>
> On Wed, Oct 1, 2008 at 11:10 AM, Shane Isbell <sh...@gmail.com>wrote:
>
>> On Tue, Sep 30, 2008 at 7:59 PM, Wendy Smoak <ws...@gmail.com> wrote:
>> >
>> >
>> > What is the convention on trunk exactly? Does it want a directory for
>> > the source code, or is it fine if source is in the same directory as
>> > the pom and .csproj file (the VS default)?
>>
>> I think we should go with VS defaults. After the VS addin, I changed my
>> mind
>> about trying to support two different directory structures for VS, the
>> Maven
>> structure being an unnatural fit. So there may be some archetypes and ITs
>> of
>> each structure as this transition was going on.
>>
>> Shane
>>
>
>
>
> --
> Leopoldo L. Agdeppa III
> Software Engineer | Exist Global | +6332 4121155 xtn 103. +639195686024 |
> YM: exst_lagdeppa | www.exist.com | Innovation Delivered
>
--
Leopoldo L. Agdeppa III
Software Engineer | Exist Global | +6332 4121155 xtn 103. +639195686024 |
YM: exst_lagdeppa | www.exist.com | Innovation Delivered
Re: Directory structure conventions
Posted by Leopoldo Agdeppa <la...@exist.com>.
+1 with VS defaults
On Wed, Oct 1, 2008 at 11:10 AM, Shane Isbell <sh...@gmail.com>wrote:
> On Tue, Sep 30, 2008 at 7:59 PM, Wendy Smoak <ws...@gmail.com> wrote:
> >
> >
> > What is the convention on trunk exactly? Does it want a directory for
> > the source code, or is it fine if source is in the same directory as
> > the pom and .csproj file (the VS default)?
>
> I think we should go with VS defaults. After the VS addin, I changed my
> mind
> about trying to support two different directory structures for VS, the
> Maven
> structure being an unnatural fit. So there may be some archetypes and ITs
> of
> each structure as this transition was going on.
>
> Shane
>
--
Leopoldo L. Agdeppa III
Software Engineer | Exist Global | +6332 4121155 xtn 103. +639195686024 |
YM: exst_lagdeppa | www.exist.com | Innovation Delivered
Re: Directory structure conventions
Posted by Shane Isbell <sh...@gmail.com>.
On Tue, Sep 30, 2008 at 7:59 PM, Wendy Smoak <ws...@gmail.com> wrote:
>
>
> What is the convention on trunk exactly? Does it want a directory for
> the source code, or is it fine if source is in the same directory as
> the pom and .csproj file (the VS default)?
I think we should go with VS defaults. After the VS addin, I changed my mind
about trying to support two different directory structures for VS, the Maven
structure being an unnatural fit. So there may be some archetypes and ITs of
each structure as this transition was going on.
Shane
Re: Directory structure conventions
Posted by Brett Porter <br...@apache.org>.
On 01/10/2008, at 12:59 PM, Wendy Smoak wrote:
> What is the convention on trunk exactly? Does it want a directory for
> the source code, or is it fine if source is in the same directory as
> the pom and .csproj file (the VS default)?
Well, there's not exactly a convention - it uses whatever is in
sourceDirectory and testSourceDirectory.
>
>
> It would be good to change the archetypes to match the convention if
> that hasn't already been done. On the branch I believe dotnet-simple
> has src/main/csharp.
On trunk, the archetypes use the VS style, so that seems to be the
convention (and should be documented on the site).
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: Directory structure conventions
Posted by Wendy Smoak <ws...@gmail.com>.
On Fri, Sep 26, 2008 at 6:32 AM, Brett Porter <br...@apache.org> wrote:
>> 1. Typical Maven single-module structure, single pom with separate
>> source trees for code and tests.
>>
>> 2. Typical Maven multi-module structure, parent pom with modules,
>> subdirectories for modules, each module containing source and tests as
>> in 1.
>
> are these the src/main/csharp | src/test/csharp (or other language)
> equivalents?
Yes.
>> 3. Visual Studio flat structure with .sln, .csproj and source code all
>> in the same directory. Source code is not typically put in a
>> subdirectory under the module, but it might be. If present, NUnit test
>> code should be in a directory named "Tests", which is not packaged in
>> the main artifact. See note below about "nested" projects. The "flat"
>> structure is only supported as a single project with no sub-modules.
>>
>> 4. Visual Studio multi-module solution with a parent pom containing
>> modules, then a subdirectory for each module, which equates to a VS
>> "project". The .sln file sits beside the parent pom, and each
>> subdirectory contains a .csproj, pom.xml and source code. Source code
>> is not typically put in a subdirectory under the module, but it might
>> be. NUnit test code may be within each module in a directory named
>> "Tests", or it may be in a separate module.
>
> +1
>
> Given this is probably the near-ubiquitous set up, should these be the
> default, and (1) and (2) be supported? (as would any configuration of
> alternate source / test paths, really - like in Java). From what I've seen
> of trunk this seems to be the case already there.
What is the convention on trunk exactly? Does it want a directory for
the source code, or is it fine if source is in the same directory as
the pom and .csproj file (the VS default)?
It would be good to change the archetypes to match the convention if
that hasn't already been done. On the branch I believe dotnet-simple
has src/main/csharp.
--
Wendy
Re: Directory structure conventions
Posted by Brett Porter <br...@apache.org>.
On 26/09/2008, at 1:05 PM, Wendy Smoak wrote:
> Coming back to this with some revisions... comments appreciated,
> particularly in the area of the "nested" project-within-project
> structure.
>
> This is what you get if you leave the "Create directory for solution"
> checkbox un-checked when creating a solution in Visual Studio, and
> then add another project to it. You end up with source code in the
> top directory as well as in the sub-directory.
>
> What 'type' do you put in the top-level pom? If it's 'exe' then you
> can't have <modules>. If it's 'pom' then you can't compile the source
> and build an artifact.
>
> Is this something NMaven should attempt to support? To what extent?
If it works equally well under both structures for Visual Studio, I
don't believe it should be supported. It is a very unnatural fit for a
Maven project - the additional complexity would not be of any benefit.
>
> The following directory structures should be supported by NMaven
>
> 1. Typical Maven single-module structure, single pom with separate
> source trees for code and tests.
>
> 2. Typical Maven multi-module structure, parent pom with modules,
> subdirectories for modules, each module containing source and tests as
> in 1.
are these the src/main/csharp | src/test/csharp (or other language)
equivalents?
>
>
> 3. Visual Studio flat structure with .sln, .csproj and source code all
> in the same directory. Source code is not typically put in a
> subdirectory under the module, but it might be. If present, NUnit test
> code should be in a directory named "Tests", which is not packaged in
> the main artifact. See note below about "nested" projects. The "flat"
> structure is only supported as a single project with no sub-modules.
>
> 4. Visual Studio multi-module solution with a parent pom containing
> modules, then a subdirectory for each module, which equates to a VS
> "project". The .sln file sits beside the parent pom, and each
> subdirectory contains a .csproj, pom.xml and source code. Source code
> is not typically put in a subdirectory under the module, but it might
> be. NUnit test code may be within each module in a directory named
> "Tests", or it may be in a separate module.
+1
Given this is probably the near-ubiquitous set up, should these be the
default, and (1) and (2) be supported? (as would any configuration of
alternate source / test paths, really - like in Java). From what I've
seen of trunk this seems to be the case already there.
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: Directory structure conventions
Posted by Carlos Sanchez <ca...@carlossanchez.eu>.
it may be, but VS may not have the restrictions of the command line tool
On Sun, Sep 28, 2008 at 7:55 PM, Brett Porter <br...@apache.org> wrote:
> Where does VS usually put the target directory in a flat structure? (I
> thought it was bin in the same directory, but I guess that can't be right)
>
> On 29/09/2008, at 12:51 PM, Carlos Sanchez wrote:
>
>> not that i know with the asp_compiler executable, other than copying
>> the files to a temporary place.
>> We are already compiling to a temporary place because it doesn't like
>> the target dir to be in the source dir
>>
>> On Sun, Sep 28, 2008 at 7:47 PM, Brett Porter <br...@apache.org> wrote:
>>>
>>> On 29/09/2008, at 12:44 PM, Jan Stevens Ancajas wrote:
>>>
>>>>>
>>>>> TODO: ASP .NET project structure (may involve links outside the
>>>>> project to web content?)
>>>>
>>>> For ASP .Net , I suggest not to support flat directory structure.
>>>> Source
>>>> is compiled twice ( the other in ./target folder) which is causing
>>>> compile
>>>> error for web.config, so you always have to 'clean' first when
>>>> compiling.
>>>
>>> Is there any way to exclude the target from compilation?
>>>
>>> Thanks,
>>> Brett
>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: Directory structure conventions
Posted by Brett Porter <br...@apache.org>.
Where does VS usually put the target directory in a flat structure? (I
thought it was bin in the same directory, but I guess that can't be
right)
On 29/09/2008, at 12:51 PM, Carlos Sanchez wrote:
> not that i know with the asp_compiler executable, other than copying
> the files to a temporary place.
> We are already compiling to a temporary place because it doesn't like
> the target dir to be in the source dir
>
> On Sun, Sep 28, 2008 at 7:47 PM, Brett Porter <br...@apache.org>
> wrote:
>>
>> On 29/09/2008, at 12:44 PM, Jan Stevens Ancajas wrote:
>>
>>>>
>>>> TODO: ASP .NET project structure (may involve links outside the
>>>> project to web content?)
>>>
>>> For ASP .Net , I suggest not to support flat directory
>>> structure. Source
>>> is compiled twice ( the other in ./target folder) which is causing
>>> compile
>>> error for web.config, so you always have to 'clean' first when
>>> compiling.
>>
>> Is there any way to exclude the target from compilation?
>>
>> Thanks,
>> Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: Directory structure conventions
Posted by Carlos Sanchez <ca...@carlossanchez.eu>.
not that i know with the asp_compiler executable, other than copying
the files to a temporary place.
We are already compiling to a temporary place because it doesn't like
the target dir to be in the source dir
On Sun, Sep 28, 2008 at 7:47 PM, Brett Porter <br...@apache.org> wrote:
>
> On 29/09/2008, at 12:44 PM, Jan Stevens Ancajas wrote:
>
>>>
>>> TODO: ASP .NET project structure (may involve links outside the
>>> project to web content?)
>>
>> For ASP .Net , I suggest not to support flat directory structure. Source
>> is compiled twice ( the other in ./target folder) which is causing compile
>> error for web.config, so you always have to 'clean' first when compiling.
>
> Is there any way to exclude the target from compilation?
>
> Thanks,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: Directory structure conventions
Posted by Brett Porter <br...@apache.org>.
On 29/09/2008, at 12:44 PM, Jan Stevens Ancajas wrote:
>>
>> TODO: ASP .NET project structure (may involve links outside the
>> project to web content?)
>
> For ASP .Net , I suggest not to support flat directory structure.
> Source
> is compiled twice ( the other in ./target folder) which is causing
> compile
> error for web.config, so you always have to 'clean' first when
> compiling.
Is there any way to exclude the target from compilation?
Thanks,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: Directory structure conventions
Posted by Jan Stevens Ancajas <ja...@exist.com>.
On Fri, Sep 26, 2008 at 11:05 AM, Wendy Smoak <ws...@gmail.com> wrote:
> Coming back to this with some revisions... comments appreciated,
> particularly in the area of the "nested" project-within-project
> structure.
>
> This is what you get if you leave the "Create directory for solution"
> checkbox un-checked when creating a solution in Visual Studio, and
> then add another project to it. You end up with source code in the
> top directory as well as in the sub-directory.
>
> What 'type' do you put in the top-level pom? If it's 'exe' then you
> can't have <modules>. If it's 'pom' then you can't compile the source
> and build an artifact.
>
> Is this something NMaven should attempt to support? To what extent?
>
> ... and here's the new version:
>
>
> http://docs.codehaus.org/display/MAVENUSER/NMaven+Project+Directory+Structure
>
> The following directory structures should be supported by NMaven
>
> 1. Typical Maven single-module structure, single pom with separate
> source trees for code and tests.
>
> 2. Typical Maven multi-module structure, parent pom with modules,
> subdirectories for modules, each module containing source and tests as
> in 1.
>
> 3. Visual Studio flat structure with .sln, .csproj and source code all
> in the same directory. Source code is not typically put in a
> subdirectory under the module, but it might be. If present, NUnit test
> code should be in a directory named "Tests", which is not packaged in
> the main artifact. See note below about "nested" projects. The "flat"
> structure is only supported as a single project with no sub-modules.
>
> 4. Visual Studio multi-module solution with a parent pom containing
> modules, then a subdirectory for each module, which equates to a VS
> "project". The .sln file sits beside the parent pom, and each
> subdirectory contains a .csproj, pom.xml and source code. Source code
> is not typically put in a subdirectory under the module, but it might
> be. NUnit test code may be within each module in a directory named
> "Tests", or it may be in a separate module.
>
> Note: Some versions of NMaven have limited support for a "nested"
> project-within-project structure with source code in the parent
> directory. This structure will have a .sln and .vbproj file at the
> top, then directories for additional modules beneath, each containing
> a .vbproj file. This structure is NOT RECOMMENDED and not likely to be
> fully supported by Maven tools such as the Release plugin.
>
> TODO: ADO .NET project structure
>
> TODO: ASP .NET project structure (may involve links outside the
> project to web content?)
For ASP .Net , I suggest not to support flat directory structure. Source
is compiled twice ( the other in ./target folder) which is causing compile
error for web.config, so you always have to 'clean' first when compiling.
>
>
> NOTE: In the examples, .vbproj and .csproj are interchangeable, each
> structure should work for any language, and a solution may be composed
> of different modules using different languages.
>
> Thanks,
> --
> Wendy
>