Need Some Feedback

[Shane Isbell <sh...@gmail.com>]

I noticed the discussion on the mailing list has been a bit slow lately,
even with the prospect of doing a release. Initially I had hopes to get to
graduation within 12 months, but I realize from a community perspective we
have a long way to go. So I wanted to get some feedback from everybody in
terms of what they think we can do to improve the situation.

I'm perfectly open to going back to the drawing board on any major issues.
I had hoped that the architecture for doing .NET plugins would bring in .NET
developers, but I don't see this happening. The platform matching is a
pretty big chunk of code that the community may not find interesting, so I
need to find out whether this should still be supported. RDF has, at best,
gotten lukewarm acceptance. Finally, we have the big issue of how to bring
.NET support into Maven itself.

Should we just start compiling a list of features and decide whether we need
them and then open up the design?

Shane

Re: Need Some Feedback

[Shane Isbell <sh...@gmail.com>]

Comments in line.

On 8/29/07, PeterNilsson <pe...@gmail.com> wrote:
>
>
> Hi,
>
> We are using Maven for building a multi-language project with both Java,
> C#
> and C++.
> For the C# projects we have been using NMaven since this spring. Currently
> we use a version of NMaven from late spring but we trying to upgrade to
> head
> as we speak.
>
> I haven't been coding that much C# myself (more Java and Maven) though so
> I
> apologize if some of my comments are off target.
>
> Given our aim our main priority is:
>
> 1) NMaven should be as tightly integrated with Maven as possible.


This has been a constant issue: to what degree do we diverge from Maven and
to what degree do we diverge from .NET standards? This revolves around two
central issues: 1) version in the file-names (this enforces certain implied
loading rules). 2) support for multiple vendors and framework versions. If
we can break apart (2) and/or add tool-chain support to Maven core, then
that solves half the problem. (1) is a little trickier, but I am okay with
going with versions in the filenames, provided that the group, in general,
accepts the limitations. It's worth it to have a separate discussion (and
possible vote) on this issue.

