[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [papyrus-rt-dev] New problem with Oomph developer setup
|
Change
72694 looks good, although after the clean setup I didn't get any "target/classes" folder, so is it really necessary?
As for change
72698, I'm confused. We certainly are missing the maven nature in the xtumlrt projects, but didn't we want to avoid putting this in the poms? I thought that was the point of adding the lifecycle-mappings to the workspace metadata during the setup, no?
Furthermore, in the case of the o.e.prt.rts plugin, the action in the mapping is to execute the antrun plugin, but unless you are on Linux that should fail.
Hi, François,
Thanks, I think this looks great. Especially the alignment of the output folder convention.
On 13 May, 2016 at 05:56:56, LE FEVRE FRANCOIS (francois.le-fevre@xxxxxx) wrote:
Hello
I have look a little to your/our problems, I have
created two bugs with a propositional patch [1].
Idea is to add the lifecycle configuration mapping
directly inside the pom.
Secondly I have noticed that your output directly
differ between the maven and eclipse configuration, these could
lead to funny problems inside Eclipse with the maven nature
activated with Tycho connector.
I would propose to specify the output directly
inside the pom also.
Francois
[1]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=493608
https://bugs.eclipse.org/bugs/show_bug.cgi?id=493612
De :
papyrus-rt-dev-bounces@xxxxxxxxxxx
[mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de
Ernesto Posse
Envoyé : jeudi 12 mai 2016 23:55
À : papyrus-rt developer discussions
<papyrus-rt-dev@xxxxxxxxxxx>
Objet : 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:
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.
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.
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.
On 12 May 2016 at 11:17, SMAOUI Asma
<Asma.SMAOUI@xxxxxx> wrote:
Hello,
See
comments bellow.
Asma
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
_______________________________________________
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
Attachment:
image001.png@01D1AD0E.8765D400
Description: Binary data
Attachment:
image002.png@01D1AD0E.8765D400
Description: Binary data
Attachment:
image001.png@01D1AD0E.8765D400
Description: Binary data