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/05/21 03:02:56 UTC
Directory structure conventions
From Maven, we have the src/main/java convention for Java projects...
what convention is NMaven going to promote for .NET projects? (And
how much deviation from that is going to be supported?)
What does a well-structured .NET project look like? I'm particularly
interested in multi-module projects.
One I saw today had a flat structure, with the "parent" directory
(with the .sln file) at the same level as directories containing
.csproj files and source code. This leaves nowhere to put the pom.xml
files, unless you put them right beside the .csproj files and use
<sourceDirectory>.</sourceDirectory> (and I'm not even sure that would
work...)
Thoughts?
--
Wendy
Re: Directory structure conventions
Posted by Jan Fredrik Wedén <jf...@gmail.com>.
On Wed, May 21, 2008 at 5:18 PM, Shane Isbell <sh...@gmail.com> wrote:
>> Another question is where to put test code using a structure like this
>> (with main artifact code in the root directory)? What is the
>> mainstream .NET/VS convention for this? E.g. will it work with sources
>> in "." and tests in "src/test" (or whatever)? The .NET team I'm
>> working with tends to create separate projects for tests since, using
>> their old style environment, test code in the same project would
>> become part of the main artifact - which should not be the case when
>> using a tool like NMaven.
>
> There is no need to create separate projects for test classes. Create a
> directory called Test in the main folder and set the pom testSourceDirectory
> to Test. They compile separately.
>
> Shane
>
That's how I thought it should work :-)
Now to convince our .NET developers to adopt a new convention...
Another question, though. In a project (as in organisational, not
code) mixing Java and .NET, should one opt for .NET sources in "." and
tests in "Test" or sources in, say, "src/main/cs" and tests in
"src/test/cs"? Will the latter confuse .NET developers and VS tooling
(we're also using CAB and SCSF) more than the former will confuse Java
people moving between camps?
--
- Jan Fredrik Wedén
Re: Directory structure conventions
Posted by Shane Isbell <sh...@gmail.com>.
On Wed, May 21, 2008 at 1:24 AM, Jan Fredrik Wedén <jf...@gmail.com>
wrote:
> On Wed, May 21, 2008 at 5:27 AM, Wendy Smoak <ws...@gmail.com> wrote:
> > On Tue, May 20, 2008 at 8:09 PM, Shane Isbell <sh...@gmail.com>
> wrote:
> >
> >> You can have flat directory structures, with a parent pom one level up.
> >
> > That's not flat. :) The parent pom would be a sibling of the modules
> > rather than above it.
> >
> > The problem I see with the existing project I was talking about is
> > that those sibling modules directly contain the .csproj file, some .cs
> > files, and a directory with more code beneath. There's nowhere to put
> > the pom.xml file.
> >
> > --
> > Wendy
> >
>
> From the 0.15 examples/archetypes I've looked at it seems that the
> pom.xml can go in the same directory as the code and project file. I
> personally don't like this (coming from Java/Maven conventions) but it
> appears to work (with the 0.15 version at least) and seems in line
> with the VS conventions mentioned in this thread.
>
> Another question is where to put test code using a structure like this
> (with main artifact code in the root directory)? What is the
> mainstream .NET/VS convention for this? E.g. will it work with sources
> in "." and tests in "src/test" (or whatever)? The .NET team I'm
> working with tends to create separate projects for tests since, using
> their old style environment, test code in the same project would
> become part of the main artifact - which should not be the case when
> using a tool like NMaven.
There is no need to create separate projects for test classes. Create a
directory called Test in the main folder and set the pom testSourceDirectory
to Test. They compile separately.
Shane
>
>
> --
> - Jan Fredrik Wedén
>
Re: Directory structure conventions
Posted by Jan Fredrik Wedén <jf...@gmail.com>.
On Wed, May 21, 2008 at 5:27 AM, Wendy Smoak <ws...@gmail.com> wrote:
> On Tue, May 20, 2008 at 8:09 PM, Shane Isbell <sh...@gmail.com> wrote:
>
>> You can have flat directory structures, with a parent pom one level up.
>
> That's not flat. :) The parent pom would be a sibling of the modules
> rather than above it.
>
> The problem I see with the existing project I was talking about is
> that those sibling modules directly contain the .csproj file, some .cs
> files, and a directory with more code beneath. There's nowhere to put
> the pom.xml file.
>
> --
> Wendy
>
From the 0.15 examples/archetypes I've looked at it seems that the
pom.xml can go in the same directory as the code and project file. I
personally don't like this (coming from Java/Maven conventions) but it
appears to work (with the 0.15 version at least) and seems in line
with the VS conventions mentioned in this thread.
Another question is where to put test code using a structure like this
(with main artifact code in the root directory)? What is the
mainstream .NET/VS convention for this? E.g. will it work with sources
in "." and tests in "src/test" (or whatever)? The .NET team I'm
working with tends to create separate projects for tests since, using
their old style environment, test code in the same project would
become part of the main artifact - which should not be the case when
using a tool like NMaven.
--
- Jan Fredrik Wedén
Re: Directory structure conventions
Posted by Wendy Smoak <ws...@gmail.com>.
On Tue, May 20, 2008 at 8:09 PM, Shane Isbell <sh...@gmail.com> wrote:
> You can have flat directory structures, with a parent pom one level up.
That's not flat. :) The parent pom would be a sibling of the modules
rather than above it.
The problem I see with the existing project I was talking about is
that those sibling modules directly contain the .csproj file, some .cs
files, and a directory with more code beneath. There's nowhere to put
the pom.xml file.
--
Wendy
Re: Directory structure conventions
Posted by Shane Isbell <sh...@gmail.com>.
From the command it's easy to support configurable directory structures, but
if you plan on using Visual Studio, I strongly encourage the flat directory
structure, as that is inline with VS conventions and makes syncing the pom
and csproj files much easier.
On Tue, May 20, 2008 at 8:02 PM, Wendy Smoak <ws...@gmail.com> wrote:
> From Maven, we have the src/main/java convention for Java projects...
> what convention is NMaven going to promote for .NET projects? (And
> how much deviation from that is going to be supported?)
>
> What does a well-structured .NET project look like? I'm particularly
> interested in multi-module projects.
You can have flat directory structures, with a parent pom one level up.
Shane
>
> One I saw today had a flat structure, with the "parent" directory
> (with the .sln file) at the same level as directories containing
> .csproj files and source code. This leaves nowhere to put the pom.xml
> files, unless you put them right beside the .csproj files and use
> <sourceDirectory>.</sourceDirectory> (and I'm not even sure that would
> work...)
>
> Thoughts?
>
> --
> 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
>
Re: Directory structure conventions
Posted by Wendy Smoak <ws...@gmail.com>.
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 Tue, May 20, 2008 at 8:09 PM, Brett Porter <br...@apache.org> wrote:
> ISTR that's what we agreed on, since it's pretty much the existing
> convention in .NET projects due to the way the IDE tends to generate things.
> Is that right?
After working with this for a while, here's what I've come up with:
http://docs.codehaus.org/display/MAVENUSER/NMaven+Project+Directory+Structure
PROPOSAL: The following directory structures should be supported by
NMaven command-line builds as well as the Visual Studio Addin.
1. Typical Maven single-module structure, single pom with separate
source trees for code and tests. (Visual Studio seems to see the two
source trees as separate "projects" each with a .csproj or .vbproj
file.)
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 (or .vbproj) and
source code all in the same directory.
4. Visual Studio multi-module project 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.
(Still to come... ADO .NET and ASP .NET project structures.)
Thoughts? In particular, is it reasonable for the VS Addin to support
(1) and (2)?
Thanks,
--
Wendy
Re: Directory structure conventions
Posted by Wendy Smoak <ws...@gmail.com>.
On Tue, May 20, 2008 at 8:09 PM, Brett Porter <br...@apache.org> wrote:
> ISTR that's what we agreed on, since it's pretty much the existing
> convention in .NET projects due to the way the IDE tends to generate things.
> Is that right?
After working with this for a while, here's what I've come up with:
http://docs.codehaus.org/display/MAVENUSER/NMaven+Project+Directory+Structure
PROPOSAL: The following directory structures should be supported by
NMaven command-line builds as well as the Visual Studio Addin.
1. Typical Maven single-module structure, single pom with separate
source trees for code and tests. (Visual Studio seems to see the two
source trees as separate "projects" each with a .csproj or .vbproj
file.)
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 (or .vbproj) and
source code all in the same directory.
4. Visual Studio multi-module project 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.
(Still to come... ADO .NET and ASP .NET project structures.)
Thoughts? In particular, is it reasonable for the VS Addin to support
(1) and (2)?
Thanks,
--
Wendy
Re: Directory structure conventions
Posted by Brett Porter <br...@apache.org>.
On 21/05/2008, at 1:02 PM, Wendy Smoak wrote:
> From Maven, we have the src/main/java convention for Java projects...
> what convention is NMaven going to promote for .NET projects? (And
> how much deviation from that is going to be supported?)
>
> What does a well-structured .NET project look like? I'm particularly
> interested in multi-module projects.
>
> One I saw today had a flat structure, with the "parent" directory
> (with the .sln file) at the same level as directories containing
> .csproj files and source code. This leaves nowhere to put the pom.xml
> files, unless you put them right beside the .csproj files and use
> <sourceDirectory>.</sourceDirectory> (and I'm not even sure that would
> work...)
ISTR that's what we agreed on, since it's pretty much the existing
convention in .NET projects due to the way the IDE tends to generate
things. Is that right?
- Brett
>
>
> Thoughts?
>
> --
> Wendy
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/