As we have a multi-language build all things that require special treatment
> are a problem.
> For example:
> - The repository layout should be identical to Maven (I am not enough into
> C# to understand the problem with having versions in dll names)


The current approach is to use an entirely different repo structure that
mirrors the GAC. For plugins - like the deploy and assembly plugins - that
require a default repository layout, there is a repository converter that
does a conversion from the GAC-style repo to the default repo. You could
attach the converter to the lifecycle and then run the plugin. But again, a
lot of these issues relate to (1).

- Maximum reuse of existing Maven plugins. For example, I have tried using
> the dependency plugin for extracting artifacts from the repository (both
> Java and C#) but it fails for C# artifacts because the type coordinate
> "library" is assumed to be file extension which means it won't find C#
> dlls.


I have encountered this problem myself. This is a bug within Maven itself,
as it doesn't load the custom artifact handlers from the
components.xmlfile. In certain cases, I have to do explicit loading of
artifact handlers
prior to plugins working. This is something we can address within Maven core
and/or the respective plugins.

- No local installation (except the compiler of course). NMaven should be
> downloaded from remote repository as other plugins. Currently we can't
> delete our local repos as we have to rerun bootstrap-build again then.


The latest version in the trunk can handle downloading of release (not
snapshot) versions.

- Snapshot support


I agree that this is important.

We only target Windows for C# so Mono support is not a priority for us.
> However, support for Visual Studio 2008 will become a priority very soon.
> We
> tried running bootstrap-build with Studio 2008 but it failed.
>
> Regarding generation of csproj or pom.xml we would prefer generating
> csproj
> from pom.xml in the same way as the eclipse plugin generates eclipse
> projects. In a multi-language environment common configuration (in pom.xml
> )
> is very valuable.
>
> To sum it up: A stable build that works as similar to Maven for Java as
> possible, possibly at the expense of C# specific features, is our target.


I think that this is the critical direction that we need to address. Not
only do we have issue (1) above but we also need to decide whether we follow
Maven standards (such as the directory structure) that don't play nicely
with Visual Studio 2005. It looks as though people are adopting NMaven to
support a standard build system for Java and C#; but we also have Amol's
case that developers on Visual Studio need to use NMaven without modifying
the pom.xml. I have a similar requirement from a customer that NMaven should
be invisible as possible. This is much easier to support if we move away
from or at least don't enforce Maven conventions. If we can find out how
people intend to use the system, then we can make these hard decisions.

Shane

  Peter
>
> --
> View this message in context:
> http://www.nabble.com/Need-Some-Feedback-tf4333020.html#a12392657
> Sent from the nmaven-dev mailing list archive at Nabble.com<http://nabble.com/>
> .
>
>

Re: Need Some Feedback

[PeterNilsson <pe...@gmail.com>]

Hi,

We are using Maven for building a multi-language project with both Java, C#
and C++.
For the C# projects we have been using NMaven since this spring. Currently
we use a version of NMaven from late spring but we trying to upgrade to head
as we speak.

I haven't been coding that much C# myself (more Java and Maven) though so I
apologize if some of my comments are off target.

Given our aim our main priority is:

1) NMaven should be as tightly integrated with Maven as possible.
 
As we have a multi-language build all things that require special treatment
are a problem. 
For example:
- The repository layout should be identical to Maven (I am not enough into
C# to understand the problem with having versions in dll names)
- Maximum reuse of existing Maven plugins. For example, I have tried using
the dependency plugin for extracting artifacts from the repository (both
Java and C#) but it fails for C# artifacts because the type coordinate
"library" is assumed to be file extension which means it won't find C# dlls. 
- No local installation (except the compiler of course). NMaven should be
downloaded from remote repository as other plugins. Currently we can't
delete our local repos as we have to rerun bootstrap-build again then.
- Snapshot support 

We only target Windows for C# so Mono support is not a priority for us.
However, support for Visual Studio 2008 will become a priority very soon. We
tried running bootstrap-build with Studio 2008 but it failed.

Regarding generation of csproj or pom.xml we would prefer generating csproj
from pom.xml in the same way as the eclipse plugin generates eclipse
projects. In a multi-language environment common configuration (in pom.xml)
is very valuable.

To sum it up: A stable build that works as similar to Maven for Java as
possible, possibly at the expense of C# specific features, is our target.

   Peter

-- 
View this message in context: http://www.nabble.com/Need-Some-Feedback-tf4333020.html#a12392657
Sent from the nmaven-dev mailing list archive at Nabble.com.

Re: Need Some Feedback

[Evan Worley <ev...@gmail.com>]

I would also like to re-iterate that we should set a CI server up to
continuously build NMaven.  This will ensure that the NMaven builds on more
than one person's machine, and should make contributors more confident when
making changes.

-Evan

On 8/27/07, Shane Isbell <sh...@gmail.com> wrote:
>
> Comments inline.
>
> On 8/27/07, Amol Manjure <am...@gmail.com> wrote:
> >
> > I work on a project that has .NET and Java components and Maven and
> > NMaven seem like a great way to combine the automated build process.
> >
> > However, the biggest issue I face is that most of the .NET developers
> > use Visual Studio to write code and run builds on their machines. A
> > lot of our build steps are built into the csproj files. We use Visual
> > Studio plugins to generate some of our code.
>
>
> We might be able to handle some of the code generation with maven plugins,
> for example the xsd or wsdl plugins. If we can start to get a list of
> these,
> we can investigate which are doable.
>
>
> > These issues need to be addressed in NMaven. The dynamic code
> > generation can be worked around by checking in generated files but the
> > post build steps and other aspects of the .NET project have to be
> > manually sync'ed.
> >
> > My first feature request would be being able to support csproj files
> > in some way without requiring someone to maintain the POM. This could
> > be done by parsing the csproj and generating a POM that provides the
> > same functionality or any other means that is appropriate. I am aware
> > of the feature whereby we can generate the csproj based on the POM but
> > that is not the normal use case for a developer who starts with a
> > csproj and wants a POM to reflect it.
>
>
> I hadn't planned on a csproj file to pom.xml converter for pre-existing
> csproj files but if there is a need we can put that in the roadmap.
> Currently, I generate a csproj file and pom.xml using a VS Wizard. The
> next
> step is to keep these in sync.
>
> Shane
>
> Amol
> >
> > On 8/27/07, Evan Worley <ev...@gmail.com> wrote:
> > > I think the mailing list is slow in general because there is really
> only
> > one
> > > core developer, and I don't see the benefit in you having design
> > discussions
> > > with yourself :).  If we can get more contributors involved, I think
> the
> > > discussions will flow naturally.  I continue to try to find time to
> get
> > > acquainted, but I find I can rarely keep up.  Now that things are
> > becoming
> > > more stable...?, it might be temping for people to get involved.
> > >
> > > I am personally very interested in seeing how the maven core can
> > supports
> > > .NET components.  One great starting point would be implementing a
> > surefire
> > > provider for nunit, a task that his been proven difficult or at least
> > > non-intuitive given the current surefire implementation.
> > >
> > > My 2 cents,
> > > Evan
> > >
> > > On 8/26/07, Shane Isbell <sh...@gmail.com> wrote:
> > > >
> > > > I noticed the discussion on the mailing list has been a bit slow
> > lately,
> > > > even with the prospect of doing a release. Initially I had hopes to
> > get to
> > > > graduation within 12 months, but I realize from a community
> > perspective we
> > > > have a long way to go. So I wanted to get some feedback from
> everybody
> > in
> > > > terms of what they think we can do to improve the situation.
> > > >
> > > > I'm perfectly open to going back to the drawing board on any major
> > issues.
> > > > I had hoped that the architecture for doing .NET plugins would bring
> > in
> > > > .NET
> > > > developers, but I don't see this happening. The platform matching is
> a
> > > > pretty big chunk of code that the community may not find
> interesting,
> > so I
> > > > need to find out whether this should still be supported. RDF has, at
> > best,
> > > > gotten lukewarm acceptance. Finally, we have the big issue of how to
> > bring
> > > > .NET support into Maven itself.
> > > >
> > > > Should we just start compiling a list of features and decide whether
> > we
> > > > need
> > > > them and then open up the design?
> > > >
> > > > Shane
> > > >
> > >
> >
>

Re: Need Some Feedback

[Shane Isbell <sh...@gmail.com>]

Comments inline.

On 8/27/07, Amol Manjure <am...@gmail.com> wrote:
>
> I work on a project that has .NET and Java components and Maven and
> NMaven seem like a great way to combine the automated build process.
>
> However, the biggest issue I face is that most of the .NET developers
> use Visual Studio to write code and run builds on their machines. A
> lot of our build steps are built into the csproj files. We use Visual
> Studio plugins to generate some of our code.


We might be able to handle some of the code generation with maven plugins,
for example the xsd or wsdl plugins. If we can start to get a list of these,
we can investigate which are doable.


> These issues need to be addressed in NMaven. The dynamic code
> generation can be worked around by checking in generated files but the
> post build steps and other aspects of the .NET project have to be
> manually sync'ed.
>
> My first feature request would be being able to support csproj files
> in some way without requiring someone to maintain the POM. This could
> be done by parsing the csproj and generating a POM that provides the
> same functionality or any other means that is appropriate. I am aware
> of the feature whereby we can generate the csproj based on the POM but
> that is not the normal use case for a developer who starts with a
> csproj and wants a POM to reflect it.


 I hadn't planned on a csproj file to pom.xml converter for pre-existing
csproj files but if there is a need we can put that in the roadmap.
Currently, I generate a csproj file and pom.xml using a VS Wizard. The next
step is to keep these in sync.

Shane

Amol
>
> On 8/27/07, Evan Worley <ev...@gmail.com> wrote:
> > I think the mailing list is slow in general because there is really only
> one
> > core developer, and I don't see the benefit in you having design
> discussions
> > with yourself :).  If we can get more contributors involved, I think the
> > discussions will flow naturally.  I continue to try to find time to get
> > acquainted, but I find I can rarely keep up.  Now that things are
> becoming
> > more stable...?, it might be temping for people to get involved.
> >
> > I am personally very interested in seeing how the maven core can
> supports
> > .NET components.  One great starting point would be implementing a
> surefire
> > provider for nunit, a task that his been proven difficult or at least
> > non-intuitive given the current surefire implementation.
> >
> > My 2 cents,
> > Evan
> >
> > On 8/26/07, Shane Isbell <sh...@gmail.com> wrote:
> > >
> > > I noticed the discussion on the mailing list has been a bit slow
> lately,
> > > even with the prospect of doing a release. Initially I had hopes to
> get to
> > > graduation within 12 months, but I realize from a community
> perspective we
> > > have a long way to go. So I wanted to get some feedback from everybody
> in
> > > terms of what they think we can do to improve the situation.
> > >
> > > I'm perfectly open to going back to the drawing board on any major
> issues.
> > > I had hoped that the architecture for doing .NET plugins would bring
> in
> > > .NET
> > > developers, but I don't see this happening. The platform matching is a
> > > pretty big chunk of code that the community may not find interesting,
> so I
> > > need to find out whether this should still be supported. RDF has, at
> best,
> > > gotten lukewarm acceptance. Finally, we have the big issue of how to
> bring
> > > .NET support into Maven itself.
> > >
> > > Should we just start compiling a list of features and decide whether
> we
> > > need
> > > them and then open up the design?
> > >
> > > Shane
> > >
> >
>

Re: Need Some Feedback

[Shane Isbell <sh...@gmail.com>]

We would have to raise the issue of how long it would take for the tool
chain support on the general maven dev list (although Jason may have some
idea). An alternative approach would be to breakout and generalize
the dotnet-executable and dotnet-vendor components to handle J2ME and J2SE
compilers and executables. The dotnet-vendor is a state machine that fills
in missing vendor info (vendor name, vendor version, framework version) and
finds executable paths, etc. Many of the APIs would work for Java but it
would need a different state-machine implementation. This state-machine
implementation would need to be pluggable.

The dotnet-executable is fairly generalized at a low level (meaning the conf
files and lower-level constructs should not need a lot of changes); but the
API itself is .NET specific so there would be a lot of changes at this
level. All in all, if you have a descent grasp of the code its about 3-4 man
weeks of work. To get this integrated into Maven core, I couldn't say at
this point. We'd need to look into that by creating a simple prototype.

To understand more on how this works:
http://incubator.apache.org/nmaven/environment-configuration.html
http://incubator.apache.org/nmaven/adding-executables.html

Shane

On 8/27/07, David Lewis <dl...@novell.com> wrote:
>
>
> We're developing Java and .NET components for both Window and
> Linux.  We're
> not currently using NMaven for the .NET components, but we'd like to
> convert
> them to use it in the near future.  We would need support for Mono to do
> this.  If you were to yank out support, how long do you think it would
> take
> to work it back in?  I think there are a couple of us in my group that
> would
> be willing to contribute if that would
> help speed it along.
>
> --David
>
>
> Shane Isbell wrote:
> >
> > Thanks Amol and Evan. It sounds as though most of the current users of
> > NMaven 1)  have dual Java/.NET environments and 2) are using
> > Microsoft/Visual Studio (not Mono).  With (1), the divergence of Maven
> and
> > NMaven is a problem. In regards to (2), I am wondering if Mono support
> > should be required at this point. Multi-vendor support is a big part of
> > the
> > code base complexity and makes integrating into Maven core problematic.
> We
> > may be able to remove that support and then work it back in within the
> > context of the current tool chain work being done within Maven core. Is
> > anybody on the list using Mono or planning on using Mono with NMaven?
> >
> > Shane
> >
> >
> > On 8/27/07, Amol Manjure <am...@gmail.com> wrote:
> >>
> >> I work on a project that has .NET and Java components and Maven and
> >> NMaven seem like a great way to combine the automated build process.
> >>
> >> However, the biggest issue I face is that most of the .NET developers
> >> use Visual Studio to write code and run builds on their machines. A
> >> lot of our build steps are built into the csproj files. We use Visual
> >> Studio plugins to generate some of our code.
> >>
> >> These issues need to be addressed in NMaven. The dynamic code
> >> generation can be worked around by checking in generated files but the
> >> post build steps and other aspects of the .NET project have to be
> >> manually sync'ed.
> >>
> >> My first feature request would be being able to support csproj files
> >> in some way without requiring someone to maintain the POM. This could
> >> be done by parsing the csproj and generating a POM that provides the
> >> same functionality or any other means that is appropriate. I am aware
> >> of the feature whereby we can generate the csproj based on the POM but
> >> that is not the normal use case for a developer who starts with a
> >> csproj and wants a POM to reflect it.
> >>
> >> Amol
> >>
> >> On 8/27/07, Evan Worley <ev...@gmail.com> wrote:
> >> > I think the mailing list is slow in general because there is really
> >> only
> >> one
> >> > core developer, and I don't see the benefit in you having design
> >> discussions
> >> > with yourself :).  If we can get more contributors involved, I think
> >> the
> >> > discussions will flow naturally.  I continue to try to find time to
> get
> >> > acquainted, but I find I can rarely keep up.  Now that things are
> >> becoming
> >> > more stable...?, it might be temping for people to get involved.
> >> >
> >> > I am personally very interested in seeing how the maven core can
> >> supports
> >> > .NET components.  One great starting point would be implementing a
> >> surefire
> >> > provider for nunit, a task that his been proven difficult or at least
> >> > non-intuitive given the current surefire implementation.
> >> >
> >> > My 2 cents,
> >> > Evan
> >> >
> >> > On 8/26/07, Shane Isbell <sh...@gmail.com> wrote:
> >> > >
> >> > > I noticed the discussion on the mailing list has been a bit slow
> >> lately,
> >> > > even with the prospect of doing a release. Initially I had hopes to
> >> get to
> >> > > graduation within 12 months, but I realize from a community
> >> perspective we
> >> > > have a long way to go. So I wanted to get some feedback from
> >> everybody
> >> in
> >> > > terms of what they think we can do to improve the situation.
> >> > >
> >> > > I'm perfectly open to going back to the drawing board on any major
> >> issues.
> >> > > I had hoped that the architecture for doing .NET plugins would
> bring
> >> in
> >> > > .NET
> >> > > developers, but I don't see this happening. The platform matching
> is
> >> a
> >> > > pretty big chunk of code that the community may not find
> interesting,
> >> so I
> >> > > need to find out whether this should still be supported. RDF has,
> at
> >> best,
> >> > > gotten lukewarm acceptance. Finally, we have the big issue of how
> to
> >> bring
> >> > > .NET support into Maven itself.
> >> > >
> >> > > Should we just start compiling a list of features and decide
> whether
> >> we
> >> > > need
> >> > > them and then open up the design?
> >> > >
> >> > > Shane
> >> > >
> >> >
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Need-Some-Feedback-tf4333020.html#a12356780
> Sent from the nmaven-dev mailing list archive at Nabble.com.
>
>

