NMaven Project Importer (pom generator)

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

NMaven Project Importer (pom generator)

Wendy Smoak
The Project Importer currently generates two .csproj files when run
against the dotnet-simple archetype:  one for the code and one for the
tests.

From discussion on [1] and working with some simple projects, it seems
to me that there should be a 1:1 relationship between pom.xml and
.csproj files.  (Slightly adjusted for the .sln file, which either
gets a 'parent' pom of its own or else there is a pom.xml for a
combined .sln and .csproj file.)

However, I'm not familiar enough with the .sln and .csproj file
formats to understand whether it is possible to tell Visual Studio not
to package the tests along with the source code, if there is only one
.csproj file.  I assume there was some reason the author decided to
create two different files?  And how would you build the tests in
Visual Studio (not using NMaven)?

If that is possible, then I think layouts (1) and (3) on the wiki page
are actually the same.

[1] http://docs.codehaus.org/display/MAVENUSER/NMaven+Project+Directory+Structure

Thanks,
Wendy
Reply | Threaded
Open this post in threaded view
|

Re: NMaven Project Importer (pom generator)

Jan Stevens Ancajas
On Wed, Jun 25, 2008 at 10:51 PM, Wendy Smoak <[hidden email]> wrote:

> The Project Importer currently generates two .csproj files when run
> against the dotnet-simple archetype:  one for the code and one for the
> tests.

It should be the JavaBinding  that generates the  .csproj files from
archetype Or  do you mean after running the JavaBinding, Pom Generator is
run again?

>
>
> From discussion on [1] and working with some simple projects, it seems
> to me that there should be a 1:1 relationship between pom.xml and
> .csproj files.  (Slightly adjusted for the .sln file, which either
> gets a 'parent' pom of its own or else there is a pom.xml for a
> combined .sln and .csproj file.)
>
> However, I'm not familiar enough with the .sln and .csproj file
> formats to understand whether it is possible to tell Visual Studio not
> to package the tests along with the source code, if there is only one
> .csproj file.  I assume there was some reason the author decided to
> create two different files?

Do you mean the 2 csproj files ? Im not the author but my take on that is so
that VS can produce 2 separate binaries for  main and test.

>

And how would you build the tests in
> Visual Studio (not using NMaven)?

There's an Addin for Nunit , TestDriven.net (http://www.testdriven.net)  but
I'm not sure if this is commonly used in the dot net community.

>
>
> If that is possible, then I think layouts (1) and (3) on the wiki page
> are actually the same.
>
> [1]
> http://docs.codehaus.org/display/MAVENUSER/NMaven+Project+Directory+Structure
>
> Thanks,
> Wendy
>
Reply | Threaded
Open this post in threaded view
|

Re: NMaven Project Importer (pom generator)

Wendy Smoak
On Thu, Jun 26, 2008 at 1:01 AM, Jan Stevens Ancajas <[hidden email]> wrote:

> It should be the JavaBinding  that generates the  .csproj files from
> archetype Or  do you mean after running the JavaBinding, Pom Generator is
> run again?

Not sure about the implementation, just that I end up with two .csproj
files after importing.  It probably uses JavaBinding behind the
scenes.

> Do you mean the 2 csproj files ? Im not the author but my take on that is so
> that VS can produce 2 separate binaries for  main and test.

Yes.  I gather the 'build' in VS has no concept of a main artifact +
associated tests.

So when we talk about using a 'Test' directory within the main
project, how is that going to work?  As a nested VS project with a
separate .csproj file?  Or something that VS ignores and only NMaven
knows how to build?

> There's an Addin for Nunit , TestDriven.net (http://www.testdriven.net)  but
> I'm not sure if this is commonly used in the dot net community.

Interesting!  I wonder does it handle compiling the tests or only running them?

--
Wendy
Reply | Threaded
Open this post in threaded view
|

Re: NMaven Project Importer (pom generator)

Wendy Smoak
On Thu, Jun 26, 2008 at 3:56 AM, Wendy Smoak <[hidden email]> wrote:

> Not sure about the implementation, just that I end up with two .csproj
> files after importing.  It probably uses JavaBinding behind the
> scenes.

Sorry.  I'm getting the pom generation and solution generation all
mixed up.  JavaBinding and Project Import don't seem to trigger the
right definition for me...

If the project already has poms, and we are generating the solution,
then I think we should assume it's primarily going to be built with
NMaven and _not_ generate a second .csproj file for the tests.  If the
person wants a separate project for the tests, they should write a
separate pom before generating the solution.

If we have solution/project files and are generating poms, then it's
1:1 for ..csproj/.vbproj to pom.xml, plus one pom.xml for the .sln
unless it is combined with a .csproj/.vbproj.

WDYT?

--
Wendy
Reply | Threaded
Open this post in threaded view
|

Re: NMaven Project Importer (pom generator)

Jan Stevens Ancajas
In reply to this post by Wendy Smoak
On Thu, Jun 26, 2008 at 6:56 PM, Wendy Smoak <[hidden email]> wrote:

> On Thu, Jun 26, 2008 at 1:01 AM, Jan Stevens Ancajas <[hidden email]>
> wrote:
>
> > It should be the JavaBinding  that generates the  .csproj files from
> > archetype Or  do you mean after running the JavaBinding, Pom Generator is
> > run again?
>
> Not sure about the implementation, just that I end up with two .csproj
> files after importing.  It probably uses JavaBinding behind the
> scenes.
>
> > Do you mean the 2 csproj files ? Im not the author but my take on that is
> so
> > that VS can produce 2 separate binaries for  main and test.
>
> Yes.  I gather the 'build' in VS has no concept of a main artifact +
> associated tests.
>
> So when we talk about using a 'Test' directory within the main
> project, how is that going to work?  As a nested VS project with a
> separate .csproj file?  Or something that VS ignores and only NMaven
> knows how to build?


for VS it should be on a separate .csproj file  to produce a separate binary
for it.

For NMaven it can be done 2 ways:
1. the test module can be define in testSourceDirectory,
2. have a pom.xml for the test module, declare the main module as a
dependency and then change the sourceDirectory to  testSourceDirectory.


