Dissolving Apache NMaven From ASF Incubator

[sisbell]

I'd like to let the general NMaven community know that we are dissolving
NMaven from the Apache Incubator and will be moving the project to Sonatype
Forge (http://sonatype.org) over the next week. I can't speak for all
members of the NMaven PPMC but my personal reasons are that after 2 years in
the incubator, we have failed to gain traction with the community. The
community involvement was quite active while NMaven was at sourceforge,
drying up very quickly after moving to ASF.

Looking back, I think there were a number of reasons for this. First, I
don't think the Apache brand name has as much appeal to the .NET crowd, so
it was easy for us to get buried. Second, we tied NMaven to a Maven 2.1
snapshot to support Visual Studio, and thus were stuck at a point where we
couldn't do a release. Finally, I took a divergent path from Maven
implementation, in part to solve problems with lack of toolchain support and
versionless artifact file names, and this made it difficult for Maven
developers to understand and to make contributions. The 0.15 release earlier
in the year was designed to address these problems. Yet we still didn't gain
much traction with the user or developer community, pointing to something
more fundamental.

Given these problems, I'd like to take NMaven to Sonatype Forge, giving it a
fresh start, getting back visibility, community involvement and a steady
release schedule. Now in regards to the future plans.

A number of .NET developers I talked to said that they while they liked
Maven and the concept of the Project Model, they didn't want to have to
install Java and Maven on their systems to use it. And finding developers
who know Maven, Java and .NET is not the easiest thing, so I'll be putting
in some time into Byldan (http://codeplex.com/byldan), a .NET version of
Maven.  I'm looking to port over the new 3.0 project builder code, so we can
start bringing the Byldan project model inline with Maven's pom. We can
build the plugins once in .NET and then execute them using either Byldan or
NMaven. The unreleased version 0.14 has this .NET plugin support, but that
code needs to be rewritten and/or cleaned up. We will need developers with
experience in app loading and app domains.

Another area I would like to focus on is the Visual Studio support. Eugene
has done a lot of work with the m2eclipse plugin, using Lucene indexing of
the the POMs for artifact searches, so I'm looking to create similar
functionality using Lucene.NET.

The final areas of focus are ones that we have been trying to solve from day
one: properly handling versionless artifact file names and doing toolchain
support, at both the client and server level. These problems are enormously
difficult to do against the web based repositories, so I will be looking to
integrate NMaven/Byldan with the Nexus Repo Manager Rest APIs, just pegging
the technology so we can get things moving more quickly. This should also
make things like PDB attached artifacts easier to handle.

I'll be posting more transition information over the coming week. Feel free
to shoot back with any questions or concerns.

Thanks,
Shane

[brettporter]

I have a number of perspectives on this, and have taken the time  
traveling over the last few days to reflect on this decision.

As a mentor, I can recognise the podling in its current form is not  
working. Contributions, patches, and questions have gone largely  
ignored this year, and development stalled after the migration to a  
new trunk. For a long time we have assumed that a kick in that  
direction was all that was needed to get it going again, but only  
small steps have been taken. Something clearly needs to change.

I don't believe the move you've suggested will make visibility,  
community involvement and a steady release schedule any more likely  
than it is now - they simply require a conscious decision and group  
effort to do so which could equally be achieved here.

My primary role in the project at the moment is as a user, distributor  
and occasional developer. There are two reasons your proposal won't  
satisfy our needs in that regard:
- we are committed to and required to maintain the code in an  
independent environment
- we require integration with Archiva for the search and management  
functionality

Do you have some alternative proposition here? I realise these may not  
be your personal "itches", but there are no technical reasons they  
can't be achieved by other community members that are interested in  
doing so while other work continues in the areas you've described.

I personally agree with the overarching technical direction you've  
described. In the long term, I see the .NET portions of this project  
doing much of the work independently, and this is also consistent with  
discussions I've had with others. However, Byldan hadn't seemed much  
more than an experiment to date - could you elaborate on where you  
think it stands to be able to provide a solution to Maven users today,  
or what kind of effort is required to bring it to that point?

I would still urge you to reconsider and give a renewed effort here to  
see what we can achieve by openly discussing the issues and roadmap  
for everyone that is interested in this project and seeing what comes  
of it.

However, if you don't believe that's feasible, I would be willing to  
champion an effort to try again afresh - either by restarting the  
podling (with Incubator and Maven PMC approval), or choosing a new  
location, and then migrating the current codebase to something more  
suitable with respect to any current users. Hopefully through regular  
communication we could converge over time while being free to  
experiment as needed.

Thanks,
Brett

On 14/11/2008, at 8:14 AM, Shane Isbell wrote:

> I'd like to let the general NMaven community know that we are  
> dissolving
> NMaven from the Apache Incubator and will be moving the project to  
> Sonatype
> Forge (http://sonatype.org) over the next week. I can't speak for all
> members of the NMaven PPMC but my personal reasons are that after 2  
> years in
> the incubator, we have failed to gain traction with the community. The
> community involvement was quite active while NMaven was at  
> sourceforge,
> drying up very quickly after moving to ASF.
>
> Looking back, I think there were a number of reasons for this.  
> First, I
> don't think the Apache brand name has as much appeal to the .NET  
> crowd, so
> it was easy for us to get buried. Second, we tied NMaven to a Maven  
> 2.1
> snapshot to support Visual Studio, and thus were stuck at a point  
> where we
> couldn't do a release. Finally, I took a divergent path from Maven
> implementation, in part to solve problems with lack of toolchain  
> support and
> versionless artifact file names, and this made it difficult for Maven
> developers to understand and to make contributions. The 0.15 release  
> earlier
> in the year was designed to address these problems. Yet we still  
> didn't gain
> much traction with the user or developer community, pointing to  
> something
> more fundamental.
>
> Given these problems, I'd like to take NMaven to Sonatype Forge,  
> giving it a
> fresh start, getting back visibility, community involvement and a  
> steady
> release schedule. Now in regards to the future plans.
>
> A number of .NET developers I talked to said that they while they  
> liked
> Maven and the concept of the Project Model, they didn't want to have  
> to
> install Java and Maven on their systems to use it. And finding  
> developers
> who know Maven, Java and .NET is not the easiest thing, so I'll be  
> putting
> in some time into Byldan (http://codeplex.com/byldan), a .NET  
> version of
> Maven.  I'm looking to port over the new 3.0 project builder code,  
> so we can
> start bringing the Byldan project model inline with Maven's pom. We  
> can
> build the plugins once in .NET and then execute them using either  
> Byldan or
> NMaven. The unreleased version 0.14 has this .NET plugin support,  
> but that
> code needs to be rewritten and/or cleaned up. We will need  
> developers with
> experience in app loading and app domains.
>
> Another area I would like to focus on is the Visual Studio support.  
> Eugene
> has done a lot of work with the m2eclipse plugin, using Lucene  
> indexing of
> the the POMs for artifact searches, so I'm looking to create similar
> functionality using Lucene.NET.
>
> The final areas of focus are ones that we have been trying to solve  
> from day
> one: properly handling versionless artifact file names and doing  
> toolchain
> support, at both the client and server level. These problems are  
> enormously
> difficult to do against the web based repositories, so I will be  
> looking to
> integrate NMaven/Byldan with the Nexus Repo Manager Rest APIs, just  
> pegging
> the technology so we can get things moving more quickly. This should  
> also
> make things like PDB attached artifacts easier to handle.
>
> I'll be posting more transition information over the coming week.  
> Feel free
> to shoot back with any questions or concerns.
>
> Thanks,
> Shane

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

[Jason van Zyl-3]

On 17-Nov-08, at 8:29 AM, Brett Porter wrote:

> I have a number of perspectives on this, and have taken the time  
> traveling over the last few days to reflect on this decision.
>
> As a mentor, I can recognise the podling in its current form is not  
> working. Contributions, patches, and questions have gone largely  
> ignored this year, and development stalled after the migration to a  
> new trunk. For a long time we have assumed that a kick in that  
> direction was all that was needed to get it going again, but only  
> small steps have been taken. Something clearly needs to change.
>
> I don't believe the move you've suggested will make visibility,  
> community involvement and a steady release schedule any more likely  
> than it is now - they simply require a conscious decision and group  
> effort to do so which could equally be achieved here.
>

All we know is that here did not work. All Shane wants to do is try a  
different approach.

> My primary role in the project at the moment is as a user,  
> distributor and occasional developer. There are two reasons your  
> proposal won't satisfy our needs in that regard:
> - we are committed to and required to maintain the code in an  
> independent environment
> - we require integration with Archiva for the search and management  
> functionality
>
> Do you have some alternative proposition here? I realise these may  
> not be your personal "itches", but there are no technical reasons  
> they can't be achieved by other community members that are  
> interested in doing so while other work continues in the areas  
> you've described.
>
> I personally agree with the overarching technical direction you've  
> described. In the long term, I see the .NET portions of this project  
> doing much of the work independently, and this is also consistent  
> with discussions I've had with others. However, Byldan hadn't seemed  
> much more than an experiment to date - could you elaborate on where  
> you think it stands to be able to provide a solution to Maven users  
> today, or what kind of effort is required to bring it to that point?
>

NMaven is useful for people who have hybrid approach: Java on the back-
end and .NET in the front-end. Byldan would be a pure .NET approach  
for Microsoft developers who are looking for an analog to Maven  
without the requirement of a Java runtime. For a shop that is already  
doing Java it's not a big stretch to use Java intermixed with C#. But  
for shops doing purely .NET I have found interest in NMaven to be  
slight at best. They are almost immediately turned off by having to  
install Java anything. Looking at your typical developer using  
Codeplex this is the profile that you have. They don't know anything  
about Java and don't want to know anything about Java. So NMaven  
provides the solution for the hybrid shop, Byldan is for a whole new  
and different user base. An attempt to bring a new set of users into a  
Maven way of developing software.

> I would still urge you to reconsider and give a renewed effort here  
> to see what we can achieve by openly discussing the issues and  
> roadmap for everyone that is interested in this project and seeing  
> what comes of it.
>

The majority of the IPMC members agree that I think the attempt here  
hasn't worked.

> However, if you don't believe that's feasible, I would be willing to  
> champion an effort to try again afresh - either by restarting the  
> podling (with Incubator and Maven PMC approval), or choosing a new  
> location, and then migrating the current codebase to something more  
> suitable with respect to any current users. Hopefully through  
> regular communication we could converge over time while being free  
> to experiment as needed.
>

It can only help to have more people working on it. I wish you luck  
with your endeavors.

> Thanks,
> Brett
>
> On 14/11/2008, at 8:14 AM, Shane Isbell wrote:
>
>> I'd like to let the general NMaven community know that we are  
>> dissolving
>> NMaven from the Apache Incubator and will be moving the project to  
>> Sonatype
>> Forge (http://sonatype.org) over the next week. I can't speak for all
>> members of the NMaven PPMC but my personal reasons are that after 2  
>> years in
>> the incubator, we have failed to gain traction with the community.  
>> The
>> community involvement was quite active while NMaven was at  
>> sourceforge,
>> drying up very quickly after moving to ASF.
>>
>> Looking back, I think there were a number of reasons for this.  
>> First, I
>> don't think the Apache brand name has as much appeal to the .NET  
>> crowd, so
>> it was easy for us to get buried. Second, we tied NMaven to a Maven  
>> 2.1
>> snapshot to support Visual Studio, and thus were stuck at a point  
>> where we
>> couldn't do a release. Finally, I took a divergent path from Maven
>> implementation, in part to solve problems with lack of toolchain  
>> support and
>> versionless artifact file names, and this made it difficult for Maven
>> developers to understand and to make contributions. The 0.15  
>> release earlier
>> in the year was designed to address these problems. Yet we still  
>> didn't gain
>> much traction with the user or developer community, pointing to  
>> something
>> more fundamental.
>>
>> Given these problems, I'd like to take NMaven to Sonatype Forge,  
>> giving it a
>> fresh start, getting back visibility, community involvement and a  
>> steady
>> release schedule. Now in regards to the future plans.
>>
>> A number of .NET developers I talked to said that they while they  
>> liked
>> Maven and the concept of the Project Model, they didn't want to  
>> have to
>> install Java and Maven on their systems to use it. And finding  
>> developers
>> who know Maven, Java and .NET is not the easiest thing, so I'll be  
>> putting
>> in some time into Byldan (http://codeplex.com/byldan), a .NET  
>> version of
>> Maven.  I'm looking to port over the new 3.0 project builder code,  
>> so we can
>> start bringing the Byldan project model inline with Maven's pom. We  
>> can
>> build the plugins once in .NET and then execute them using either  
>> Byldan or
>> NMaven. The unreleased version 0.14 has this .NET plugin support,  
>> but that
>> code needs to be rewritten and/or cleaned up. We will need  
>> developers with
>> experience in app loading and app domains.
>>
>> Another area I would like to focus on is the Visual Studio support.  
>> Eugene
>> has done a lot of work with the m2eclipse plugin, using Lucene  
>> indexing of
>> the the POMs for artifact searches, so I'm looking to create similar
>> functionality using Lucene.NET.
>>
>> The final areas of focus are ones that we have been trying to solve  
>> from day
>> one: properly handling versionless artifact file names and doing  
>> toolchain
>> support, at both the client and server level. These problems are  
>> enormously
>> difficult to do against the web based repositories, so I will be  
>> looking to
>> integrate NMaven/Byldan with the Nexus Repo Manager Rest APIs, just  
>> pegging
>> the technology so we can get things moving more quickly. This  
>> should also
>> make things like PDB attached artifacts easier to handle.
>>
>> I'll be posting more transition information over the coming week.  
>> Feel free
>> to shoot back with any questions or concerns.
>>
>> Thanks,
>> Shane
>
> --
> Brett Porter
> [hidden email]
> http://blogs.exist.com/bporter/
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

What matters is not ideas, but the people who have them. Good people  
can fix bad ideas, but good ideas can't save bad people.

  -- Paul Graham

[Christian Raschka-4]

I want to drop some thoughts into the discussion. We are a shop using
both Java and .Net. I am using Maven for all my projects and having a
build process which is based on Maven. Beside the well know benefits
of Maven, a big point for using it, is the versioning and
reproducibility. We have products and components which you could
easily put together in different versions. Maven (and the Archiva
Repository Server we use) helps us at this point.

Now I have seen NMaven and I tried to port the ideas of the Java World
to the .net one. At this point I have seen the (mentioned) problems
Maven has (for the .Net world). I also would like to help to NMaven
community, because I like the project very much, but it is very
confusing where to start. (There is a release (0.14) which seems to be
used, but for me it doesn't work. And there is the trunk, which I
think needs much work to be done, e.g. it seems important to have a VS
Plugin to generate solutions out of poms and vice versa.)

And thats the point. I don't know how a migration could solve this issue.

I also think, that you could use the help of the maven developer, if
there are problems, but I don't know how this was in the history.

I don't know how much maven related things could be reused by NMaven,
but I think reusing code is better as developing new things in an
other language. I think we should go out to the .net community and
show them what the benefits of NMaven are instead of simply
capitulating. I haven't seen something simular to maven in the .net
world.

In the next days I will talk to some german alt.net guys and see what
there opinion is.

[Caulene Tibbetts]

I agree, Christian.  We are also a large enterprise using both Java and
.NET, and using a Maven-based build process.  The clear benefits of using
NMaven are 1) use of the Archiva repository for binaries, 2) versioning
capability, 3) reproducibility, and 4) consistent tooling throughout the
enterprise.  We have been working off the 0.14 branch, but would love to
move over to the trunk as soon as the full functionality is available
there.

The VS interface has proven to be very valuable to us - it makes it easy to
port an existing project over to NMaven, as well as enabling users to use
NMaven for builds within the IDE.  There are a few items which could still
be cleaned up, but the main functionality is there.

The key to increasing adoption of NMaven is letting the .NET world know
about the functionality that is available - I've not been able to find
*any*other product that addresses versioning, reproducibility, or has
even a
vague concept of a binary repository.

[James Carpenter-2]

I'll go ahead and state the obvious.  Many of us here really like the  
idea of .NET support for maven, but very few of us are willing to  
devote the time and resources required to really move the ball  
forward.  Although I am personally willing to contribute minor  
enhancements here and there as my own needs arise, I'm not currently  
motivated enough to take on a primary contributor role for NMaven.  
Though I may disagree with some of Shane's early architectural  
decisions which originally took NMaven away from the maven core, Shane  
was actively developing NMaven while I largely sat on the sidelines.  
Although their opinions seem to vary a bit, I believe the postings by  
Shane and Brett collectively provide a fairly clear summary of why the  
project has not gained the level of adoption we would all like.

The harsh reality here is that a few individuals and/or an appropriate  
company or funder must step up to the plate or NMaven will die.  If  
anyone reading this is willing to devote the necessary time to the  
project, please consider taking on a more active role.  If any  
potential funder is willing to commit the funding necessary to  
maintain steady progress please indicate a willingness to do so or  
otherwise take action to engage appropriate individuals.  As with any  
software project, good senior talent isn't cheap so any funding  
probably needs to at least be in the 6 figure range (USD).  Much of  
this work will involve enhancements to the maven core, which will  
probably be more daunting than a junior engineer can easily handle.

On Dec 1, 2008, at 6:26 PM, Caulene Tibbetts wrote:

> I agree, Christian.  We are also a large enterprise using both Java  
> and
> .NET, and using a Maven-based build process.  The clear benefits of  
> using
> NMaven are 1) use of the Archiva repository for binaries, 2)  
> versioning
> capability, 3) reproducibility, and 4) consistent tooling throughout  
> the
> enterprise.  We have been working off the 0.14 branch, but would  
> love to
> move over to the trunk as soon as the full functionality is available
> there.
>
> The VS interface has proven to be very valuable to us - it makes it  
> easy to
> port an existing project over to NMaven, as well as enabling users  
> to use
> NMaven for builds within the IDE.  There are a few items which could  
> still
> be cleaned up, but the main functionality is there.
>
> The key to increasing adoption of NMaven is letting the .NET world  
> know
> about the functionality that is available - I've not been able to find
> *any*other product that addresses versioning, reproducibility, or has
> even a
> vague concept of a binary repository.

Sincerely,
James Carpenter
email: [hidden email]