Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2e-users] Compatibility between indigo m2e and juno m2e

Hi,

> What I was hoping is that there were some 
> way to not have the markers while my team and I worked on the same svn 
> projects (.project, .classpath and.settings included), my team working 
> with Indigo, me working with Juno (only while I validate Juno).

This is one reason why some people (me included) are in favor to NOT share IDE specific files in SVN (use svn:ignore). You made the (good) choice to use Maven and the pom.xml as the project descriptor. Let every IDE generate what is needed locally for each developper. It will make your Eclipse migrations much easier.

In your situation you should keep Indigo metadata in SVN for your team and update your metadata locally for Juno (using m2e update project) but do not commit the changes in SVN until your team is ready to switch to Juno.

This problem is not limited to m2e. I remember lot of problems when Eclipse metadata were shared in SVN and people are using different Eclipse versions.


My 2 cents.

Julien


>________________________________
> De : Jean Couillaud <carm@xxxxxxxxxxxx>
>À : Maven Integration for Eclipse users mailing list <m2e-users@xxxxxxxxxxx> 
>Envoyé le : Vendredi 13 juillet 2012 11h25
>Objet : Re: [m2e-users] Compatibility between indigo m2e and juno m2e
> 
>
>I must have been blurry :
>What I was hoping is that there were some 
way to not have the markers while my team and I worked on the same svn 
projects (.project, .classpath and.settings included), my team working 
with Indigo, me working with Juno (only while I validate Juno).
>I hope this is clearer.
>I have seen that the quick fix for the errors
modifies .settings and .classpath files/dires and that the changes made
by Juno are not compatible with Indigo's m2e.
>
>Regards,
>Jean
>
>
>On Fri, Jul 13, 2012 at 5:59 AM, Igor Fedorenko <igor@xxxxxxxxxxxxxx> wrote:
>
>There are no known compatibility issues between m2e 1.0 and 1.1.
>>
>>When a workspace that was originally created with one m2e version is
>>opened with another, m2e needs to "update" some internal structures, so
>>it creates the error markers. Once updated, however, everything is
>>expected to work as long as m2e version does not change. Everything is
>>expected to work if the workspace is initially created with m2e 1.1.
>>
>>--
>>Regards,
>>Igor
>>
>>
>>On 12-07-13 1:29 AM, Jean Couillaud wrote:
>>
>>No no, I'm not expecting them to do that. I was just looking for a way
>>>to continue working on the project with the team (and among other
>>>
things, updating and committing to the trunk) while*I* validate Juno.
>>>
>>>I have to ensure that using Juno won't prevent us from doing anything we
>>>are currently doing with indigo (For instance, we have to use svn1.6 for
>>>now and if subclipse dropped support for 1.6, it would have prevented us
>>>from migrating to juno).
>>>You have to understand we are working with people who need pretty
>>>serious garanties before doing any change to anything. Real lives are at
>>>stake.
>>>
>>>I've seen that using an existing indigo workspace with juno keeps the
>>>toolbar laf as the indigo one. It does not seem to me it is a documented
>>>feature.
>>>I was merely wondering if there were some "hidden compatibility
>>>features" like that in m2e, or something I would have overlooked like a
>>>"soft compatibility" setting in m2e prefs.
>>>Judging by your answers, there's no such thing, unless I misunderstood
>>>you and I'll have to go with branches, separate workspaces, etc. A pain
>>>I wish I could have avoided.
>>>
>>>Regards,
>>>Jean
>>>
>>>On Thu, Jul 12, 2012 at 9:19 PM, Igor Fedorenko <igor@xxxxxxxxxxxxxx
>>>
>>><mailto:igor@xxxxxxxxxxxxxx>> wrote:
>>>
>>>    Do you expect your team members constantly go back and forth between m2e
>>>    versions for the same workspace? The error marker is not expected to
>>>    appear if the same workspace is used with the same m2e version, which I
>>>    believe how most m2e users operate.
>>>
>>>    --
>>>    Regards,
>>>    Igor
>>>
>>>
>>>    On 12-07-12 12:26 PM, Jean Couillaud wrote:
>>>
>>>        Hi,
>>>
>>>        First, I'm sorry if this has already been discussed:
>>>        I am trying to migrate from indigo to Juno. To do that, I have to
>>>        validate Juno against our different projects. Among others, we
>>>        have a
>>>        200 projects, 2M Locs application in dev that I would like to
>>>        work on
>>>        with juno although the rest of the team still uses indigo.
>>>        When I tried to open some of the projects with Juno, m2e
>>>        complained and
>>>        ordered me to update the project conf. I did it and went back to
>>>        indigo
>>>        only to see that indigo complained the same and probably
>>>        reverted juno's
>>>        changes.
>>>        Is there a way to have part of the team use Juno and the other
>>>        Indigo
>>>        without m2e complaining ?
>>>
>>>        Thx in advance;
>>>
>>>
>>>
>>>
        _________________________________________________
>>>        m2e-users mailing list
>>>        m2e-users@xxxxxxxxxxx <mailto:m2e-users@xxxxxxxxxxx>
>>>        https://dev.eclipse.org/__mailman/listinfo/m2e-users
>>>        <https://dev.eclipse.org/mailman/listinfo/m2e-users>
>>>
>>>
>>>    _________________________________________________
>>>    m2e-users mailing list
>>>    m2e-users@xxxxxxxxxxx <mailto:m2e-users@xxxxxxxxxxx>
>>>    https://dev.eclipse.org/__mailman/listinfo/m2e-users
>>>
>>>    <https://dev.eclipse.org/mailman/listinfo/m2e-users>
>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>m2e-users mailing list
>>>m2e-users@xxxxxxxxxxx
>>>https://dev.eclipse.org/mailman/listinfo/m2e-users
>>>
>>>
>>
>>_______________________________________________
>>m2e-users mailing list
>>m2e-users@xxxxxxxxxxx
>>https://dev.eclipse.org/mailman/listinfo/m2e-users
>>
>
>_______________________________________________
>m2e-users mailing list
>m2e-users@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/m2e-users
>
>
>


Back to the top