>
> > There's an Addin for Nunit , TestDriven.net (http://www.testdriven.net)
>  but
> > I'm not sure if this is commonly used in the dot net community.
>
> Interesting!  I wonder does it handle compiling the tests or only running
> them?
>
> --
> Wendy
>
Reply | Threaded
Open this post in threaded view
|

Re: NMaven Project Importer (pom generator)

Jan Stevens Ancajas
In reply to this post by Wendy Smoak
On Thu, Jun 26, 2008 at 8:00 PM, Wendy Smoak <[hidden email]> wrote:

> On Thu, Jun 26, 2008 at 3:56 AM, Wendy Smoak <[hidden email]> wrote:
>
> > Not sure about the implementation, just that I end up with two .csproj
> > files after importing.  It probably uses JavaBinding behind the
> > scenes.
>
> Sorry.  I'm getting the pom generation and solution generation all
> mixed up.  JavaBinding and Project Import don't seem to trigger the
> right definition for me...
>
> If the project already has poms, and we are generating the solution,
> then I think we should assume it's primarily going to be built with
> NMaven and _not_ generate a second .csproj file for the tests.  If the
> person wants a separate project for the tests, they should write a
> separate pom before generating the solution.
>
> If we have solution/project files and are generating poms, then it's
> 1:1 for ..csproj/.vbproj to pom.xml, plus one pom.xml for the .sln
> unless it is combined with a .csproj/.vbproj.
>
> WDYT?

I think that should be ok.

>
>
> --
> Wendy
>
Reply | Threaded
Open this post in threaded view
|

Re: NMaven Project Importer (pom generator)

Shane Isbell
The pom generator is designed to generate csproj files for the default maven
directory structure, which is the reason that there are two generated csproj
files, one for main source and one for test source. I highly encourage
people to use a flat directory structure with one csproj file.

Shane

On Thu, Jun 26, 2008 at 6:52 AM, Jan Stevens Ancajas <[hidden email]>
wrote:

>  On Thu, Jun 26, 2008 at 8:00 PM, Wendy Smoak <[hidden email]> wrote:
>
> > On Thu, Jun 26, 2008 at 3:56 AM, Wendy Smoak <[hidden email]> wrote:
> >
> > > Not sure about the implementation, just that I end up with two .csproj
> > > files after importing.  It probably uses JavaBinding behind the
> > > scenes.
> >
> > Sorry.  I'm getting the pom generation and solution generation all
> > mixed up.  JavaBinding and Project Import don't seem to trigger the
> > right definition for me...
> >
> > If the project already has poms, and we are generating the solution,
> > then I think we should assume it's primarily going to be built with
> > NMaven and _not_ generate a second .csproj file for the tests.  If the
> > person wants a separate project for the tests, they should write a
> > separate pom before generating the solution.
> >
> > If we have solution/project files and are generating poms, then it's
> > 1:1 for ..csproj/.vbproj to pom.xml, plus one pom.xml for the .sln
> > unless it is combined with a .csproj/.vbproj.
> >
> > WDYT?
>
> I think that should be ok.
>
> >
> >
> > --
> > Wendy
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: NMaven Project Importer (pom generator)

Wendy Smoak
Thanks, Shane.  This brings me back around to the question, then where
are the tests in this "flat" scenario?

If we're talking about generating poms from VS Solutions, then why
would we assume the default Maven structure instead of the default
Visual Studio structure?

--
Wendy

On Thu, Jun 26, 2008 at 7:34 AM, Shane Isbell <[hidden email]> wrote:
> The pom generator is designed to generate csproj files for the default maven
> directory structure, which is the reason that there are two generated csproj
> files, one for main source and one for test source. I highly encourage
> people to use a flat directory structure with one csproj file.
Reply | Threaded
Open this post in threaded view
|

Re: NMaven Project Importer (pom generator)

Shane Isbell
On Thu, Jun 26, 2008 at 8:41 AM, Wendy Smoak <[hidden email]> wrote:

> Thanks, Shane.  This brings me back around to the question, then where
> are the tests in this "flat" scenario?

The main classes are at the same level as the pom.xml file. The 'Test'
directory, which contains the test classes, are at the same level as the
pom.xml file.

>
>
> If we're talking about generating poms from VS Solutions, then why
> would we assume the default Maven structure instead of the default
> Visual Studio structure?

Originally, we were targeting to support VS for both the default Maven
structure and the flat structure. When generating new csproj files from
poms, the default structure is okay. But this default structure becomes
complicated and buggy when trying to add things like new classes, resources,
etc from within VS. That's why I would encourage people to use the flat
directory structure if they are going to be using VS. My idea for 0.16+ is
that only the flat structure will be supported for VS.

Shane

>
>
> --
> Wendy
>
> On Thu, Jun 26, 2008 at 7:34 AM, Shane Isbell <[hidden email]>
> wrote:
> > The pom generator is designed to generate csproj files for the default
> maven
> > directory structure, which is the reason that there are two generated
> csproj
> > files, one for main source and one for test source. I highly encourage
> > people to use a flat directory structure with one csproj file.
>
Reply | Threaded
Open this post in threaded view
|

Re: NMaven Project Importer (pom generator)

Wendy Smoak
On Thu, Jun 26, 2008 at 8:56 AM, Shane Isbell <[hidden email]> wrote:
> On Thu, Jun 26, 2008 at 8:41 AM, Wendy Smoak <[hidden email]> wrote:
>
>> Thanks, Shane.  This brings me back around to the question, then where
>> are the tests in this "flat" scenario?
>
> The main classes are at the same level as the pom.xml file. The 'Test'
> directory, which contains the test classes, are at the same level as the
> pom.xml file.

What does VS know about the Test directory?  AFAIK it doesn't have the
concept of a main artifact and associated tests.

Are you able to build the Test dll with Visual Studio with this scenario?

(That's a requirement in my case for existing projects, though I
believe it is addressed by the fact that there _is_ a .csproj file for
the tests, where ever the developer decides to put them.  Sometimes
it's in a sibling directory to the project, sometimes in a
subdirectory.  It "looks" the same in VS.)

--
Wendy
--
Wendy
Reply | Threaded
Open this post in threaded view
|

Questions regarding current state of C# build systems

James Carpenter-2
============================
Questions:

