Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] New problem with Oomph developer setup

Something new: tired of the multiple problems I've been having, I went for the nuclear option and deleted every trace of Eclipse I could find in my system, including .eclipse, .p2, .m2, any keys under .ssh and the Keychain Access (OS X's password manager) as well as other entries created on OS X, such as those under ~/Library/Caches, /Library/Caches, /System/Library/Caches, ~/Library/Preferences and ~/Library/Application Support, and the Eclipse Installer. Then I downloaded a fresh version of the Installer (64 bit-MacOSX) and ran the setup. 

But even after all this, I got this:

 Screenshot 2016-05-12 17.36.40.png

and this:

Screenshot 2016-05-12 17.36.59.png

even though during setup I entered the correct user ID and password, and authenticated it!

At least this time it didn't complain when I checked "Save Password".

The rest succeeds, but it bothers me that I get that password error that should not happen. 


On Thu, May 12, 2016 at 12:32 PM Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:
OK, since this works, I think we can abandon change 72334. Any objections?

Asma, I'm not sure why you ended up with a different lifecycle-metadata but with the new .setup you don't have to manually set it. The one included in the setup only ignores the maven-antrun plugin, and it works already for Christian, Peter and myself. The setup is already merged, so could you try it perhaps on a fresh install/workspace) and see if it works for you?

Peter, if you follow the setup's defaults, it will use the same local git repo location, so if you already had generated EMF code, it will be there and there wouldn't be any errors. If you deleted the contents of the working directory (and not the .git), before running the setup, and did not get errors on the EMF models, then I'm a bit mystified myself. In any case, my understanding is that the setup should work even if the git repo is already there, including the working directory, although there may be problems if the currently checked out branch does not match the checkout branch in the setup. 

I'm still trying to get the 70911 change to work, for for some strange reason, it works for 3 of the EMF models but it completely ignores the xtumrlt.common component in spite of the fact that the relevant launch configuration, setup task and MWE2 workflow is almost identical to the ones that do work, the only difference being the names used. I don't want to merge the change until I'm sure it works.




On Thu, May 12, 2016 at 5:25 AM Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:
Hi,

I have not followed along all these discussions, but I did try the latest update of the setup file and started from "scratch" setting up a development environment. And it do seem to work now. No lifecycle errors as before.

One think though that puzzled me for a while though was that the manual steps of generating code was not needed. I realized that one more thing had to be "nuked", i.e. the Git repo. To avoid having to re-clone, I simply removed the contents of the Working Tree (apart from the .git directory of course) and made a hard reset to get back to defined state. Then I needed to follow the manual steps according to the instructions on the Wiki.

Maybe this could be something to keep in mind for those that still have issues, i.e. make sure to "nuke" the Git repo also, in case you have something still in there that causes those issues.

/Peter Cigéhn

On 12 May 2016 at 11:17, SMAOUI Asma <Asma.SMAOUI@xxxxxx> wrote:

Hello,

 

See comments bellow.

 

Asma

 

De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de Christian Damus
Envoyé : mercredi 11 mai 2016 21:18
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] New problem with Oomph developer setup

 

On 11 May, 2016 at 15:06:31, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:

The nuclear option?  It seemed to work for Asma.  But, it removes a lot of goodness, such as Oomph’s download cache directory and the bundle pool.  In fact, deleting that bundle pool yanks out all of the plug-ins from your Oomph-managed Eclipse installations, so you’ll have to delete all of those, too, because they won’t work any more.

I can’t really see your secure storage and maven problems being caused by interference from other installations; Oomph and p2 keep this stuff pretty well isolated.  But, I don’t actually know what’s happening in your environment, so I can’t advise one way or the other.  Sorry.

 

Yes. It was working for me, I even downloaded a new Eclipse Installer and started all from scratch ;). But I think there is no use to do so. It is a brutal procedure J

 

I think we could just suppress the antrun in this lifecycle mappings preference file for now and remove the same from the POMs.  That just leaves the three lifecycle errors in the feature POMs that I mentioned earlier, which we can then review.

The nice thing about this is that by default, m2e doesn’t create this file in the preferences, so we can actually create it in the setup model and then the next time developers run the setup, they will get this file.  That is, assuming they didn’t already create it for themselves.  That’s the tricky bit:  we get one chance at creating this file; Oomph will not replace it if we make changes (users would have to delete it and then let Oomph re-create it).

BTW, the m2e connectors that we know we need are currently installed in my Eclipse from here:

org.sonatype.tycho.repository - http://repo1.maven.org/maven2/.m2e/connectors/m2eclipse-tycho/0.8.0/N/LATEST/

So, we can just go with these for now in the setup model?

 

Done. I just pushed 72559 and added you as a reviewer. I put the features and these two repos under the "Core Development Tools" P2 director. Is that the appropriate place?

I followed the link suggested by Christian and I ended up with a lifecycle-mapping-metadata.xml that contains <pluginExecution> balises, with different filters and goals <pluginExecutionFilter> <goals><goal>validate-version</goal>…with ignore actions. <action><ignore /> </action></pluginExecution>.

I did not modify the setup file, that’s why my lifecycle-mapping-metadata.xml contains filter execution for all different goals validate-version, build-qualifier, validate-id, complie, run…and not just the antrum run goal as I can notice in the lifecycle-mapping-metadata.xml created when testing the latest setup file version.

However, it could be also interesting to mege Ernesto patch that generates code automatically for xtuml different models to endup with 0 errors ;)

Asma


_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev


_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

Back to the top