Hi Celine. I have some questions and comments inline below.
Hello Everyone,
We are working on a new hierachy of the pom structure for PapyrusRT
project in order to be aligned with the common usage of maven.
During this reflexion, there are several points raised that need
your experience on the topic.
1)
Maven Hierarchy refactor:
The releng folder contains too many folders.
That is why we plan to not have a sub-pom in the releng/xyz for the
main sub part of Papyrus RT but to add it into the plugins/umlrt/xyz
folder . Does it make sense to you ?
I'm not sure I follow. What do you mean by the sub-pom? Do you mean the any of the releng/xyz/pom.xml? Is the idea to move for example releng/core/pom.xml to plugins/umlrt/core/pom.xml?
If that's what you mean, sure, I'm good with that.
Another question remains, what should we do with the releng/xyz/site
folder? Which is a sub p2 for the specific features.
Do you see any usefull reasons to keep it ? I checked in SysML
1.4 project, it only has one main p2.
Up to this point we've had separate p2 repos for codegen+rts and for core/profile/tooling. If we are going to finally have a unified p2 repo, then it would seem OK to remove the specific releng/xyz/site folders.
But if we unify the p2 repos, this may have an impact on the Hudson jobs, since we also have separate jobs for codegen/rts and for core/profile/tooling.
I like the idea of a unified job, while also leaving the possibility of building separately. If we have a unified job, I would like if we had stable nightly or weekly builds that publish the repo to some reasonably looking URL (I think the one used by core/profile/tooling is too long:
https://hudson.eclipse.org/papyrus-rt/job/Papyrus-RT-Master-All/lastSuccessfulBuild/artifact/repository/).
Anyway, I think if we get the unified build, then sure, we can throw away those releng/xyz/site folders. I think Camille was working on this unification with change 70225,
2)
Using Target Platform
As the experience seems to give good results, we will use the
Target Platform to manage dependencies. We would like to have
several TP's depending on the needs:
* Eclipse (latest release (Neon) or previous release (Mars))
* Papyrus (nightly or latest release
(Neon M7))
* Papyrus RT (nightly or latest release
)
The combination of those 3 levels of
dependencies will be used in the Hudson jobs, in order to check
compatibility, quality and regression between TP's.
Using the TP is working properly if the build is launched from the
root (the TP is defined in the main pom.xml ).
Is this work with TP related to change
65272?
The open point is how can we manage the build of a sub project
like "codegen" that is currently done in the Job ?
a. Do we really need to be able to build any sub-project ?
Shouldn't we? If we don't build some sub-project, other parts may not build or work, no? I can see for example that you don't need to build the runtime or codegen to get tooling working. Is this what you mean?
b. Maybe we can manage the sub module through different profiles
into the main pom.xml ?
That sounds fine with me.
c. We should define the TP into each level of the hierarchy
I don't really have an opinion on this. Would this mean that there would be different TPs for say individual plugins? for all of codegen? for everything?
You are welcome to give your opinion on those 2 topics.
Best regards
Céline
--
| |
Céline
JANSSENS
Software
Engineer
+33 (0)2 44 47 23 23
|
| |
Mail : cej@xxxxxxxxxxx
|
6 rue Léonard De Vinci - BP 0119 - 53001 LAVAL
Cedex - FRANCE
www.all4tec.net
|
|
_______________________________________________
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