I could use some advice on the current state of C# build tooling.

* What choices are available and how would you contrast them?  I am  
currently aware of NAnt, MSBuild and NMaven but have little experience  
with any of them, although I am user level expert with Ant and Maven.  
Are there any commercial solutions which are currently way ahead of  
the above choices?

* Although i am convinced a maven based .NET build will potentially  
one day satisfy all my requirements, I don't have a great grasp of the  
status quo.  Is NMaven in its current state a better solution for a  
very large project than other choices?

* If NMaven is currently mature enough to use on a very large project,  
what steps should I take to avoid problems?  For example I assume I  
will need to create an in-house release and drop it into an in-house  
repo/repo-proxy such as artifactory.

* Are there any up-to-date articles or other such information covering  
these questions?  I have taken a look around via google but not found  
anything particularly compelling.

It is my hope the sections below will provide some contextual color  
and specificity to the above questions.

Thanks in advance for all the time and effort spent responding to this  
post.

=============================
Problem Context:

I have very recently joined a newly formed architecture team of a  
large (>50 developer) .NET based project.  The project has  
historically been a huge mess, but new leadership is beginning to  
change things for the better.  Over the last  few months the  
organization has started to very successfully apply the scope and  
customer management aspects of agile development.

Unfortunately, the code quality aspects of agile development are yet  
to be engrained into the company culture.  By this I mean test driven  
development, automated integration tests, automated performance tests,  
continuous integration, and frequent re-factoring as needed.  There  
appears to be a desire by the business to improve "quality" but little  
understanding of what this means and how to achieve it.

To large extent I believe a project delivers on whatever is measured.  
I believe much of the necessary quality related cultural change can be  
affected by simply deploying good build automation.  An important  
aspect of this effort is the need for an information radiator which  
brings attention and social pressures to bear on the quality aspects.  
The information radiator can be as simple as a maker board with a few  
simple code metrics for each sub-team alongside a large poster giving  
business context to each metric.  The metrics on the information  
radiator are only intended to apply social/organizational pressures.  
With sufficient motivation development teams will naturally take a  
closer look at the more detailed quality reports produced by the build  
system and other tooling.
=============================
My Background (your audience):

The majority of my expertise is in Java.  I have expert user level  
knowledge of maven based java builds.  I have even written and  
enhanced several maven plugins in the past including a few of the very  
early (pre-NMaven) C# maven plugins.  I am fairly familiar with the C#  
core language but not with much of the library and tooling stack  
for .NET development.

=============================
Characteristics of Desired Build System

* Sufficiently mature to avoid weeks of custom development and bug  
fighting.
* Conducive to modular development.
* Support for completely automated releases (i.e. mvn release:prepare  
release:perform)
* Sufficiently easy for junior and intermediate developers to learn  
and use from a surface user perspective.
* Supports the evil that is clear case.  (Should also support the  
goodness that is SVN in the event my team is able to affect such a  
change.)
* Produces test coverage, code complexity, and other such quality  
reports.
* Easily driven by an appropriate continuous integration solution.  
(Probably TeamCity)

=============================
Example Solution for Java based Code

* SVN for source control
* maven based build with properly configured release, and site plugins
* artifactory or similar for repo proxy
* TeamCity for CI.  (CruiseControl, Hudson, etc. are great but not as  
nice as TeamCity.  The distributed builds and remote build  
functionality are sadly unmatched by an OS solution.)
* Configure CI to send out emails on build critical failures.
* properly configured cobertura and/or clover plugin.
* various other quality metric report plugins (Checkstyle, PMD,  
FindBugs, JDepend, etc.)
* Sonar (maybe XRadar)
* Large wall monitor(s) displaying results of Sonar overview page.
* Large poster beside wall mounted monitors giving business context to  
each high level metric.
* Lots of mentoring and evangelizing to help influence the culture in  
a positive direction.

Note: Sonar and wall monitors can be replaced with a frequently  
updated marker board.

With experience all of the technical aspects can be put in place with  
only a few days of work.  The most time consuming part is actually  
working out the dependencies section of the pom files for code with  
lots of jars of unknown versions.
==============================

Thanks again for all your time and effort spent reading and responding  
to this post.