Re: Need Some Feedback

[David Lewis <dl...@novell.com>]

We're developing Java and .NET components for both Window and Linux.  We're
not currently using NMaven for the .NET components, but we'd like to convert
them to use it in the near future.  We would need support for Mono to do
this.  If you were to yank out support, how long do you think it would take
to work it back in?  I think there are a couple of us in my group that would
be willing to contribute if that would 
help speed it along.  

--David


Shane Isbell wrote:
> 
> Thanks Amol and Evan. It sounds as though most of the current users of
> NMaven 1)  have dual Java/.NET environments and 2) are using
> Microsoft/Visual Studio (not Mono).  With (1), the divergence of Maven and
> NMaven is a problem. In regards to (2), I am wondering if Mono support
> should be required at this point. Multi-vendor support is a big part of
> the
> code base complexity and makes integrating into Maven core problematic. We
> may be able to remove that support and then work it back in within the
> context of the current tool chain work being done within Maven core. Is
> anybody on the list using Mono or planning on using Mono with NMaven?
> 
> Shane
> 
> 
> On 8/27/07, Amol Manjure <am...@gmail.com> wrote:
>>
>> I work on a project that has .NET and Java components and Maven and
>> NMaven seem like a great way to combine the automated build process.
>>
>> However, the biggest issue I face is that most of the .NET developers
>> use Visual Studio to write code and run builds on their machines. A
>> lot of our build steps are built into the csproj files. We use Visual
>> Studio plugins to generate some of our code.
>>
>> These issues need to be addressed in NMaven. The dynamic code
>> generation can be worked around by checking in generated files but the
>> post build steps and other aspects of the .NET project have to be
>> manually sync'ed.
>>
>> My first feature request would be being able to support csproj files
>> in some way without requiring someone to maintain the POM. This could
>> be done by parsing the csproj and generating a POM that provides the
>> same functionality or any other means that is appropriate. I am aware
>> of the feature whereby we can generate the csproj based on the POM but
>> that is not the normal use case for a developer who starts with a
>> csproj and wants a POM to reflect it.
>>
>> Amol
>>
>> On 8/27/07, Evan Worley <ev...@gmail.com> wrote:
>> > I think the mailing list is slow in general because there is really
>> only
>> one
>> > core developer, and I don't see the benefit in you having design
>> discussions
>> > with yourself :).  If we can get more contributors involved, I think
>> the
>> > discussions will flow naturally.  I continue to try to find time to get
>> > acquainted, but I find I can rarely keep up.  Now that things are
>> becoming
>> > more stable...?, it might be temping for people to get involved.
>> >
>> > I am personally very interested in seeing how the maven core can
>> supports
>> > .NET components.  One great starting point would be implementing a
>> surefire
>> > provider for nunit, a task that his been proven difficult or at least
>> > non-intuitive given the current surefire implementation.
>> >
>> > My 2 cents,
>> > Evan
>> >
>> > On 8/26/07, Shane Isbell <sh...@gmail.com> wrote:
>> > >
>> > > I noticed the discussion on the mailing list has been a bit slow
>> lately,
>> > > even with the prospect of doing a release. Initially I had hopes to
>> get to
>> > > graduation within 12 months, but I realize from a community
>> perspective we
>> > > have a long way to go. So I wanted to get some feedback from
>> everybody
>> in
>> > > terms of what they think we can do to improve the situation.
>> > >
>> > > I'm perfectly open to going back to the drawing board on any major
>> issues.
>> > > I had hoped that the architecture for doing .NET plugins would bring
>> in
>> > > .NET
>> > > developers, but I don't see this happening. The platform matching is
>> a
>> > > pretty big chunk of code that the community may not find interesting,
>> so I
>> > > need to find out whether this should still be supported. RDF has, at
>> best,
>> > > gotten lukewarm acceptance. Finally, we have the big issue of how to
>> bring
>> > > .NET support into Maven itself.
>> > >
>> > > Should we just start compiling a list of features and decide whether
>> we
>> > > need
>> > > them and then open up the design?
>> > >
>> > > Shane
>> > >
>> >
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/Need-Some-Feedback-tf4333020.html#a12356780
Sent from the nmaven-dev mailing list archive at Nabble.com.

