Abel Muiņo wrote:

I've done several searches before writing that down and could find no information regarding Nexus Indexer license.

  I suggest you'd ask next time instead of guessing. If you were unable to find something it doesn't mean that it is not available.

It's great to know from you that the code is EPL... having online references explaining it would be even better.

  As you know, all open source projects rely on community that helps to improve code and documentation. But those who are interested to use the code can always ask questions that will be answered.

   Regardless of licensing issues, your choice of only supporting Nexus (Sonatype's indexing library) for artifact search is a bad decision for an eclipse project, since it limits opportunities for 3rd parties to extend the functionality (which keeps m2e very close to being a Sonatype-only tool instead of an integration techonology).

  I don't quite see what exactly brought you to such conclusion. It is true that we have been working with Sonatype to promote Nexus Indexer component, which allowed us to create the actual infrastructure for indexing and searching proprietary remote repositories.

  This was in response to Jason comments. Jason justified having only one search provider (Nexus) instead of an open (extensible) approach like IAM has. I think this is an error.

  No, it is not a mistake. We deliberately trying to create a standard component for indexing and searching Maven repositories. There is really little point for the end users to have pluggable search systems, it is just fractioning the toolset and only beneficial to vendors who are not interested in the open source. So, I strongly encourage you to join our efforts.

Also note that Nexus Indexer and Nexus repository manager are open source projects, so if someone want to extend or improve them, it is completely possible.

I fully understand that. But we're talking about Eclipse and EPL-compatible licenses. Nexus isn't. Nexus indexer might be... I'm not an expert lawyer.

  This isn't really place to discuss legal issues with Nexus repository manager. You are welcome to join Nexus mailing list and ask such questions there.

  I respectfully disagree with this. Like I already mentioned it is actually no different then Eclipse Orbit project.

The difference is clear... Orbit is part of the Eclipse Foundation, but the bundles are Sonatype's.

  When Carlos uploads Maven snapshots he built manually on his machine to the Apache snapshot repository, does that mean that they are Carlos'? I think not. As I said, we needed reliable infrastructure and because there wasn't any around, we have created one at Sonatype.

Besides, we do have all build tools published and anyone can reproduce the same build if needed.

That information is what I asked for in the previous message, and got no useful reply.

  Can you please avoid such offensive statements in the future.

  Anyways, information is actually on the wiki page at http://docs.codehaus.org/display/M2ECLIPSE/Configuring+Development+Environment

I've outlined one plan on the previous message.

The easier part to collaborate on are the editors, since they are isolated from most of the details of the embedding.

We have, at least, 2 editors being built by IAM/Q4E:

  So do we. What's now?

My proposal was to work together on these (my proposal was that you looked at IAM's code and integrated into M2E, but I think you already started from scratch) and provide a single implementation for IAM and M2E, developed outside of both ("neutral territory").

  As Jason already mentioned it is not a good idea to borrow code at this time and it is unclear to me how one would decide which implementation is better.

Other areas where we are duplicating functionality is on support for extensibility (which leads to WTP, AJDT, etc... support), but I think we should start with small steps, stablish common ground for both projects, know each other and, in time, progress to other areas.

  This is sounds good, though I am not really sure what it actually mean from the practical point of view.

Jason's response looked like a negative answer... that's why I asked for a clear confirmation.

  I don't think it wasn't negative and he raised several concerns that you chose to ignore.

but instead choose to make several negative claims about Sonatype.

I'm terribly sorry about that interpretation. It was never my intention to make negative claims about Sonatype... I just wanted to point out several "rough edges" on its approach to the Eclipse ecosystem.

  Actually, I think Sonatype company is a perfect fit to the Eclipse ecosystem, which is heavily dependent on commercial vendors. In fact Sonatype already provides resources and infrastructure that serves Maven community. So you could at least respect that.

For a Maven Integration project to be useful (as a technology, not as a product) it needs to be open. Having chosen to be tightly tied to a single solution (Nexus in this case) which is provided by a single company (which incidentally is the same company supporting the project) is a bad move for the ecosystem. It does not encourage participation which in turn decreases diversity.

  Again, you are getting it all wrong. There is nothing bad about open source components created by Sonatype and they are truly open to the community.

I'm not saying this as a way of criticize m2e. I'm justifying what could be gained from collaboration. I think I've demonstrated my will to collaborate both publicly, privately in the few emails exchanged (with Jason) and in the time I submitted patches to m2eclipse for WTP support (I even built and hosted the patched version).

  Well, I would say that it would have been better to everyone if you're continued supporting those patches and helped fix issues in m2eclipse, instead of creating new project.

My position is clear. Two eclipse projects doing the same thing is a waste of resources.
I hope that we can continue this conversation... but for that to happen the position of m2e must be clearly stated. Open to collaboration? (like I think you -Eugene- are) or not? (like I understand from Jason comments).

  I completely agree that is is a bad idea to have two projects doing the same thing. We didn't created such situation and I am glad to hear that you finally started to understand that too. So we are open to collaboration, but the problem is that it is practically impossible to merge two different codebases, or at least I don't see how we can do that. That is why I've asked you what exactly is your idea of collaboration.

  regards,
  Eugene