Directory structure conventions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Directory structure conventions

Wendy Smoak
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
Reply | Threaded
Open this post in threaded view
|

Re: Directory structure conventions

brettporter
Administrator

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
[hidden email]
http://blogs.exist.com/bporter/

Reply | Threaded
Open this post in threaded view
|

Re: Directory structure conventions

Shane Isbell
In reply to this post by Wendy Smoak
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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Directory structure conventions

Wendy Smoak
On Tue, May 20, 2008 at 8:09 PM, Shane Isbell <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Directory structure conventions

Jan Fredrik Wedén
On Wed, May 21, 2008 at 5:27 AM, Wendy Smoak <[hidden email]> wrote:

> On Tue, May 20, 2008 at 8:09 PM, Shane Isbell <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Directory structure conventions

Shane Isbell
On Wed, May 21, 2008 at 1:24 AM, Jan Fredrik Wedén <[hidden email]>
wrote:

> On Wed, May 21, 2008 at 5:27 AM, Wendy Smoak <[hidden email]> wrote:
> > On Tue, May 20, 2008 at 8:09 PM, Shane Isbell <[hidden email]>
> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Directory structure conventions

Jan Fredrik Wedén
On Wed, May 21, 2008 at 5:18 PM, Shane Isbell <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Directory structure conventions

Wendy Smoak
In reply to this post by brettporter
On Tue, May 20, 2008 at 8:09 PM, Brett Porter <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Directory structure conventions

Wendy Smoak
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
Reply | Threaded
Open this post in threaded view
|

Re: Directory structure conventions

brettporter
Administrator

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
[hidden email]
http://blogs.exist.com/bporter/

Reply | Threaded
Open this post in threaded view
|

Re: Directory structure conventions

Jan Stevens Ancajas
In reply to this post by Wendy Smoak
On Fri, Sep 26, 2008 at 11:05 AM, Wendy Smoak <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Directory structure conventions

brettporter
Administrator

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
[hidden email]
http://blogs.exist.com/bporter/

Reply | Threaded
Open this post in threaded view
|

Re: Directory structure conventions

Carlos Sanchez
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 <[hidden email]> 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
> [hidden email]
> http://blogs.exist.com/bporter/
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Directory structure conventions

brettporter
Administrator
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 <[hidden email]>  
> 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
>> [hidden email]
>> http://blogs.exist.com/bporter/
>>
>>

--
Brett Porter
[hidden email]
http://blogs.exist.com/bporter/

Reply | Threaded
Open this post in threaded view
|

Re: Directory structure conventions

Carlos Sanchez
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 <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://blogs.exist.com/bporter/
>>>
>>>
>
> --
> Brett Porter
> [hidden email]
> http://blogs.exist.com/bporter/
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Directory structure conventions

Wendy Smoak
In reply to this post by brettporter
On Fri, Sep 26, 2008 at 6:32 AM, Brett Porter <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Directory structure conventions

Shane Isbell
On Tue, Sep 30, 2008 at 7:59 PM, Wendy Smoak <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Directory structure conventions

brettporter
Administrator
In reply to this post by Wendy Smoak

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
[hidden email]
http://blogs.exist.com/bporter/

Reply | Threaded
Open this post in threaded view
|

Re: Directory structure conventions

Wendy Smoak
In reply to this post by Shane Isbell
On Tue, Sep 30, 2008 at 8:10 PM, Shane Isbell <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Directory structure conventions

bong
In reply to this post by Shane Isbell
+1 with VS defaults

On Wed, Oct 1, 2008 at 11:10 AM, Shane Isbell <[hidden email]>wrote:

> On Tue, Sep 30, 2008 at 7:59 PM, Wendy Smoak <[hidden email]> 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
12