Re: Need Some Feedback

[Shane Isbell <sh...@gmail.com>]

Thanks Amol and Evan. It sounds as though most of the current users of
NMaven 1)  have dual Java/.NET environments and 2) are using
Microsoft/Visual Studio (not Mono).  With (1), the divergence of Maven and
NMaven is a problem. In regards to (2), I am wondering if Mono support
should be required at this point. Multi-vendor support is a big part of the
code base complexity and makes integrating into Maven core problematic. We
may be able to remove that support and then work it back in within the
context of the current tool chain work being done within Maven core. Is
anybody on the list using Mono or planning on using Mono with NMaven?

Shane


On 8/27/07, Amol Manjure <am...@gmail.com> wrote:
>
> I work on a project that has .NET and Java components and Maven and
> NMaven seem like a great way to combine the automated build process.
>
> However, the biggest issue I face is that most of the .NET developers
> use Visual Studio to write code and run builds on their machines. A
> lot of our build steps are built into the csproj files. We use Visual
> Studio plugins to generate some of our code.
>
> These issues need to be addressed in NMaven. The dynamic code
> generation can be worked around by checking in generated files but the
> post build steps and other aspects of the .NET project have to be
> manually sync'ed.
>
> My first feature request would be being able to support csproj files
> in some way without requiring someone to maintain the POM. This could
> be done by parsing the csproj and generating a POM that provides the
> same functionality or any other means that is appropriate. I am aware
> of the feature whereby we can generate the csproj based on the POM but
> that is not the normal use case for a developer who starts with a
> csproj and wants a POM to reflect it.
>
> Amol
>
> On 8/27/07, Evan Worley <ev...@gmail.com> wrote:
> > I think the mailing list is slow in general because there is really only
> one
> > core developer, and I don't see the benefit in you having design
> discussions
> > with yourself :).  If we can get more contributors involved, I think the
> > discussions will flow naturally.  I continue to try to find time to get
> > acquainted, but I find I can rarely keep up.  Now that things are
> becoming
> > more stable...?, it might be temping for people to get involved.
> >
> > I am personally very interested in seeing how the maven core can
> supports
> > .NET components.  One great starting point would be implementing a
> surefire
> > provider for nunit, a task that his been proven difficult or at least
> > non-intuitive given the current surefire implementation.
> >
> > My 2 cents,
> > Evan
> >
> > On 8/26/07, Shane Isbell <sh...@gmail.com> wrote:
> > >
> > > I noticed the discussion on the mailing list has been a bit slow
> lately,
> > > even with the prospect of doing a release. Initially I had hopes to
> get to
> > > graduation within 12 months, but I realize from a community
> perspective we
> > > have a long way to go. So I wanted to get some feedback from everybody
> in
> > > terms of what they think we can do to improve the situation.
> > >
> > > I'm perfectly open to going back to the drawing board on any major
> issues.
> > > I had hoped that the architecture for doing .NET plugins would bring
> in
> > > .NET
> > > developers, but I don't see this happening. The platform matching is a
> > > pretty big chunk of code that the community may not find interesting,
> so I
> > > need to find out whether this should still be supported. RDF has, at
> best,
> > > gotten lukewarm acceptance. Finally, we have the big issue of how to
> bring
> > > .NET support into Maven itself.
> > >
> > > Should we just start compiling a list of features and decide whether
> we
> > > need
> > > them and then open up the design?
> > >
> > > Shane
> > >
> >
>