Sincerely,
James Carpenter
cell: 832-677-7247
email: [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Questions regarding current state of C# build systems

brettporter
Administrator
Hi James,

Sorry it has taken quite a while to reply, I've been behind on mail.  
You may have already made a decision, but it'd be great to hear what  
you found out.

Thoughts inline...

On 10/08/2008, at 9:36 AM, James Carpenter wrote:

> ============================
> Questions:
>
> I could use some advice on the current state of C# build tooling.
>
> * What choices are available and how would you contrast them?  I am  
> currently aware of NAnt, MSBuild and NMaven but have little  
> experience with any of them, although I am user level expert with  
> Ant and Maven.  Are there any commercial solutions which are  
> currently way ahead of the above choices?

I'm not aware of any other commercial solutions to this specific area  
myself. MSBuild is completely integrated with visual studio which is  
of benefit, though the available tasks I have found for it for the  
tools you refer to are limited.

NAnt certainly has been around longer than NMaven and so is more  
mature and has more resources available for it. However, I believe  
NMaven is the closest to what you are ultimately looking for: being  
based on Maven you will already have the ability to run the tools  
you've described and use it from within any continuous integration  
server, and this is certainly where its objectives lay.

> * Although i am convinced a maven based .NET build will potentially  
> one day satisfy all my requirements, I don't have a great grasp of  
> the status quo.  Is NMaven in its current state a better solution  
> for a very large project than other choices?

I believe NMaven would be technically capable of meeting your needs  
for a large project, but there are a couple of caveats.

Between the stage of the project and the fact that it is incubating,  
it is essential to become involved in the community in some way to get  
the most out of it. I'd say if you have some time to put in here it  
will be repaid, but it does still require that investment at the moment.

We currently only have one official release - 0.15. While this is much  
more suitable for some of your applications (since it is much more  
closely aligned to Maven's practices), it also lacks a lot of the  
features that are present in 0.14-SNAPSHOT. While we're working on  
(and looking for volunteers) to get involved in migrating that to the  
trunk now, using it now requires building an inhouse release and being  
involved here as you mentioned in a later question.

I hope that helps clear it up.

Cheers,
Brett

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

Reply | Threaded
Open this post in threaded view
|

Re: Questions regarding current state of C# build systems

James Carpenter-2
I still havn't hit the problem with the level of agression I would like to be able to devote to the effort.  Surface evaluations appear to bear out my initial concerns that nothing is truely capable of everything I need without significant development effort.
 
NMaven:
1) Best long term choice available.
 
 From past experience a couple years ago building C# with pre-NMaven .NET sandbox plugins as well as past discussions on this mailing list the ability for the repository to store assemblies without requiring versions in the file names (and assembly meta-data) is absolutely critical.  

--- On Tue, 9/2/08, Brett Porter <[hidden email]> wrote:

From: Brett Porter <[hidden email]>
Subject: Re: Questions regarding current state of C# build systems
To: [hidden email]
Date: Tuesday, September 2, 2008, 2:36 AM

Hi James,

Sorry it has taken quite a while to reply, I've been behind on mail.  
You may have already made a decision, but it'd be great to hear what  
you found out.

Thoughts inline...

On 10/08/2008, at 9:36 AM, James Carpenter wrote:

> ============================
> Questions:
>
> I could use some advice on the current state of C# build tooling.
>
> * What choices are available and how would you contrast them?  I am  
> currently aware of NAnt, MSBuild and NMaven but have little  
> experience with any of them, although I am user level expert with  
> Ant and Maven.  Are there any commercial solutions which are  
> currently way ahead of the above choices?

I'm not aware of any other commercial solutions to this specific area  
myself. MSBuild is completely integrated with visual studio which is  
of benefit, though the available tasks I have found for it for the  
tools you refer to are limited.

NAnt certainly has been around longer than NMaven and so is more  
mature and has more resources available for it. However, I believe  
NMaven is the closest to what you are ultimately looking for: being  
based on Maven you will already have the ability to run the tools  
you've described and use it from within any continuous integration  
server, and this is certainly where its objectives lay.

> * Although i am convinced a maven based .NET build will potentially  
> one day satisfy all my requirements, I don't have a great grasp of  
> the status quo.  Is NMaven in its current state a better solution  
> for a very large project than other choices?

I believe NMaven would be technically capable of meeting your needs  
for a large project, but there are a couple of caveats.

Between the stage of the project and the fact that it is incubating,  
it is essential to become involved in the community in some way to get  
the most out of it. I'd say if you have some time to put in here it  
will be repaid, but it does still require that investment at the moment.

We currently only have one official release - 0.15. While this is much  
more suitable for some of your applications (since it is much more  
closely aligned to Maven's practices), it also lacks a lot of the  
features that are present in 0.14-SNAPSHOT. While we're working on  
(and looking for volunteers) to get involved in migrating that to the  
trunk now, using it now requires building an inhouse release and being  
involved here as you mentioned in a later question.

I hope that helps clear it up.

Cheers,
Brett

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

Reply | Threaded
Open this post in threaded view
|

Re: Questions regarding current state of C# build systems

James Carpenter-2
In reply to this post by brettporter
I still havn't hit the problem with the level of agression I would like to be able to devote to the effort.  Surface evaluations appear to bear out my initial concerns that nothing is truely capable of everything I need without significant development effort.
 
NMaven:
1) Best long term choice available.
 
  From past experience a couple years ago building C# with pre-NMaven .NET sandbox plugins as well as past discussions on this mailing list the ability for the repository to store assemblies without requiring versions in the file names (and assembly meta-data) is absolutely critical.  

--- On Tue, 9/2/08, Brett Porter <[hidden email]> wrote:

From: Brett Porter <[hidden email]>
Subject: Re: Questions regarding current state of C# build systems
To: [hidden email]
Date: Tuesday, September 2, 2008, 2:36 AM

Hi James,

Sorry it has taken quite a while to reply, I've been behind on mail.  
You may have already made a decision, but it'd be great to hear what  
you found out.

Thoughts inline...

On 10/08/2008, at 9:36 AM, James Carpenter wrote:

> ============================
> Questions:
>
> I could use some advice on the current state of C# build tooling.
>
> * What choices are available and how would you contrast them?  I am  
> currently aware of NAnt, MSBuild and NMaven but have little  
> experience with any of them, although I am user level expert with  
> Ant and Maven.  Are there any commercial solutions which are  
> currently way ahead of the above choices?

I'm not aware of any other commercial solutions to this specific area  
myself. MSBuild is completely integrated with visual studio which is  
of benefit, though the available tasks I have found for it for the  
tools you refer to are limited.

NAnt certainly has been around longer than NMaven and so is more  
mature and has more resources available for it. However, I believe  
NMaven is the closest to what you are ultimately looking for: being  
based on Maven you will already have the ability to run the tools  
you've described and use it from within any continuous integration  
server, and this is certainly where its objectives lay.

> * Although i am convinced a maven based .NET build will potentially  
> one day satisfy all my requirements, I don't have a great grasp of  
> the status quo.  Is NMaven in its current state a better solution  
> for a very large project than other choices?

I believe NMaven would be technically capable of meeting your needs  
for a large project, but there are a couple of caveats.

Between the stage of the project and the fact that it is incubating,  
it is essential to become involved in the community in some way to get  
the most out of it. I'd say if you have some time to put in here it  
will be repaid, but it does still require that investment at the moment.

We currently only have one official release - 0.15. While this is much  
more suitable for some of your applications (since it is much more  
closely aligned to Maven's practices), it also lacks a lot of the  
features that are present in 0.14-SNAPSHOT. While we're working on  
(and looking for volunteers) to get involved in migrating that to the  
trunk now, using it now requires building an inhouse release and being  
involved here as you mentioned in a later question.

I hope that helps clear it up.

Cheers,
Brett

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

Reply | Threaded
Open this post in threaded view
|

Re: Questions regarding current state of C# build systems

James Carpenter-2
In reply to this post by James Carpenter-2

I still haven't hit the problem with the level of aggression I would like to be able to devote to the effort.  Surface evaluations appear to bear out my initial concerns that nothing is truly capable of everything I need without significant development effort.
 
=========================================== 
NMaven is still the front-runner.  I recognize this will involve creating custom plugins and bug fixes here and there.  As long as I am able to contribute such enhancements back to the NMaven project and have them accepted this is much better than maintaining in-house
build code (maven, ant, etc.).
 
Showstopper Issues:
 
* From past experience a couple years ago building C# with pre-NMaven .NET sandbox plugins as well as past discussions on this mailing list the ability for the repository to store assemblies without requiring versions in the file names (and assembly meta-data) is absolutely critical.  Nothing I have read so far indicates the intent of the core nmaven developers regarding this functionality.
 
Non-versioned assembly filenames were obviously available in the 0.14 release but no longer appears to be on the trunk.  I completely agree with the decision to move the nmaven plugins in alignment with core maven, I just need to better understand the roadmap.  I don't think this is a feature that can be omitted and have a workable solution.  I have submitted a post to the mailing list on this issue but I am yet to receive a response.
 
If the effort required to teach the artifact resolver/nmaven to handle an alternate repository layout for certain classes of artifacts isn't too great I would consider taking it on.  I would need a few pointers though as although I have written lots of custom maven plugins I have never dug as deep into the maven internals as this may require.  I also expect the nmaven developers have a better idea than I as to what needs done.  I am only willing to take this on if I can get my current employee to empower me to attack it.
 
* From a sustainability standpoint any custom plugins I build should be consistent with the 0.15+ architecture.  This is to say I don't want to spend development time coding against a deprecated architecture and I realize some amount of development will indeed be necessary.
 
Manageable Consequences of using NMaven at this stage:
 
* I will need to create an in-house release of NMaven to provide the necessary build stability until the time an appropriate formal NMaven release is created.  This is a pain but by no means a show-stopper.
 
* I will need to live without Visual Studio support for some period of time.
 
* I will likely have to create several report plugins.
 
* Dependent builds in TeamCity will need to be manually configured and/or I will need to figure out how to extend TeamCity to figure it out on its own.
 
* Selling the solution to those drinking the .NET cool-aid will be difficult.  Even I would prefer an all .NET solution for building an all .NET product.
 
* I suspect any nmaven plugins will have to be authored in Java.  The ability to write .NET plugins in C# might help when trying to call .NET tooling as opposed to making system calls on executables pragmatically resolved via the artifact resolver.  I haven't examined the NMaven trunk in great detail but it appears the C# plugin support is no longer available.  Can C# based plugins make use of component dependencies injected by plexus?  (i.e. Has some fancy/complicated cross-vm proxy mechanism been implemented?)
 
* I will spend a great deal of time training .NET developers/build staff on how/why to use maven.
 
===============================
The other decent choice is some combination of Ant/msbuild/Nant/Ivy with TeamCity for CI.  The biggest advantage with this choice is the appearance of using technologies more familiar to .NET developers.  The biggest drawback (as with any custom build system) is the resulting build scripts quickly become more complicated than simply learning a new technology which solves most of the problems out of the box.
 
It is also probably fair to say there are less likely to be major technical complications with Ant/Nant/msbuild/Ivy which show up at the last minute as there may be with nmaven.  The fact maven is capable of so much results in a great deal more complexity.  Therefore when one runs into an issue which can't be addressed via configuration and/or a simple plugin things get complicated quickly.  This doesn't tend to happen much in maven built Java projects as the road is pretty well paved at this point, but nmaven is still very much on the bleeding edge.  The emotional response of developers to problems with familiar technologies is often much different than their response to similar issues with unfamiliar technologies.
 
==============================
In the end, I am still left needing to build a non-trivial prototype build in both technologies in order to make a good decision.

--- On Tue, 9/2/08, Brett Porter <[hidden email]> wrote:

From: Brett Porter <[hidden email]>
Subject: Re: Questions regarding current state of C# build systems
To: [hidden email]
Date: Tuesday, September 2, 2008, 2:36 AM

Hi James,

Sorry it has taken quite a while to reply, I've been behind on mail.  
You may have already made a decision, but it'd be great to hear what  
you found out.

Thoughts inline...

On 10/08/2008, at 9:36 AM, James Carpenter wrote:

> ============================
> Questions:
>
> I could use some advice on the current state of C# build tooling.
>
> * What choices are available and how would you contrast them?  I am  
> currently aware of NAnt, MSBuild and NMaven but have little  
> experience with any of them, although I am user level expert with  
> Ant and Maven.  Are there any commercial solutions which are  
> currently way ahead of the above choices?

I'm not aware of any other commercial solutions to this specific area  
myself. MSBuild is completely integrated with visual studio which is  
of benefit, though the available tasks I have found for it for the  
tools you refer to are limited.

NAnt certainly has been around longer than NMaven and so is more  
mature and has more resources available for it. However, I believe  
NMaven is the closest to what you are ultimately looking for: being  
based on Maven you will already have the ability to run the tools  
you've described and use it from within any continuous integration  
server, and this is certainly where its objectives lay.

> * Although i am convinced a maven based .NET build will potentially  
> one day satisfy all my requirements, I don't have a great grasp of  
> the status quo.  Is NMaven in its current state a better solution  
> for a very large project than other choices?

I believe NMaven would be technically capable of meeting your needs  
for a large project, but there are a couple of caveats.

Between the stage of the project and the fact that it is incubating,  
it is essential to become involved in the community in some way to get  
the most out of it. I'd say if you have some time to put in here it  
will be repaid, but it does still require that investment at the moment.

We currently only have one official release - 0.15. While this is much  
more suitable for some of your applications (since it is much more  
closely aligned to Maven's practices), it also lacks a lot of the  
features that are present in 0.14-SNAPSHOT. While we're working on  
(and looking for volunteers) to get involved in migrating that to the  
trunk now, using it now requires building an inhouse release and being  
involved here as you mentioned in a later question.

I hope that helps clear it up.

Cheers,
Brett

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

Reply | Threaded
Open this post in threaded view
|

Re: Questions regarding current state of C# build systems

brettporter
Administrator
Thanks for the detailed information. I think you have a solid grasp of  
it.

It also seems we need to spend some time documenting the status of:
- the long and winding discussions about the repository format
- support for C# authored plugins via a proxy in the future (in  
comparison to what was done in 0.14)

Cheers,
Brett

On 03/09/2008, at 1:44 AM, James Carpenter wrote:

>
> I still haven't hit the problem with the level of aggression I would  
> like to be able to devote to the effort.  Surface evaluations appear  
> to bear out my initial concerns that nothing is truly capable of  
> everything I need without significant development effort.
>
> ===========================================
> NMaven is still the front-runner.  I recognize this will involve  
> creating custom plugins and bug fixes here and there.  As long as I  
> am able to contribute such enhancements back to the NMaven project  
> and have them accepted this is much better than maintaining in-house
> build code (maven, ant, etc.).
>
> Showstopper Issues:
>
> * From past experience a couple years ago building C# with pre-
> NMaven .NET sandbox plugins as well as past discussions on this  
> mailing list the ability for the repository to store assemblies  
> without requiring versions in the file names (and assembly meta-
> data) is absolutely critical.  Nothing I have read so far indicates  
> the intent of the core nmaven developers regarding this functionality.
>
> Non-versioned assembly filenames were obviously available in the  
> 0.14 release but no longer appears to be on the trunk.  I completely  
> agree with the decision to move the nmaven plugins in alignment with  
> core maven, I just need to better understand the roadmap.  I don't  
> think this is a feature that can be omitted and have a workable  
> solution.  I have submitted a post to the mailing list on this issue  
> but I am yet to receive a response.
>
> If the effort required to teach the artifact resolver/nmaven to  
> handle an alternate repository layout for certain classes of  
> artifacts isn't too great I would consider taking it on.  I would  
> need a few pointers though as although I have written lots of custom  
> maven plugins I have never dug as deep into the maven internals as  
> this may require.  I also expect the nmaven developers have a better  
> idea than I as to what needs done.  I am only willing to take this  
> on if I can get my current employee to empower me to attack it.
>
> * From a sustainability standpoint any custom plugins I build should  
> be consistent with the 0.15+ architecture.  This is to say I don't  
> want to spend development time coding against a deprecated  
> architecture and I realize some amount of development will indeed be  
> necessary.
>
> Manageable Consequences of using NMaven at this stage:
>
> * I will need to create an in-house release of NMaven to provide the  
> necessary build stability until the time an appropriate formal  
> NMaven release is created.  This is a pain but by no means a show-
> stopper.
>
> * I will need to live without Visual Studio support for some period  
> of time.
>
> * I will likely have to create several report plugins.
>
> * Dependent builds in TeamCity will need to be manually configured  
> and/or I will need to figure out how to extend TeamCity to figure it  
> out on its own.
>
> * Selling the solution to those drinking the .NET cool-aid will be  
> difficult.  Even I would prefer an all .NET solution for building an  
> all .NET product.
>
> * I suspect any nmaven plugins will have to be authored in Java.  
> The ability to write .NET plugins in C# might help when trying to  
> call .NET tooling as opposed to making system calls on executables  
> pragmatically resolved via the artifact resolver.  I haven't  
> examined the NMaven trunk in great detail but it appears the C#  
> plugin support is no longer available.  Can C# based plugins make  
> use of component dependencies injected by plexus?  (i.e. Has some  
> fancy/complicated cross-vm proxy mechanism been implemented?)
>
> * I will spend a great deal of time training .NET developers/build  
> staff on how/why to use maven.
>
> ===============================
> The other decent choice is some combination of Ant/msbuild/Nant/Ivy  
> with TeamCity for CI.  The biggest advantage with this choice is the  
> appearance of using technologies more familiar to .NET developers.  
> The biggest drawback (as with any custom build system) is the  
> resulting build scripts quickly become more complicated than simply  
> learning a new technology which solves most of the problems out of  
> the box.
>
> It is also probably fair to say there are less likely to be major  
> technical complications with Ant/Nant/msbuild/Ivy which show up at  
> the last minute as there may be with nmaven.  The fact maven is  
> capable of so much results in a great deal more complexity.  
> Therefore when one runs into an issue which can't be addressed via  
> configuration and/or a simple plugin things get complicated  
> quickly.  This doesn't tend to happen much in maven built Java  
> projects as the road is pretty well paved at this point, but nmaven  
> is still very much on the bleeding edge.  The emotional response of  
> developers to problems with familiar technologies is often much  
> different than their response to similar issues with unfamiliar  
> technologies.
>
> ==============================
> In the end, I am still left needing to build a non-trivial prototype  
> build in both technologies in order to make a good decision.
>
> --- On Tue, 9/2/08, Brett Porter <[hidden email]> wrote:
>
> From: Brett Porter <[hidden email]>
> Subject: Re: Questions regarding current state of C# build systems
> To: [hidden email]
> Date: Tuesday, September 2, 2008, 2:36 AM
>
> Hi James,
>
> Sorry it has taken quite a while to reply, I've been behind on mail.
> You may have already made a decision, but it'd be great to hear what
> you found out.
>
> Thoughts inline...
>
> On 10/08/2008, at 9:36 AM, James Carpenter wrote:
>
>> ============================
>> Questions:
>>
>> I could use some advice on the current state of C# build tooling.
>>
>> * What choices are available and how would you contrast them?  I am
>> currently aware of NAnt, MSBuild and NMaven but have little
>> experience with any of them, although I am user level expert with
>> Ant and Maven.  Are there any commercial solutions which are
>> currently way ahead of the above choices?
>
> I'm not aware of any other commercial solutions to this specific area
> myself. MSBuild is completely integrated with visual studio which is
> of benefit, though the available tasks I have found for it for the
> tools you refer to are limited.
>
> NAnt certainly has been around longer than NMaven and so is more
> mature and has more resources available for it. However, I believe
> NMaven is the closest to what you are ultimately looking for: being
> based on Maven you will already have the ability to run the tools
> you've described and use it from within any continuous integration
> server, and this is certainly where its objectives lay.
>
>> * Although i am convinced a maven based .NET build will potentially
>> one day satisfy all my requirements, I don't have a great grasp of
>> the status quo.  Is NMaven in its current state a better solution
>> for a very large project than other choices?
>
> I believe NMaven would be technically capable of meeting your needs
> for a large project, but there are a couple of caveats.
>
> Between the stage of the project and the fact that it is incubating,
> it is essential to become involved in the community in some way to get
> the most out of it. I'd say if you have some time to put in here it
> will be repaid, but it does still require that investment at the  
> moment.
>
> We currently only have one official release - 0.15. While this is much
> more suitable for some of your applications (since it is much more
> closely aligned to Maven's practices), it also lacks a lot of the
> features that are present in 0.14-SNAPSHOT. While we're working on
> (and looking for volunteers) to get involved in migrating that to the
> trunk now, using it now requires building an inhouse release and being
> involved here as you mentioned in a later question.
>
> I hope that helps clear it up.
>
> Cheers,
> 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: Questions regarding current state of C# build systems

James Carpenter-2
Where do I find the "long and winding discussions about the repository format"?  Is there a mailing list thread(s) on the maven dev list I should read?

--- On Tue, 9/2/08, Brett Porter <[hidden email]> wrote:

From: Brett Porter <[hidden email]>
Subject: Re: Questions regarding current state of C# build systems
To: [hidden email]
Date: Tuesday, September 2, 2008, 8:48 PM

Thanks for the detailed information. I think you have a solid grasp of  
it.

It also seems we need to spend some time documenting the status of:
- the long and winding discussions about the repository format
- support for C# authored plugins via a proxy in the future (in  
comparison to what was done in 0.14)

Cheers,
Brett

On 03/09/2008, at 1:44 AM, James Carpenter wrote:

>
> I still haven't hit the problem with the level of aggression I would  
> like to be able to devote to the effort.  Surface evaluations appear  
> to bear out my initial concerns that nothing is truly capable of  
> everything I need without significant development effort.
>
> ===========================================
> NMaven is still the front-runner.  I recognize this will involve  
> creating custom plugins and bug fixes here and there.  As long as I  
> am able to contribute such enhancements back to the NMaven project  
> and have them accepted this is much better than maintaining in-house
> build code (maven, ant, etc.).
>
> Showstopper Issues:
>
> * From past experience a couple years ago building C# with pre-
> NMaven .NET sandbox plugins as well as past discussions on this  
> mailing list the ability for the repository to store assemblies  
> without requiring versions in the file names (and assembly meta-
> data) is absolutely critical.  Nothing I have read so far indicates  
> the intent of the core nmaven developers regarding this functionality.
>
> Non-versioned assembly filenames were obviously available in the  
> 0.14 release but no longer appears to be on the trunk.  I completely  
> agree with the decision to move the nmaven plugins in alignment with  
> core maven, I just need to better understand the roadmap.  I don't  
> think this is a feature that can be omitted and have a workable  
> solution.  I have submitted a post to the mailing list on this issue  
> but I am yet to receive a response.
>
> If the effort required to teach the artifact resolver/nmaven to  
> handle an alternate repository layout for certain classes of  
> artifacts isn't too great I would consider taking it on.  I would  
> need a few pointers though as although I have written lots of custom  
> maven plugins I have never dug as deep into the maven internals as  
> this may require.  I also expect the nmaven developers have a better  
> idea than I as to what needs done.  I am only willing to take this  
> on if I can get my current employee to empower me to attack it.
>
> * From a sustainability standpoint any custom plugins I build should  
> be consistent with the 0.15+ architecture.  This is to say I don't  
> want to spend development time coding against a deprecated  
> architecture and I realize some amount of development will indeed be  
> necessary.
>
> Manageable Consequences of using NMaven at this stage:
>
> * I will need to create an in-house release of NMaven to provide the  
> necessary build stability until the time an appropriate formal  
> NMaven release is created.  This is a pain but by no means a show-
> stopper.
>
> * I will need to live without Visual Studio support for some period  
> of time.
>
> * I will likely have to create several report plugins.
>
> * Dependent builds in TeamCity will need to be manually configured  
> and/or I will need to figure out how to extend TeamCity to figure it  
> out on its own.
>
> * Selling the solution to those drinking the .NET cool-aid will be  
> difficult.  Even I would prefer an all .NET solution for building an  
> all .NET product.
>
> * I suspect any nmaven plugins will have to be authored in Java.  
> The ability to write .NET plugins in C# might help when trying to  
> call .NET tooling as opposed to making system calls on executables  
> pragmatically resolved via the artifact resolver.  I haven't  
> examined the NMaven trunk in great detail but it appears the C#  
> plugin support is no longer available.  Can C# based plugins make  
> use of component dependencies injected by plexus?  (i.e. Has some  
> fancy/complicated cross-vm proxy mechanism been implemented?)
>
> * I will spend a great deal of time training .NET developers/build  
> staff on how/why to use maven.
>
> ===============================
> The other decent choice is some combination of Ant/msbuild/Nant/Ivy  
> with TeamCity for CI.  The biggest advantage with this choice is the  
> appearance of using technologies more familiar to .NET developers.  
> The biggest drawback (as with any custom build system) is the  
> resulting build scripts quickly become more complicated than simply  
> learning a new technology which solves most of the problems out of  
> the box.
>
> It is also probably fair to say there are less likely to be major  
> technical complications with Ant/Nant/msbuild/Ivy which show up at  
> the last minute as there may be with nmaven.  The fact maven is  
> capable of so much results in a great deal more complexity.  
> Therefore when one runs into an issue which can't be addressed via  
> configuration and/or a simple plugin things get complicated  
> quickly.  This doesn't tend to happen much in maven built Java  
> projects as the road is pretty well paved at this point, but nmaven  
> is still very much on the bleeding edge.  The emotional response of  
> developers to problems with familiar technologies is often much  
> different than their response to similar issues with unfamiliar  
> technologies.
>
> ==============================
> In the end, I am still left needing to build a non-trivial prototype  
> build in both technologies in order to make a good decision.
>
> --- On Tue, 9/2/08, Brett Porter <[hidden email]> wrote:
>
> From: Brett Porter <[hidden email]>
> Subject: Re: Questions regarding current state of C# build systems
> To: [hidden email]
> Date: Tuesday, September 2, 2008, 2:36 AM
>
> Hi James,
>
> Sorry it has taken quite a while to reply, I've been behind on mail.
> You may have already made a decision, but it'd be great to hear what
> you found out.
>
> Thoughts inline...
>
> On 10/08/2008, at 9:36 AM, James Carpenter wrote:
>
>> ============================
>> Questions:
>>
>> I could use some advice on the current state of C# build tooling.
>>
>> * What choices are available and how would you contrast them?  I am
>> currently aware of NAnt, MSBuild and NMaven but have little
>> experience with any of them, although I am user level expert with
>> Ant and Maven.  Are there any commercial solutions which are
>> currently way ahead of the above choices?
>
> I'm not aware of any other commercial solutions to this specific area
> myself. MSBuild is completely integrated with visual studio which is
> of benefit, though the available tasks I have found for it for the
> tools you refer to are limited.
>
> NAnt certainly has been around longer than NMaven and so is more
> mature and has more resources available for it. However, I believe
> NMaven is the closest to what you are ultimately looking for: being
> based on Maven you will already have the ability to run the tools
> you've described and use it from within any continuous integration
> server, and this is certainly where its objectives lay.
>
>> * Although i am convinced a maven based .NET build will potentially
>> one day satisfy all my requirements, I don't have a great grasp of
>> the status quo.  Is NMaven in its current state a better solution
>> for a very large project than other choices?
>
> I believe NMaven would be technically capable of meeting your needs
> for a large project, but there are a couple of caveats.
>
> Between the stage of the project and the fact that it is incubating,
> it is essential to become involved in the community in some way to get
> the most out of it. I'd say if you have some time to put in here it
> will be repaid, but it does still require that investment at the  
> moment.
>
> We currently only have one official release - 0.15. While this is much
> more suitable for some of your applications (since it is much more
> closely aligned to Maven's practices), it also lacks a lot of the
> features that are present in 0.14-SNAPSHOT. While we're working on
> (and looking for volunteers) to get involved in migrating that to the
> trunk now, using it now requires building an inhouse release and being
> involved here as you mentioned in a later question.
>
> I hope that helps clear it up.
>
> Cheers,
> 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: Questions regarding current state of C# build systems

brettporter
Administrator

On 04/09/2008, at 1:32 AM, James Carpenter wrote:

> Where do I find the "long and winding discussions about the  
> repository format"?  Is there a mailing list thread(s) on the maven  
> dev list I should read?

Sorry, that's what I was referring to - it has come up a few times,  
and I don't think it has ever been summarised in one place. I don't  
have any direct pointers, but there would have been some on this list,  
dev@maven, and I believe some notes in the Maven wiki's.

- Brett

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

Reply | Threaded
Open this post in threaded view
|

Re: Questions regarding current state of C# build systems

Shane Isbell
I did a 180 (a long and winding 180), finally coming to the conclusion that
not having versions in the filename doesn't buy us all that much, at least
in open development environments.

My preference is that all .NET artifacts going into public repository should
be signed with a strong name. If this is the case, it doesn't really matter
whether an artifact is compiled with the version in the filename or not.
0.16 does support using of system scope for referencing an assembly locally
on the file system so that assemblies external to Maven can still be used.

Shane

On Wed, Sep 3, 2008 at 3:27 PM, Brett Porter <[hidden email]> wrote:

>
> On 04/09/2008, at 1:32 AM, James Carpenter wrote:
>
>  Where do I find the "long and winding discussions about the repository
>> format"?  Is there a mailing list thread(s) on the maven dev list I should
>> read?
>>
>
> Sorry, that's what I was referring to - it has come up a few times, and I
> don't think it has ever been summarised in one place. I don't have any
> direct pointers, but there would have been some on this list, dev@maven,
> and I believe some notes in the Maven wiki's.
>
> - Brett
>
>
> --
> Brett Porter
> [hidden email]
> http://blogs.exist.com/bporter/
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Questions regarding current state of C# build systems

James Carpenter-2
In general I believe its very important to support 3rd party assemblies without requiring re-compilation.  Due to the meta-data contained within an assembly and/or the digital signatures invvoled renaming an assembly is simply not an option.  I suppose it's ok to store assemblies in the repository in some archive format which includes a version in the file name, but all this needs to be undone by the time the compiler and/or CLR see them. 
 
On a related note, the pdb files and archives of the source associated with an assembly should also be stored in the repository.  The necessary magic to have the repository treated as a symbol server and source server will also need to be worked out.
 
Without addressing this issue, I simply don't see how NMaven will ever achieve broad acceptance and usage.  As you will notice from my earlier comments, for me this is an absolute show-stopper.  Some of the libraries I need to reference are indeed closed source and/or delivered by other teams within the company which manage their builds differently than mine.
 
I appreciate all the hard work and effort the core NMaven developers have done.  The level effort involved is not something I am personally willing to commit to the NMaven project, so I feel a litle bad complaining.
--- On Wed, 9/3/08, Shane Isbell <[hidden email]> wrote:

From: Shane Isbell <[hidden email]>
Subject: Re: Questions regarding current state of C# build systems
To: [hidden email]
Date: Wednesday, September 3, 2008, 5:50 PM

I did a 180 (a long and winding 180), finally coming to the conclusion that
not having versions in the filename doesn't buy us all that much, at least
in open development environments.

My preference is that all .NET artifacts going into public repository should
be signed with a strong name. If this is the case, it doesn't really matter
whether an artifact is compiled with the version in the filename or not.
0.16 does support using of system scope for referencing an assembly locally
on the file system so that assemblies external to Maven can still be used.

Shane

On Wed, Sep 3, 2008 at 3:27 PM, Brett Porter <[hidden email]> wrote:

>
> On 04/09/2008, at 1:32 AM, James Carpenter wrote:
>
>  Where do I find the "long and winding discussions about the
repository
>> format"?  Is there a mailing list thread(s) on the maven dev list
I should
>> read?
>>
>
> Sorry, that's what I was referring to - it has come up a few times,
and I
> don't think it has ever been summarised in one place. I don't have
any

> direct pointers, but there would have been some on this list, dev@maven,
> and I believe some notes in the Maven wiki's.
>
> - Brett
>
>
> --
> Brett Porter
> [hidden email]
> http://blogs.exist.com/bporter/
>
>
12