Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » IAM (Eclipse Integration for Apache Maven) » Re: Adding Lukáš Křečan as a committer on m2eclipse
Re: Adding Lukáš Křečan as a committer on m2eclipse [message #8676] Sat, 10 May 2008 16:20 Go to next message
Abel Mui is currently offline Abel MuiFriend
Messages: 247
Registered: July 2009
Senior Member
(CC iam newsgroup)

Since this editors (and the Doxia ones) are tooling around maven, I'm
fairly sure that they can be shared.

In IAM/q4e we already have this work started and the form based pom is
quite evolved too. It would be a shame to start all over again for m2e.

What I'm proposing is creating a common ground both projects can use.
For example, high level editors (not limited to pom, settings, etc...
also doxia) and maven bundles (the embedder, doxia or other plug-ins).

Would you be interested?

Jason van Zyl wrote:
> Hi,
>
> I'm happy to announce that Lukáš Křečan will be joining the
> m2eclipse team. Lukáš is the author of mvnindex and he's created an
> indexing mechanism similar to what we have done with Nexus, and he has
> a structured editor for Maven POM. We are now going to be
> collaborating on integrating the indexing technologies, and Eugene
> will be working with Lukáš to integrate the collective work on editors
> into one cohesive framework for editing POMs. Lukáš is a great
> addition to the team and we're glad to have him aboard.
>
> Thanks,
>
> Jason.
>
>
Re: Adding Lukáš Křečan as a committer on m2eclipse [message #8688 is a reply to message #8676] Sat, 10 May 2008 17:59 Go to previous messageGo to next message
Eugene Kuleshov is currently offline Eugene KuleshovFriend
Messages: 504
Registered: July 2009
Senior Member
Abel Muiño Vizcaino wrote:
> In IAM/q4e we already have this work started and the form based pom is
> quite evolved too. It would be a shame to start all over again for m2e.
Just to clarify, m2eclipse as well already have good progress on the
pom editor.
> What I'm proposing is creating a common ground both projects can use.
> For example, high level editors (not limited to pom, settings, etc...
> also doxia) and maven bundles (the embedder, doxia or other plug-ins).
>
> Would you be interested?
I'd be glad to see such cooperation, though your own project pages
state that there are technical differences between q4e and m2eclipse, so
it is unclear what can be actually shared and it would be interesting to
see more technical details on that.

Another thing worth to mention is that we have osgi bundles created
for number of Maven components and those are available from m2eclipse
source control system (pretty much as from Orbit) as well as from Maven
repository we host at
http://repository.sonatype.org:8081/nexus/content/groups/mav en-eclipse/
and anyone is welcome to use those artifacts.

regards,
Eugene
Collaboration between IAM and M2E [message #8700 is a reply to message #8688] Mon, 12 May 2008 19:39 Go to previous messageGo to next message
Abel Mui is currently offline Abel MuiFriend
Messages: 247
Registered: July 2009
Senior Member
Eugene Kuleshov wrote:
> I'd be glad to see such cooperation, though your own project pages
> state that there are technical differences between q4e and m2eclipse,
> so it is unclear what can be actually shared and it would be
> interesting to see more technical details on that.

Thanks for drawing my attention to that, it was written at the time of
m2eclipse 0.0.11 or 12, where the architecture was a single plug-in.
Since m2eclipse has been rewritten, the technical differences are less.
I've rewritten that section specific FAQ answer.

Differences that I can think of (and I speak for what I've read or been
told in the past) that still hold are:

Q4E is event-oriented, I believe that m2e uses the console and stdin/out.

A bigger one is tha m2eclipse forks and uses an external maven (for
running maven goals) while iam/q4e only uses the embedder. Our position
here is that it is the way to go, allowing deep integration and better
performance. It certainly has allowed us to quickly do things like the
dependency analysis view and some other "magic" in the maven incremental
builder.

On most other fronts, both projects have, or will achieve in the near
future, similar feature sets. Think of that:

- m2eclipse integrated the nexus index, and little time later, q4e also
can read it. We introduced one indirection layer so other search engines
could also be used... we feel that's the "Eclipse way", providing am
exemplary implementation but leaving the door open for others.

- iam/q4e provided autocompletion for dependencies on pom.xml, and
m2eclipse brings in Lukas Krecan, so I guess that soon you also will
have that.

- iam/q4e has had Forms-based pom editor under development during the
past releases, and m2e has started to prototype its own too.

- The extension points in q4e allowing third party (and, as an exemplary
implementation, WTP support) are also being implemented (in a different
flavor) in m2e...

I guess the same thing will happen with other high level features, and
that's just a waste of resources.

What I would suggest is that, as a stating point, you take a look at the
editors in q4e and detect what is preventing you from reusing them.
Together we'll see if that can be solved... just ask whatever you need
on q4e-dev[1]. Once a path of action is clear, we could just move common
parts to a "neutral" repository with committers from both teams (I'm
talking about collaboration, not plain reuse).
> Another thing worth to mention is that we have osgi bundles created
> for number of Maven components and those are available from m2eclipse
> source control system (pretty much as from Orbit) as well as from
> Maven repository we host at
> http://repository.sonatype.org:8081/nexus/content/groups/mav en-eclipse/
> and anyone is welcome to use those artifacts.
It would be great if those bundles were provided directly by the
apache/maven. It just seems the right thing to me... BTW: are the build
scripts available? It would not be wise to depend an Eclipse project
like IAM on them if they can't be rebuilt if needed.

Anyway, I think it would be a big plus for the embedder developers if
the bugs were reported against a single version.

I took a quick look at the embedder bundle and noticed the
"Eclipse-BuddyPolicy: dependent". In iam/q4e we've chosen "registered"
to allow choosing the specific plug-ins that need to be in the embedder
classpath. Why did you choose a broader option? Could this be changed in
your packaging to avoid accidentally placing elements in the classpath?

I'll be taking some steps to use your embedder bundle in IAM and see if
there's something else we would need.


Looking forward to hearing from you,
--
Abel Muiño Vizcaino - http://ramblingabout.wordpress.com
Re: Collaboration between IAM and M2E [message #8779 is a reply to message #8700] Fri, 16 May 2008 03:07 Go to previous messageGo to next message
Jason van Zyl is currently offline Jason van ZylFriend
Messages: 19
Registered: July 2009
Junior Member
On 2008-05-12 12:39:28 -0700, Abel Muiño Vizcaino <amuino@gmail.com> said:

> Eugene Kuleshov wrote:
>> I'd be glad to see such cooperation, though your own project pages
>> state that there are technical differences between q4e and m2eclipse,
>> so it is unclear what can be actually shared and it would be
>> interesting to see more technical details on that.
>
> Thanks for drawing my attention to that, it was written at the time of
> m2eclipse 0.0.11 or 12, where the architecture was a single plug-in.
> Since m2eclipse has been rewritten, the technical differences are less.
> I've rewritten that section specific FAQ answer.
>
> On most other fronts, both projects have, or will achieve in the near
> future, similar feature sets. Think of that:
>
> - m2eclipse integrated the nexus index, and little time later, q4e also
> can read it. We introduced one indirection layer so other search
> engines could also be used... we feel that's the "Eclipse way",
> providing am exemplary implementation but leaving the door open for
> others.

We needed something that worked so we focused on Nexus Indexer, which
is already the defacto standard. It's integrated into all three major
IDEs and it's an open source component under a license that can be used
by everyone. Our library not only provides the framework for creating
the indices but provides the infrastructure for working with the
indices. So we provide tools to create the indices and operate on the
indices. This work really doesn't need to be duplicated.

> - iam/q4e provided autocompletion for dependencies on pom.xml, and
> m2eclipse brings in Lukas Krecan, so I guess that soon you also will
> have that.

We are pretty happy with the contribution from our community. Lukas and
Eugene have something very good already. Eugene made some pretty
awesome progress with the help of Lukas:

http://www.jroller.com/eu/entry/maven_pom_xml_editor

>
> - iam/q4e has had Forms-based pom editor under development during the
> past releases, and m2e has started to prototype its own too.
>
> - The extension points in q4e allowing third party (and, as an
> exemplary implementation, WTP support) are also being implemented (in a
> different flavor) in m2e...
>
> I guess the same thing will happen with other high level features, and
> that's just a waste of resources.
>
> What I would suggest is that, as a stating point, you take a look at
> the editors in q4e and detect what is preventing you from reusing them.
> Together we'll see if that can be solved... just ask whatever you need
> on q4e-dev[1]. Once a path of action is clear, we could just move
> common parts to a "neutral" repository with committers from both teams
> (I'm talking about collaboration, not plain reuse).

We've decided to go the route of accepting code from our community and
making the contributor a committer on our project. Additionally since a
member of your team made an IP claim about some of our code we honestly
feel it best from an IP perspective to wait until the IP process is
complete unless the code is directly contributed to the project with
the corresponding CLAs.

>> Another thing worth to mention is that we have osgi bundles created
>> for number of Maven components and those are available from m2eclipse
>> source control system (pretty much as from Orbit) as well as from Maven
>> repository we host at
>> http://repository.sonatype.org:8081/nexus/content/groups/mav en-eclipse/
>> and anyone is welcome to use those artifacts.
> It would be great if those bundles were provided directly by the
> apache/maven. It just seems the right thing to me... BTW: are the build
> scripts available? It would not be wise to depend an Eclipse project
> like IAM on them if they can't be rebuilt if needed.

No build scripts necessary. We are using Tycho and straight Maven to
build headless:
https://ci.sonatype.org/job/m2eclipse/143/

All good as shown in our instance of Hudson:
https://ci.sonatype.org/job/m2eclipse/143/console

You can also read this document to learn how to build m2e, as well as
external dependencies:
http://docs.codehaus.org/display/M2ECLIPSE/Configuring+Devel opment+Environment

Thanks,

Jason
Re: Collaboration between IAM and M2E [message #8793 is a reply to message #8779] Mon, 19 May 2008 17:29 Go to previous messageGo to next message
Abel Mui is currently offline Abel MuiFriend
Messages: 247
Registered: July 2009
Senior Member
Hi Jason,

I get from your reply that M2E is not willing to collaborate with
IAM? I'm a bit confused because Eugene showed interest in a previous
reply, so I would like to know what's the official position of the M2E
project. This is the most important thing I would like to get from this
conversation.

There are other topics on your reply that are also interesting...

Regarding reuse of the Nexus index component, IAM/Q4R is reusing the
indexes without using any code. Since Nexus is GPL, and the
indexer/reader is part of it (so it is also GPL) I don't think it would
be possible to reuse it in an Eclipse project. If Sonatype releases a
version of the component under EPL license, that would be much different.

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).

This is the first time I hear about the IP claims you mention. Since
you don't really say anything (what claims? what person? when? where?)
it all sounds like FUD. I'm sure that was not intention, so you should
clearly explain this.

Finally, about reusing the generated maven bundles, what I was
asking is for a way to build them by anyone under an EPL (or compatible
license), so if Sonatype decided to stop taking care of them, the rest
of the users could still generate updated versions. I find that having
those bundles (and the build process for generating them) in the Apache
Maven project would make a lot of sense, specially when it will not be
difficult for you to achieve.

I'm looking forward to hearing from you. I sincerely hope that the M2E
project can collaborate with IAM and find common ground. Both proposals
(soon to be projects) have the same goals and are duplicating the
effort. The IAM team has offered help so you don't have to re-implement
what we already have... now it is your choice to accept it and work
together or to refuse it and go against what Eclipse means.

Yours,
Abel Muiño

Jason van Zyl wrote:
> On 2008-05-12 12:39:28 -0700, Abel Muiño Vizcaino <amuino@gmail.com>
> said:
>
>> Eugene Kuleshov wrote:
>>> I'd be glad to see such cooperation, though your own project pages
>>> state that there are technical differences between q4e and
>>> m2eclipse, so it is unclear what can be actually shared and it would
>>> be interesting to see more technical details on that.
>>
>> Thanks for drawing my attention to that, it was written at the time
>> of m2eclipse 0.0.11 or 12, where the architecture was a single
>> plug-in. Since m2eclipse has been rewritten, the technical
>> differences are less. I've rewritten that section specific FAQ answer.
>>
>> On most other fronts, both projects have, or will achieve in the near
>> future, similar feature sets. Think of that:
>>
>> - m2eclipse integrated the nexus index, and little time later, q4e
>> also can read it. We introduced one indirection layer so other search
>> engines could also be used... we feel that's the "Eclipse way",
>> providing am exemplary implementation but leaving the door open for
>> others.
>
> We needed something that worked so we focused on Nexus Indexer, which
> is already the defacto standard. It's integrated into all three major
> IDEs and it's an open source component under a license that can be
> used by everyone. Our library not only provides the framework for
> creating the indices but provides the infrastructure for working with
> the indices. So we provide tools to create the indices and operate on
> the indices. This work really doesn't need to be duplicated.
>
>> - iam/q4e provided autocompletion for dependencies on pom.xml, and
>> m2eclipse brings in Lukas Krecan, so I guess that soon you also will
>> have that.
>
> We are pretty happy with the contribution from our community. Lukas
> and Eugene have something very good already. Eugene made some pretty
> awesome progress with the help of Lukas:
>
> http://www.jroller.com/eu/entry/maven_pom_xml_editor
>
>>
>> - iam/q4e has had Forms-based pom editor under development during the
>> past releases, and m2e has started to prototype its own too.
>>
>> - The extension points in q4e allowing third party (and, as an
>> exemplary implementation, WTP support) are also being implemented (in
>> a different flavor) in m2e...
>>
>> I guess the same thing will happen with other high level features,
>> and that's just a waste of resources.
>>
>> What I would suggest is that, as a stating point, you take a look at
>> the editors in q4e and detect what is preventing you from reusing
>> them. Together we'll see if that can be solved... just ask whatever
>> you need on q4e-dev[1]. Once a path of action is clear, we could just
>> move common parts to a "neutral" repository with committers from both
>> teams (I'm talking about collaboration, not plain reuse).
>
> We've decided to go the route of accepting code from our community and
> making the contributor a committer on our project. Additionally since
> a member of your team made an IP claim about some of our code we
> honestly feel it best from an IP perspective to wait until the IP
> process is complete unless the code is directly contributed to the
> project with the corresponding CLAs.
>
>>> Another thing worth to mention is that we have osgi bundles
>>> created for number of Maven components and those are available from
>>> m2eclipse source control system (pretty much as from Orbit) as well
>>> as from Maven repository we host at
>>> http://repository.sonatype.org:8081/nexus/content/groups/mav en-eclipse/
>>> and anyone is welcome to use those artifacts.
>> It would be great if those bundles were provided directly by the
>> apache/maven. It just seems the right thing to me... BTW: are the
>> build scripts available? It would not be wise to depend an Eclipse
>> project like IAM on them if they can't be rebuilt if needed.
>
> No build scripts necessary. We are using Tycho and straight Maven to
> build headless:
> https://ci.sonatype.org/job/m2eclipse/143/
>
> All good as shown in our instance of Hudson:
> https://ci.sonatype.org/job/m2eclipse/143/console
>
> You can also read this document to learn how to build m2e, as well as
> external dependencies:
> http://docs.codehaus.org/display/M2ECLIPSE/Configuring+Devel opment+Environment
>
>
> Thanks,
>
> Jason
>
Re: Collaboration between IAM and M2E [message #8804 is a reply to message #8793] Tue, 20 May 2008 02:25 Go to previous messageGo to next message
Eugene Kuleshov is currently offline Eugene KuleshovFriend
Messages: 504
Registered: July 2009
Senior Member
Abel Muiño Vizcaino wrote:
> Regarding reuse of the Nexus index component, IAM/Q4R is reusing
> the indexes without using any code. Since Nexus is GPL, and the
> indexer/reader is part of it (so it is also GPL) I don't think it
> would be possible to reuse it in an Eclipse project. If Sonatype
> releases a version of the component under EPL license, that would be
> much different.
Abel, before making such claims you should have checked Nexus Indexer
license. In fact it is EPL, which makes it perfect library to be used in
any Eclipse project. I would also say that using Nexus Indexer formats
outside it is generally a bad idea and would lead to incompatibilities.
> 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. 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.
> Finally, about reusing the generated maven bundles, what I was
> asking is for a way to build them by anyone under an EPL (or
> compatible license), so if Sonatype decided to stop taking care of
> them, the rest of the users could still generate updated versions. I
> find that having those bundles (and the build process for generating
> them) in the Apache Maven project would make a lot of sense, specially
> when it will not be difficult for you to achieve.
I respectfully disagree with this. Like I already mentioned it is
actually no different then Eclipse Orbit project. Besides, we do have
all build tools published and anyone can reproduce the same build if
needed. More over, at the moment Apache don't really have reliable
infrastructure and we believe that bundles available from Sonatype
currently more trusted, because they are created with direct
participation of several Maven committers.
> I'm looking forward to hearing from you. I sincerely hope that the M2E
> project can collaborate with IAM and find common ground.
You haven't actually answered my question on what exactly is your idea
of collaboration with m2e project, but instead choose to make several
negative claims about Sonatype.

regards,
Eugene
Re: Collaboration between IAM and M2E [message #8813 is a reply to message #8804] Tue, 20 May 2008 13:31 Go to previous messageGo to next message
Abel Mui is currently offline Abel MuiFriend
Messages: 247
Registered: July 2009
Senior Member
Eugene Kuleshov wrote:

> Abel Muiño Vizcaino wrote:
>> Regarding reuse of the Nexus index component, IAM/Q4R is reusing
>> the indexes without using any code. Since Nexus is GPL, and the
>> indexer/reader is part of it (so it is also GPL) I don't think it
>> would be possible to reuse it in an Eclipse project. If Sonatype
>> releases a version of the component under EPL license, that would be
>> much different.
> Abel, before making such claims you should have checked Nexus Indexer
> license. In fact it is EPL, which makes it perfect library to be used in
> any Eclipse project.

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

The closest match is the Nexus CLI
(http://docs.codehaus.org/display/M2ECLIPSE/Nexus+Indexer), which is
downloadable from the Nexus download site... and Nexus is GPL. If the code
is EPL, it could not be packaged with Nexus unless it has double
licensing. I haven't found any reference to that, so (being no lawyer)
this situation is confusing, at best.

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

>> 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.

> 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.

>> Finally, about reusing the generated maven bundles, what I was
>> asking is for a way to build them by anyone under an EPL (or
>> compatible license), so if Sonatype decided to stop taking care of
>> them, the rest of the users could still generate updated versions. I
>> find that having those bundles (and the build process for generating
>> them) in the Apache Maven project would make a lot of sense, specially
>> when it will not be difficult for you to achieve.
> 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.

> 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.

>> I'm looking forward to hearing from you. I sincerely hope that the M2E
>> project can collaborate with IAM and find common ground.
> You haven't actually answered my question on what exactly is your idea
> of collaboration with m2e project

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:
- xml pom editor: autocompletion based on the indexer info (here's where
having a single Open Search Framework can help).
- form-based pom editor: it can leverage maven metadata.

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").

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.

That was our (IAM's) proposal (if you are willing to propose another path,
please do so). Jason's response looked like a negative answer... that's
why I asked for a clear confirmation.

> 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.

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.

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).

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).

Thanks for your time!
--
Abel Muiño
Re: Collaboration between IAM and M2E [message #8820 is a reply to message #8813] Tue, 20 May 2008 15:55 Go to previous messageGo to next message
Andrew Niefer is currently offline Andrew NieferFriend
Messages: 990
Registered: July 2009
Senior Member
Hi Guys,
As a committer on PDE/Build, Equinox, and P2, I'm standing somewhere
close to the center of where integration between the core Eclipse and
m2e/iam may occur.

From a purely selfish standpoint, learning two projects is a lot more
work than learning one :) At this point, I couldn't tell you what the
difference between the two projects is.

Any point of integration with p2/pde/equinox would be an excellent place
for collaboration between iam and m2e.

-Andrew



Abel Muiño wrote:
> Eugene Kuleshov wrote:
>
>> Abel Muiño Vizcaino wrote:
>>> I'm looking forward to hearing from you. I sincerely hope that the
>>> M2E project can collaborate with IAM and find common ground.
>> You haven't actually answered my question on what exactly is your
>> idea of collaboration with m2e 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).
>
> Thanks for your time!
> --
> Abel Muiño
>
Re: Collaboration between IAM and M2E [message #10848 is a reply to message #8813] Tue, 20 May 2008 16:03 Go to previous messageGo to next message
Eugene Kuleshov is currently offline Eugene KuleshovFriend
Messages: 504
Registered: July 2009
Senior Member
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+Devel opment+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
Re: Collaboration between IAM and M2E [message #10862 is a reply to message #10848] Tue, 20 May 2008 19:02 Go to previous messageGo to next message
Abel Mui is currently offline Abel MuiFriend
Messages: 247
Registered: July 2009
Senior Member
I think that we could just "agree to disagree" regarding the focus on
Sonatype products.

Regarding collaborating on the editors, when I wrote "we have" I was
meaning IAM and M2E as you correctly pointed out. That is, precisely why
I thought it could be a nice spot to collaborate on. Since that's been
refused at this time, we'll need to seek elsewhere and we (q4e/iam) are
open to your suggestions.

Since we both agree that two projects for the same objectives is not the
best option (I'll not discuss who created the situation, since we
clearly have different views)... what can we do to benefit the end user
and the community?

I would not propose a merge as the starting point, but I would like to
find some spots to collaborate so knowledge can be gained and a
transition can be planned over time.

Please share your thoughts on this.
--
Abel Muiño Vizcaino - http://ramblingabout.wordpress.com

Eugene Kuleshov wrote:
> 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+Devel opment+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
>
Re: Collaboration between IAM and M2E [message #10875 is a reply to message #8793] Wed, 21 May 2008 02:53 Go to previous message
Eclipse UserFriend
Originally posted by: jason.vanzyl.mac.com

On 2008-05-19 10:29:08 -0700, Abel Muiño Vizcaino <amuino@gmail.com> said:

> Hi Jason,
>
> I get from your reply that M2E is not willing to collaborate with
> IAM? I'm a bit confused because Eugene showed interest in a previous
> reply, so I would like to know what's the official position of the M2E
> project. This is the most important thing I would like to get from this
> conversation.

There is no official position about collaborating, or not, with any
particular group.

>
> There are other topics on your reply that are also interesting...
>
> Regarding reuse of the Nexus index component, IAM/Q4R is reusing
> the indexes without using any code. Since Nexus is GPL, and the
> indexer/reader is part of it (so it is also GPL) I don't think it would
> be possible to reuse it in an Eclipse project. If Sonatype releases a
> version of the component under EPL license, that would be much
> different.

When we released the sources we stated it was EPL

http://blogs.sonatype.com/brian/2008/05/01/1209658620000.htm l

Which is also in the POM:

http://svn.sonatype.org/nexus/trunk/nexus-indexer/pom.xml

>
> 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).

There's no limitation for extension whatsoever. With the stand-alone
indexer we've provided users that don't even use a repository manager
to get access within Eclipse so we've actually provided a greater field
of use.

>
> This is the first time I hear about the IP claims you mention.
> Since you don't really say anything (what claims? what person? when?
> where?) it all sounds like FUD. I'm sure that was not intention, so you
> should clearly explain this.

You can ask Brett, he made the claim.

http://markmail.org/message/nnorndjjioxltc6f

>
> Finally, about reusing the generated maven bundles, what I was
> asking is for a way to build them by anyone under an EPL (or compatible
> license), so if Sonatype decided to stop taking care of them, the rest
> of the users could still generate updated versions. I find that having
> those bundles (and the build process for generating them) in the Apache
> Maven project would make a lot of sense, specially when it will not be
> difficult for you to achieve.

The bundles are created with Tycho which is under the m2e proposal so
it will come along with the IDE integration and the Doxia editors.
Anyone can build them, even now. I'm not sure what you mean by putting
the bundles at the Apache Maven project, I assume you mean in the
central repository.

>
> I'm looking forward to hearing from you. I sincerely hope that the M2E
> project can collaborate with IAM and find common ground. Both proposals
> (soon to be projects) have the same goals and are duplicating the
> effort. The IAM team has offered help so you don't have to re-implement
> what we already have... now it is your choice to accept it and work
> together or to refuse it and go against what Eclipse means.

That we use or, don't use, a particular piece of code just because it
exists is not anti anything. In this message in particular you sound
more frustrated and angry then anything.

Using words like "FUD", citing our licenses incorrectly and telling us
if we don't use your code, or work with you we don't belong at Eclipse
is a little over the top.

When all the code is here, under the EPL, and belongs to the Eclipse
Foundation then we have a basis from which to start talking about
collaborating. We have specific goals for Maven users, and no one from
our side is ruling out anything but for certain you demanding
collaboration with an accusatory air isn't going to make it happen. I'm
sure we can find a way to work together, and that would probably start
with you taking a different tone.

>
> Yours,
> Abel Muiño
>
> Jason van Zyl wrote:
>> On 2008-05-12 12:39:28 -0700, Abel Muiño Vizcaino <amuino@gmail.com> said:
>>
>>> Eugene Kuleshov wrote:
>>>> I'd be glad to see such cooperation, though your own project pages
>>>> state that there are technical differences between q4e and m2eclipse,
>>>> so it is unclear what can be actually shared and it would be
>>>> interesting to see more technical details on that.
>>>
>>> Thanks for drawing my attention to that, it was written at the time of
>>> m2eclipse 0.0.11 or 12, where the architecture was a single plug-in.
>>> Since m2eclipse has been rewritten, the technical differences are less.
>>> I've rewritten that section specific FAQ answer.
>>>
>>> On most other fronts, both projects have, or will achieve in the near
>>> future, similar feature sets. Think of that:
>>>
>>> - m2eclipse integrated the nexus index, and little time later, q4e also
>>> can read it. We introduced one indirection layer so other search
>>> engines could also be used... we feel that's the "Eclipse way",
>>> providing am exemplary implementation but leaving the door open for
>>> others.
>>
>> We needed something that worked so we focused on Nexus Indexer, which
>> is already the defacto standard. It's integrated into all three major
>> IDEs and it's an open source component under a license that can be used
>> by everyone. Our library not only provides the framework for creating
>> the indices but provides the infrastructure for working with the
>> indices. So we provide tools to create the indices and operate on the
>> indices. This work really doesn't need to be duplicated.
>>
>>> - iam/q4e provided autocompletion for dependencies on pom.xml, and
>>> m2eclipse brings in Lukas Krecan, so I guess that soon you also will
>>> have that.
>>
>> We are pretty happy with the contribution from our community. Lukas and
>> Eugene have something very good already. Eugene made some pretty
>> awesome progress with the help of Lukas:
>>
>> http://www.jroller.com/eu/entry/maven_pom_xml_editor
>>
>>>
>>> - iam/q4e has had Forms-based pom editor under development during the
>>> past releases, and m2e has started to prototype its own too.
>>>
>>> - The extension points in q4e allowing third party (and, as an
>>> exemplary implementation, WTP support) are also being implemented (in a
>>> different flavor) in m2e...
>>>
>>> I guess the same thing will happen with other high level features, and
>>> that's just a waste of resources.
>>>
>>> What I would suggest is that, as a stating point, you take a look at
>>> the editors in q4e and detect what is preventing you from reusing them.
>>> Together we'll see if that can be solved... just ask whatever you need
>>> on q4e-dev[1]. Once a path of action is clear, we could just move
>>> common parts to a "neutral" repository with committers from both teams
>>> (I'm talking about collaboration, not plain reuse).
>>
>> We've decided to go the route of accepting code from our community and
>> making the contributor a committer on our project. Additionally since a
>> member of your team made an IP claim about some of our code we honestly
>> feel it best from an IP perspective to wait until the IP process is
>> complete unless the code is directly contributed to the project with
>> the corresponding CLAs.
>>
>>>> Another thing worth to mention is that we have osgi bundles created
>>>> for number of Maven components and those are available from m2eclipse
>>>> source control system (pretty much as from Orbit) as well as from Maven
>>>> repository we host at
>>>> http://repository.sonatype.org:8081/nexus/content/groups/mav en-eclipse/
>>>> and anyone is welcome to use those artifacts.
>>> It would be great if those bundles were provided directly by the
>>> apache/maven. It just seems the right thing to me... BTW: are the build
>>> scripts available? It would not be wise to depend an Eclipse project
>>> like IAM on them if they can't be rebuilt if needed.
>>
>> No build scripts necessary. We are using Tycho and straight Maven to
>> build headless:
>> https://ci.sonatype.org/job/m2eclipse/143/
>>
>> All good as shown in our instance of Hudson:
>> https://ci.sonatype.org/job/m2eclipse/143/console
>>
>> You can also read this document to learn how to build m2e, as well as
>> external dependencies:
>> http://docs.codehaus.org/display/M2ECLIPSE/Configuring+Devel opment+Environment
>>
>> Thanks,
>>
>> Jason
Re: Adding Lukáš Křečan as a committer on m2eclipse [message #565864 is a reply to message #8676] Sat, 10 May 2008 17:59 Go to previous message
Eugene Kuleshov is currently offline Eugene KuleshovFriend
Messages: 504
Registered: July 2009
Senior Member
Abel Muiño Vizcaino wrote:
> In IAM/q4e we already have this work started and the form based pom is
> quite evolved too. It would be a shame to start all over again for m2e.
Just to clarify, m2eclipse as well already have good progress on the
pom editor.
> What I'm proposing is creating a common ground both projects can use.
> For example, high level editors (not limited to pom, settings, etc...
> also doxia) and maven bundles (the embedder, doxia or other plug-ins).
>
> Would you be interested?
I'd be glad to see such cooperation, though your own project pages
state that there are technical differences between q4e and m2eclipse, so
it is unclear what can be actually shared and it would be interesting to
see more technical details on that.

Another thing worth to mention is that we have osgi bundles created
for number of Maven components and those are available from m2eclipse
source control system (pretty much as from Orbit) as well as from Maven
repository we host at
http://repository.sonatype.org:8081/nexus/content/groups/mav en-eclipse/
and anyone is welcome to use those artifacts.

regards,
Eugene
Collaboration between IAM and M2E [message #565884 is a reply to message #8688] Mon, 12 May 2008 19:39 Go to previous message
Abel Mui is currently offline Abel MuiFriend
Messages: 247
Registered: July 2009
Senior Member
Eugene Kuleshov wrote:
> I'd be glad to see such cooperation, though your own project pages
> state that there are technical differences between q4e and m2eclipse,
> so it is unclear what can be actually shared and it would be
> interesting to see more technical details on that.

Thanks for drawing my attention to that, it was written at the time of
m2eclipse 0.0.11 or 12, where the architecture was a single plug-in.
Since m2eclipse has been rewritten, the technical differences are less.
I've rewritten that section specific FAQ answer.

Differences that I can think of (and I speak for what I've read or been
told in the past) that still hold are:

Q4E is event-oriented, I believe that m2e uses the console and stdin/out.

A bigger one is tha m2eclipse forks and uses an external maven (for
running maven goals) while iam/q4e only uses the embedder. Our position
here is that it is the way to go, allowing deep integration and better
performance. It certainly has allowed us to quickly do things like the
dependency analysis view and some other "magic" in the maven incremental
builder.

On most other fronts, both projects have, or will achieve in the near
future, similar feature sets. Think of that:

- m2eclipse integrated the nexus index, and little time later, q4e also
can read it. We introduced one indirection layer so other search engines
could also be used... we feel that's the "Eclipse way", providing am
exemplary implementation but leaving the door open for others.

- iam/q4e provided autocompletion for dependencies on pom.xml, and
m2eclipse brings in Lukas Krecan, so I guess that soon you also will
have that.

- iam/q4e has had Forms-based pom editor under development during the
past releases, and m2e has started to prototype its own too.

- The extension points in q4e allowing third party (and, as an exemplary
implementation, WTP support) are also being implemented (in a different
flavor) in m2e...

I guess the same thing will happen with other high level features, and
that's just a waste of resources.

What I would suggest is that, as a stating point, you take a look at the
editors in q4e and detect what is preventing you from reusing them.
Together we'll see if that can be solved... just ask whatever you need
on q4e-dev[1]. Once a path of action is clear, we could just move common
parts to a "neutral" repository with committers from both teams (I'm
talking about collaboration, not plain reuse).
> Another thing worth to mention is that we have osgi bundles created
> for number of Maven components and those are available from m2eclipse
> source control system (pretty much as from Orbit) as well as from
> Maven repository we host at
> http://repository.sonatype.org:8081/nexus/content/groups/mav en-eclipse/
> and anyone is welcome to use those artifacts.
It would be great if those bundles were provided directly by the
apache/maven. It just seems the right thing to me... BTW: are the build
scripts available? It would not be wise to depend an Eclipse project
like IAM on them if they can't be rebuilt if needed.

Anyway, I think it would be a big plus for the embedder developers if
the bugs were reported against a single version.

I took a quick look at the embedder bundle and noticed the
"Eclipse-BuddyPolicy: dependent". In iam/q4e we've chosen "registered"
to allow choosing the specific plug-ins that need to be in the embedder
classpath. Why did you choose a broader option? Could this be changed in
your packaging to avoid accidentally placing elements in the classpath?

I'll be taking some steps to use your embedder bundle in IAM and see if
there's something else we would need.


Looking forward to hearing from you,
--
Abel Muiño Vizcaino - http://ramblingabout.wordpress.com
Re: Collaboration between IAM and M2E [message #566039 is a reply to message #8700] Fri, 16 May 2008 03:07 Go to previous message
Jason van Zyl is currently offline Jason van ZylFriend
Messages: 19
Registered: July 2009
Junior Member
On 2008-05-12 12:39:28 -0700, Abel Muiño Vizcaino <amuino@gmail.com> said:

> Eugene Kuleshov wrote:
>> I'd be glad to see such cooperation, though your own project pages
>> state that there are technical differences between q4e and m2eclipse,
>> so it is unclear what can be actually shared and it would be
>> interesting to see more technical details on that.
>
> Thanks for drawing my attention to that, it was written at the time of
> m2eclipse 0.0.11 or 12, where the architecture was a single plug-in.
> Since m2eclipse has been rewritten, the technical differences are less.
> I've rewritten that section specific FAQ answer.
>
> On most other fronts, both projects have, or will achieve in the near
> future, similar feature sets. Think of that:
>
> - m2eclipse integrated the nexus index, and little time later, q4e also
> can read it. We introduced one indirection layer so other search
> engines could also be used... we feel that's the "Eclipse way",
> providing am exemplary implementation but leaving the door open for
> others.

We needed something that worked so we focused on Nexus Indexer, which
is already the defacto standard. It's integrated into all three major
IDEs and it's an open source component under a license that can be used
by everyone. Our library not only provides the framework for creating
the indices but provides the infrastructure for working with the
indices. So we provide tools to create the indices and operate on the
indices. This work really doesn't need to be duplicated.

> - iam/q4e provided autocompletion for dependencies on pom.xml, and
> m2eclipse brings in Lukas Krecan, so I guess that soon you also will
> have that.

We are pretty happy with the contribution from our community. Lukas and
Eugene have something very good already. Eugene made some pretty
awesome progress with the help of Lukas:

http://www.jroller.com/eu/entry/maven_pom_xml_editor

>
> - iam/q4e has had Forms-based pom editor under development during the
> past releases, and m2e has started to prototype its own too.
>
> - The extension points in q4e allowing third party (and, as an
> exemplary implementation, WTP support) are also being implemented (in a
> different flavor) in m2e...
>
> I guess the same thing will happen with other high level features, and
> that's just a waste of resources.
>
> What I would suggest is that, as a stating point, you take a look at
> the editors in q4e and detect what is preventing you from reusing them.
> Together we'll see if that can be solved... just ask whatever you need
> on q4e-dev[1]. Once a path of action is clear, we could just move
> common parts to a "neutral" repository with committers from both teams
> (I'm talking about collaboration, not plain reuse).

We've decided to go the route of accepting code from our community and
making the contributor a committer on our project. Additionally since a
member of your team made an IP claim about some of our code we honestly
feel it best from an IP perspective to wait until the IP process is
complete unless the code is directly contributed to the project with
the corresponding CLAs.

>> Another thing worth to mention is that we have osgi bundles created
>> for number of Maven components and those are available from m2eclipse
>> source control system (pretty much as from Orbit) as well as from Maven
>> repository we host at
>> http://repository.sonatype.org:8081/nexus/content/groups/mav en-eclipse/
>> and anyone is welcome to use those artifacts.
> It would be great if those bundles were provided directly by the
> apache/maven. It just seems the right thing to me... BTW: are the build
> scripts available? It would not be wise to depend an Eclipse project
> like IAM on them if they can't be rebuilt if needed.

No build scripts necessary. We are using Tycho and straight Maven to
build headless:
https://ci.sonatype.org/job/m2eclipse/143/

All good as shown in our instance of Hudson:
https://ci.sonatype.org/job/m2eclipse/143/console

You can also read this document to learn how to build m2e, as well as
external dependencies:
http://docs.codehaus.org/display/M2ECLIPSE/Configuring+Devel opment+Environment

Thanks,

Jason
Re: Collaboration between IAM and M2E [message #566060 is a reply to message #8779] Mon, 19 May 2008 17:29 Go to previous message
Abel Mui is currently offline Abel MuiFriend
Messages: 247
Registered: July 2009
Senior Member
Hi Jason,

I get from your reply that M2E is not willing to collaborate with
IAM? I'm a bit confused because Eugene showed interest in a previous
reply, so I would like to know what's the official position of the M2E
project. This is the most important thing I would like to get from this
conversation.

There are other topics on your reply that are also interesting...

Regarding reuse of the Nexus index component, IAM/Q4R is reusing the
indexes without using any code. Since Nexus is GPL, and the
indexer/reader is part of it (so it is also GPL) I don't think it would
be possible to reuse it in an Eclipse project. If Sonatype releases a
version of the component under EPL license, that would be much different.

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).

This is the first time I hear about the IP claims you mention. Since
you don't really say anything (what claims? what person? when? where?)
it all sounds like FUD. I'm sure that was not intention, so you should
clearly explain this.

Finally, about reusing the generated maven bundles, what I was
asking is for a way to build them by anyone under an EPL (or compatible
license), so if Sonatype decided to stop taking care of them, the rest
of the users could still generate updated versions. I find that having
those bundles (and the build process for generating them) in the Apache
Maven project would make a lot of sense, specially when it will not be
difficult for you to achieve.

I'm looking forward to hearing from you. I sincerely hope that the M2E
project can collaborate with IAM and find common ground. Both proposals
(soon to be projects) have the same goals and are duplicating the
effort. The IAM team has offered help so you don't have to re-implement
what we already have... now it is your choice to accept it and work
together or to refuse it and go against what Eclipse means.

Yours,
Abel Muiño

Jason van Zyl wrote:
> On 2008-05-12 12:39:28 -0700, Abel Muiño Vizcaino <amuino@gmail.com>
> said:
>
>> Eugene Kuleshov wrote:
>>> I'd be glad to see such cooperation, though your own project pages
>>> state that there are technical differences between q4e and
>>> m2eclipse, so it is unclear what can be actually shared and it would
>>> be interesting to see more technical details on that.
>>
>> Thanks for drawing my attention to that, it was written at the time
>> of m2eclipse 0.0.11 or 12, where the architecture was a single
>> plug-in. Since m2eclipse has been rewritten, the technical
>> differences are less. I've rewritten that section specific FAQ answer.
>>
>> On most other fronts, both projects have, or will achieve in the near
>> future, similar feature sets. Think of that:
>>
>> - m2eclipse integrated the nexus index, and little time later, q4e
>> also can read it. We introduced one indirection layer so other search
>> engines could also be used... we feel that's the "Eclipse way",
>> providing am exemplary implementation but leaving the door open for
>> others.
>
> We needed something that worked so we focused on Nexus Indexer, which
> is already the defacto standard. It's integrated into all three major
> IDEs and it's an open source component under a license that can be
> used by everyone. Our library not only provides the framework for
> creating the indices but provides the infrastructure for working with
> the indices. So we provide tools to create the indices and operate on
> the indices. This work really doesn't need to be duplicated.
>
>> - iam/q4e provided autocompletion for dependencies on pom.xml, and
>> m2eclipse brings in Lukas Krecan, so I guess that soon you also will
>> have that.
>
> We are pretty happy with the contribution from our community. Lukas
> and Eugene have something very good already. Eugene made some pretty
> awesome progress with the help of Lukas:
>
> http://www.jroller.com/eu/entry/maven_pom_xml_editor
>
>>
>> - iam/q4e has had Forms-based pom editor under development during the
>> past releases, and m2e has started to prototype its own too.
>>
>> - The extension points in q4e allowing third party (and, as an
>> exemplary implementation, WTP support) are also being implemented (in
>> a different flavor) in m2e...
>>
>> I guess the same thing will happen with other high level features,
>> and that's just a waste of resources.
>>
>> What I would suggest is that, as a stating point, you take a look at
>> the editors in q4e and detect what is preventing you from reusing
>> them. Together we'll see if that can be solved... just ask whatever
>> you need on q4e-dev[1]. Once a path of action is clear, we could just
>> move common parts to a "neutral" repository with committers from both
>> teams (I'm talking about collaboration, not plain reuse).
>
> We've decided to go the route of accepting code from our community and
> making the contributor a committer on our project. Additionally since
> a member of your team made an IP claim about some of our code we
> honestly feel it best from an IP perspective to wait until the IP
> process is complete unless the code is directly contributed to the
> project with the corresponding CLAs.
>
>>> Another thing worth to mention is that we have osgi bundles
>>> created for number of Maven components and those are available from
>>> m2eclipse source control system (pretty much as from Orbit) as well
>>> as from Maven repository we host at
>>> http://repository.sonatype.org:8081/nexus/content/groups/mav en-eclipse/
>>> and anyone is welcome to use those artifacts.
>> It would be great if those bundles were provided directly by the
>> apache/maven. It just seems the right thing to me... BTW: are the
>> build scripts available? It would not be wise to depend an Eclipse
>> project like IAM on them if they can't be rebuilt if needed.
>
> No build scripts necessary. We are using Tycho and straight Maven to
> build headless:
> https://ci.sonatype.org/job/m2eclipse/143/
>
> All good as shown in our instance of Hudson:
> https://ci.sonatype.org/job/m2eclipse/143/console
>
> You can also read this document to learn how to build m2e, as well as
> external dependencies:
> http://docs.codehaus.org/display/M2ECLIPSE/Configuring+Devel opment+Environment
>
>
> Thanks,
>
> Jason
>
Re: Collaboration between IAM and M2E [message #566085 is a reply to message #8793] Tue, 20 May 2008 02:25 Go to previous message
Eugene Kuleshov is currently offline Eugene KuleshovFriend
Messages: 504
Registered: July 2009
Senior Member
Abel Muiño Vizcaino wrote:
> Regarding reuse of the Nexus index component, IAM/Q4R is reusing
> the indexes without using any code. Since Nexus is GPL, and the
> indexer/reader is part of it (so it is also GPL) I don't think it
> would be possible to reuse it in an Eclipse project. If Sonatype
> releases a version of the component under EPL license, that would be
> much different.
Abel, before making such claims you should have checked Nexus Indexer
license. In fact it is EPL, which makes it perfect library to be used in
any Eclipse project. I would also say that using Nexus Indexer formats
outside it is generally a bad idea and would lead to incompatibilities.
> 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. 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.
> Finally, about reusing the generated maven bundles, what I was
> asking is for a way to build them by anyone under an EPL (or
> compatible license), so if Sonatype decided to stop taking care of
> them, the rest of the users could still generate updated versions. I
> find that having those bundles (and the build process for generating
> them) in the Apache Maven project would make a lot of sense, specially
> when it will not be difficult for you to achieve.
I respectfully disagree with this. Like I already mentioned it is
actually no different then Eclipse Orbit project. Besides, we do have
all build tools published and anyone can reproduce the same build if
needed. More over, at the moment Apache don't really have reliable
infrastructure and we believe that bundles available from Sonatype
currently more trusted, because they are created with direct
participation of several Maven committers.
> I'm looking forward to hearing from you. I sincerely hope that the M2E
> project can collaborate with IAM and find common ground.
You haven't actually answered my question on what exactly is your idea
of collaboration with m2e project, but instead choose to make several
negative claims about Sonatype.

regards,
Eugene
Re: Collaboration between IAM and M2E [message #566105 is a reply to message #8804] Tue, 20 May 2008 13:31 Go to previous message
Abel Mui is currently offline Abel MuiFriend
Messages: 247
Registered: July 2009
Senior Member
Eugene Kuleshov wrote:

> Abel Muiño Vizcaino wrote:
>> Regarding reuse of the Nexus index component, IAM/Q4R is reusing
>> the indexes without using any code. Since Nexus is GPL, and the
>> indexer/reader is part of it (so it is also GPL) I don't think it
>> would be possible to reuse it in an Eclipse project. If Sonatype
>> releases a version of the component under EPL license, that would be
>> much different.
> Abel, before making such claims you should have checked Nexus Indexer
> license. In fact it is EPL, which makes it perfect library to be used in
> any Eclipse project.

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

The closest match is the Nexus CLI
(http://docs.codehaus.org/display/M2ECLIPSE/Nexus+Indexer), which is
downloadable from the Nexus download site... and Nexus is GPL. If the code
is EPL, it could not be packaged with Nexus unless it has double
licensing. I haven't found any reference to that, so (being no lawyer)
this situation is confusing, at best.

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

>> 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.

> 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.

>> Finally, about reusing the generated maven bundles, what I was
>> asking is for a way to build them by anyone under an EPL (or
>> compatible license), so if Sonatype decided to stop taking care of
>> them, the rest of the users could still generate updated versions. I
>> find that having those bundles (and the build process for generating
>> them) in the Apache Maven project would make a lot of sense, specially
>> when it will not be difficult for you to achieve.
> 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.

> 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.

>> I'm looking forward to hearing from you. I sincerely hope that the M2E
>> project can collaborate with IAM and find common ground.
> You haven't actually answered my question on what exactly is your idea
> of collaboration with m2e project

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:
- xml pom editor: autocompletion based on the indexer info (here's where
having a single Open Search Framework can help).
- form-based pom editor: it can leverage maven metadata.

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").

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.

That was our (IAM's) proposal (if you are willing to propose another path,
please do so). Jason's response looked like a negative answer... that's
why I asked for a clear confirmation.

> 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.

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.

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).

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).

Thanks for your time!
--
Abel Muiño
Re: Collaboration between IAM and M2E [message #566122 is a reply to message #8813] Tue, 20 May 2008 15:55 Go to previous message
Andrew Niefer is currently offline Andrew NieferFriend
Messages: 990
Registered: July 2009
Senior Member
Hi Guys,
As a committer on PDE/Build, Equinox, and P2, I'm standing somewhere
close to the center of where integration between the core Eclipse and
m2e/iam may occur.

From a purely selfish standpoint, learning two projects is a lot more
work than learning one :) At this point, I couldn't tell you what the
difference between the two projects is.

Any point of integration with p2/pde/equinox would be an excellent place
for collaboration between iam and m2e.

-Andrew



Abel Muiño wrote:
> Eugene Kuleshov wrote:
>
>> Abel Muiño Vizcaino wrote:
>>> I'm looking forward to hearing from you. I sincerely hope that the
>>> M2E project can collaborate with IAM and find common ground.
>> You haven't actually answered my question on what exactly is your
>> idea of collaboration with m2e 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).
>
> Thanks for your time!
> --
> Abel Muiño
>
Re: Collaboration between IAM and M2E [message #566143 is a reply to message #8813] Tue, 20 May 2008 16:03 Go to previous message
Eugene Kuleshov is currently offline Eugene KuleshovFriend
Messages: 504
Registered: July 2009
Senior Member
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+Devel opment+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
Re: Collaboration between IAM and M2E [message #566165 is a reply to message #10848] Tue, 20 May 2008 19:02 Go to previous message
Abel Mui is currently offline Abel MuiFriend
Messages: 247
Registered: July 2009
Senior Member
I think that we could just "agree to disagree" regarding the focus on
Sonatype products.

Regarding collaborating on the editors, when I wrote "we have" I was
meaning IAM and M2E as you correctly pointed out. That is, precisely why
I thought it could be a nice spot to collaborate on. Since that's been
refused at this time, we'll need to seek elsewhere and we (q4e/iam) are
open to your suggestions.

Since we both agree that two projects for the same objectives is not the
best option (I'll not discuss who created the situation, since we
clearly have different views)... what can we do to benefit the end user
and the community?

I would not propose a merge as the starting point, but I would like to
find some spots to collaborate so knowledge can be gained and a
transition can be planned over time.

Please share your thoughts on this.
--
Abel Muiño Vizcaino - http://ramblingabout.wordpress.com

Eugene Kuleshov wrote:
> 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+Devel opment+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
>
Re: Collaboration between IAM and M2E [message #566212 is a reply to message #8793] Wed, 21 May 2008 02:53 Go to previous message
Eclipse UserFriend
Originally posted by: jason.vanzyl.mac.com

On 2008-05-19 10:29:08 -0700, Abel Muiño Vizcaino <amuino@gmail.com> said:

> Hi Jason,
>
> I get from your reply that M2E is not willing to collaborate with
> IAM? I'm a bit confused because Eugene showed interest in a previous
> reply, so I would like to know what's the official position of the M2E
> project. This is the most important thing I would like to get from this
> conversation.

There is no official position about collaborating, or not, with any
particular group.

>
> There are other topics on your reply that are also interesting...
>
> Regarding reuse of the Nexus index component, IAM/Q4R is reusing
> the indexes without using any code. Since Nexus is GPL, and the
> indexer/reader is part of it (so it is also GPL) I don't think it would
> be possible to reuse it in an Eclipse project. If Sonatype releases a
> version of the component under EPL license, that would be much
> different.

When we released the sources we stated it was EPL

http://blogs.sonatype.com/brian/2008/05/01/1209658620000.htm l

Which is also in the POM:

http://svn.sonatype.org/nexus/trunk/nexus-indexer/pom.xml

>
> 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).

There's no limitation for extension whatsoever. With the stand-alone
indexer we've provided users that don't even use a repository manager
to get access within Eclipse so we've actually provided a greater field
of use.

>
> This is the first time I hear about the IP claims you mention.
> Since you don't really say anything (what claims? what person? when?
> where?) it all sounds like FUD. I'm sure that was not intention, so you
> should clearly explain this.

You can ask Brett, he made the claim.

http://markmail.org/message/nnorndjjioxltc6f

>
> Finally, about reusing the generated maven bundles, what I was
> asking is for a way to build them by anyone under an EPL (or compatible
> license), so if Sonatype decided to stop taking care of them, the rest
> of the users could still generate updated versions. I find that having
> those bundles (and the build process for generating them) in the Apache
> Maven project would make a lot of sense, specially when it will not be
> difficult for you to achieve.

The bundles are created with Tycho which is under the m2e proposal so
it will come along with the IDE integration and the Doxia editors.
Anyone can build them, even now. I'm not sure what you mean by putting
the bundles at the Apache Maven project, I assume you mean in the
central repository.

>
> I'm looking forward to hearing from you. I sincerely hope that the M2E
> project can collaborate with IAM and find common ground. Both proposals
> (soon to be projects) have the same goals and are duplicating the
> effort. The IAM team has offered help so you don't have to re-implement
> what we already have... now it is your choice to accept it and work
> together or to refuse it and go against what Eclipse means.

That we use or, don't use, a particular piece of code just because it
exists is not anti anything. In this message in particular you sound
more frustrated and angry then anything.

Using words like "FUD", citing our licenses incorrectly and telling us
if we don't use your code, or work with you we don't belong at Eclipse
is a little over the top.

When all the code is here, under the EPL, and belongs to the Eclipse
Foundation then we have a basis from which to start talking about
collaborating. We have specific goals for Maven users, and no one from
our side is ruling out anything but for certain you demanding
collaboration with an accusatory air isn't going to make it happen. I'm
sure we can find a way to work together, and that would probably start
with you taking a different tone.

>
> Yours,
> Abel Muiño
>
> Jason van Zyl wrote:
>> On 2008-05-12 12:39:28 -0700, Abel Muiño Vizcaino <amuino@gmail.com> said:
>>
>>> Eugene Kuleshov wrote:
>>>> I'd be glad to see such cooperation, though your own project pages
>>>> state that there are technical differences between q4e and m2eclipse,
>>>> so it is unclear what can be actually shared and it would be
>>>> interesting to see more technical details on that.
>>>
>>> Thanks for drawing my attention to that, it was written at the time of
>>> m2eclipse 0.0.11 or 12, where the architecture was a single plug-in.
>>> Since m2eclipse has been rewritten, the technical differences are less.
>>> I've rewritten that section specific FAQ answer.
>>>
>>> On most other fronts, both projects have, or will achieve in the near
>>> future, similar feature sets. Think of that:
>>>
>>> - m2eclipse integrated the nexus index, and little time later, q4e also
>>> can read it. We introduced one indirection layer so other search
>>> engines could also be used... we feel that's the "Eclipse way",
>>> providing am exemplary implementation but leaving the door open for
>>> others.
>>
>> We needed something that worked so we focused on Nexus Indexer, which
>> is already the defacto standard. It's integrated into all three major
>> IDEs and it's an open source component under a license that can be used
>> by everyone. Our library not only provides the framework for creating
>> the indices but provides the infrastructure for working with the
>> indices. So we provide tools to create the indices and operate on the
>> indices. This work really doesn't need to be duplicated.
>>
>>> - iam/q4e provided autocompletion for dependencies on pom.xml, and
>>> m2eclipse brings in Lukas Krecan, so I guess that soon you also will
>>> have that.
>>
>> We are pretty happy with the contribution from our community. Lukas and
>> Eugene have something very good already. Eugene made some pretty
>> awesome progress with the help of Lukas:
>>
>> http://www.jroller.com/eu/entry/maven_pom_xml_editor
>>
>>>
>>> - iam/q4e has had Forms-based pom editor under development during the
>>> past releases, and m2e has started to prototype its own too.
>>>
>>> - The extension points in q4e allowing third party (and, as an
>>> exemplary implementation, WTP support) are also being implemented (in a
>>> different flavor) in m2e...
>>>
>>> I guess the same thing will happen with other high level features, and
>>> that's just a waste of resources.
>>>
>>> What I would suggest is that, as a stating point, you take a look at
>>> the editors in q4e and detect what is preventing you from reusing them.
>>> Together we'll see if that can be solved... just ask whatever you need
>>> on q4e-dev[1]. Once a path of action is clear, we could just move
>>> common parts to a "neutral" repository with committers from both teams
>>> (I'm talking about collaboration, not plain reuse).
>>
>> We've decided to go the route of accepting code from our community and
>> making the contributor a committer on our project. Additionally since a
>> member of your team made an IP claim about some of our code we honestly
>> feel it best from an IP perspective to wait until the IP process is
>> complete unless the code is directly contributed to the project with
>> the corresponding CLAs.
>>
>>>> Another thing worth to mention is that we have osgi bundles created
>>>> for number of Maven components and those are available from m2eclipse
>>>> source control system (pretty much as from Orbit) as well as from Maven
>>>> repository we host at
>>>> http://repository.sonatype.org:8081/nexus/content/groups/mav en-eclipse/
>>>> and anyone is welcome to use those artifacts.
>>> It would be great if those bundles were provided directly by the
>>> apache/maven. It just seems the right thing to me... BTW: are the build
>>> scripts available? It would not be wise to depend an Eclipse project
>>> like IAM on them if they can't be rebuilt if needed.
>>
>> No build scripts necessary. We are using Tycho and straight Maven to
>> build headless:
>> https://ci.sonatype.org/job/m2eclipse/143/
>>
>> All good as shown in our instance of Hudson:
>> https://ci.sonatype.org/job/m2eclipse/143/console
>>
>> You can also read this document to learn how to build m2e, as well as
>> external dependencies:
>> http://docs.codehaus.org/display/M2ECLIPSE/Configuring+Devel opment+Environment
>>
>> Thanks,
>>
>> Jason
Previous Topic:IAM has entered the Creation Review state
Next Topic:New snapshot for version 0.7.0 available
Goto Forum:
  


Current Time: Thu Mar 28 11:33:22 GMT 2024

Powered by FUDForum. Page generated in 0.06200 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top