Re: Need Some Feedback

[Amol Manjure <am...@gmail.com>]

I work on a project that has .NET and Java components and Maven and
NMaven seem like a great way to combine the automated build process.

However, the biggest issue I face is that most of the .NET developers
use Visual Studio to write code and run builds on their machines. A
lot of our build steps are built into the csproj files. We use Visual
Studio plugins to generate some of our code.

These issues need to be addressed in NMaven. The dynamic code
generation can be worked around by checking in generated files but the
post build steps and other aspects of the .NET project have to be
manually sync'ed.

My first feature request would be being able to support csproj files
in some way without requiring someone to maintain the POM. This could
be done by parsing the csproj and generating a POM that provides the
same functionality or any other means that is appropriate. I am aware
of the feature whereby we can generate the csproj based on the POM but
that is not the normal use case for a developer who starts with a
csproj and wants a POM to reflect it.

Amol

On 8/27/07, Evan Worley <ev...@gmail.com> wrote:
> I think the mailing list is slow in general because there is really only one
> core developer, and I don't see the benefit in you having design discussions
> with yourself :).  If we can get more contributors involved, I think the
> discussions will flow naturally.  I continue to try to find time to get
> acquainted, but I find I can rarely keep up.  Now that things are becoming
> more stable...?, it might be temping for people to get involved.
>
> I am personally very interested in seeing how the maven core can supports
> .NET components.  One great starting point would be implementing a surefire
> provider for nunit, a task that his been proven difficult or at least
> non-intuitive given the current surefire implementation.
>
> My 2 cents,
> Evan
>
> On 8/26/07, Shane Isbell <sh...@gmail.com> wrote:
> >
> > I noticed the discussion on the mailing list has been a bit slow lately,
> > even with the prospect of doing a release. Initially I had hopes to get to
> > graduation within 12 months, but I realize from a community perspective we
> > have a long way to go. So I wanted to get some feedback from everybody in
> > terms of what they think we can do to improve the situation.
> >
> > I'm perfectly open to going back to the drawing board on any major issues.
> > I had hoped that the architecture for doing .NET plugins would bring in
> > .NET
> > developers, but I don't see this happening. The platform matching is a
> > pretty big chunk of code that the community may not find interesting, so I
> > need to find out whether this should still be supported. RDF has, at best,
> > gotten lukewarm acceptance. Finally, we have the big issue of how to bring
> > .NET support into Maven itself.
> >
> > Should we just start compiling a list of features and decide whether we
> > need
> > them and then open up the design?
> >
> > Shane
> >
>

Re: Need Some Feedback

[Evan Worley <ev...@gmail.com>]

I think the mailing list is slow in general because there is really only one
core developer, and I don't see the benefit in you having design discussions
with yourself :).  If we can get more contributors involved, I think the
discussions will flow naturally.  I continue to try to find time to get
acquainted, but I find I can rarely keep up.  Now that things are becoming
more stable...?, it might be temping for people to get involved.

I am personally very interested in seeing how the maven core can supports
.NET components.  One great starting point would be implementing a surefire
provider for nunit, a task that his been proven difficult or at least
non-intuitive given the current surefire implementation.

My 2 cents,
Evan

On 8/26/07, Shane Isbell <sh...@gmail.com> wrote:
>
> I noticed the discussion on the mailing list has been a bit slow lately,
> even with the prospect of doing a release. Initially I had hopes to get to
> graduation within 12 months, but I realize from a community perspective we
> have a long way to go. So I wanted to get some feedback from everybody in
> terms of what they think we can do to improve the situation.
>
> I'm perfectly open to going back to the drawing board on any major issues.
> I had hoped that the architecture for doing .NET plugins would bring in
> .NET
> developers, but I don't see this happening. The platform matching is a
> pretty big chunk of code that the community may not find interesting, so I
> need to find out whether this should still be supported. RDF has, at best,
> gotten lukewarm acceptance. Finally, we have the big issue of how to bring
> .NET support into Maven itself.
>
> Should we just start compiling a list of features and decide whether we
> need
> them and then open up the design?
>
> Shane
>