| Re: [mdt-papyrus.dev] discusion relative to maven integration in papyrus |
|
Ø
(as an aside, do we have a good story for the EMF codegen situations that require editing generated code?) All metamodels based on the GMF Notation metamodel, which doesn’t come with a GenModel. Especially the generated code for the Model Import tool and Viewpoints
can’t be compiled immediately. They need manual fixes. The Notation metamodel has been generated a long time ago, and I suspect something not standard has been used (Or maybe I just don’t know which GenModel options
should be enabled :) ) Ø
[cwd] That’s a good point. I’ve even forgotten now what the motivation was for migrating the builds to Tycho in the first place. And I think I was one of those that were advocating for it! Much (much, much, much, much, much, much, much) easier to maintain and reproduce than our previous Ant/Buckminster build. Camille De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Christian W. Damus Hi, François, Thanks for your comments. I have some replies to follow up, in-line below. Cheers, Christian On Thursday, Feb 19, 2015 at 07:07, LE FEVRE FRANCOIS <francois.le-fevre@xxxxxx>, wrote: Hi, Christian, Your report « Maven Nature in Papyrus source projects” is really good. I had really appreciated it covers all aspects from installation , to configuration, to scalability… About the installation process. Perhaps it could be good to know what is the exact version of maven on the hudson server, so we could assert that we have exactly the same environment. You can link a specific maven instance that is not embedded within the eclipse/oomph in the installations setup/eclipse preference. [cwd] Indeed. However, I think the linked maven instance is only used for “Maven Builds” as run by maven launch configurations. I see no evidence that they are used for the regular workspace builds (I tried it) and, in fact, the preference
page itself makes it clear that the embedded maven is always used for dependency resolution.
[cwd] Yes, performance definitely seems to be in the same ball-park, and I’m satisfied with that. This was by no means a statistically rigorous experiment: I tried to control the conditions as well as I could, but I didn’t take repeated
measurements and compute means and sigmas as I would for a more formal performance test. I’m happy to do that, of course, but it takes time.
[cwd] I think that should be fine. None of this experiment changed the POM files or module structure in any way. It only changed the metadata used by the Eclipse workbench. I’m curious about this notion of attracting developers from Maven, which has been mentioned before. What do you mean by that? We’re trying to attract people interested in model-driven development with UML; Maven has nothing to do with
that. If the tools help to ease adoption, that’s great, but I expect that much of the modelling community is already familiar with Eclipse because so many of the best modelling tools are built on Eclipse already (at least the ones that Papyrus is built on).
I don’t see why Maven would attract anyone in particular …
[cwd] I’d like to play a bit of the devil’s advocate in response, not be snarky or obstinate or anything, but just to make sure that I (and anybody else reading) understand both of our perspectives. I don’t necessarily disagree on any
point! And I fully embrace my dinosaur nature when it shows itself. :-) In any case, it seems that we have a developer approaching Eclipse from a strong Maven background and one that is approaching Maven from a strong Eclipse background, which is great
because that ensures we get a complete picture and a productive discussion.
[cwd] Eclipse has rather proven itself in producing industrial-strength software (witness EMF, Equinox, Eclipse Platform). Does maven automatically improve on that? Quality is more about what we put into the source, not what the build
does with it.
[cwd] One thing that my experiment seems to demonstrate is that, in fact, the Maven nature does not do much to unify these environments, except perhaps in the dependency resolution. But, through Tycho, this all traces back to the PDE
and JDT metadata anyways, so what’s the difference? Certainly the actual mechanics of the build are still vastly different.
[cwd] Yes, we have seen how some more issues like this cropped up. I could say that there would be other ways to validate these configuration details, but that might be trying too hard. ;-)
[cwd] Right, but there are other ways that this can be accomplished, too. We didn’t need maven to get rid of Xtend-generated code because the Xtext builder already does that. And we would have put the energy spent on an EMF generator
maven plug-in into an Eclipse plug-in that implements this as a project builder, if we still used Buckminster for the builds, but we’re using maven so we had to do it as a maven plug-in.
[cwd] What does you mean by this? Git triggers to me are a specific thing, hooks in the git system whereby actions like commit or push can be intercepted for validation, notification, and other behaviours.
[cwd] That doesn’t need maven. And a best practice is a best practice regardless. (as an aside, do we have a good story for the EMF codegen situations that require editing generated code?)
[cwd] I don’t know … the Maven Nature conversion modified a thousand files in my git workspace automatically … It added more configuration than it removed. What configuration specifically are you referring to?
[cwd] Do you mean APIs for manipulation of Papyrus artifacts, transformations, and the like that don’t require the whole Eclipse run-time? That is important to me, and if maven can help that, great. But again, the Eclipse IDE also provides
for a variety of execution environments at build- and run-time. It just hasn’t been a priority for Papyrus yet.
[cwd] This does sound interesting. But, of course, Eclipse provides mechanisms for project templates, too. I don’t know enough about maven to understand in what ways its archetypes are better.
[cwd] Yes, the maven community provides a wealth of plug-ins for just about everything one can think of (except, apparently, generating EMF code?)
[cwd] Yeah, by the time I had finished writing that document, I was half convinced that I myself had proposed to convert the entire set of Papyrus projects to maven. ;-) Perhaps that the word “proposed” was not the right choice; “suggested”
or even “hinted” may have been better. It seems to have been the eventual conclusion, at any rate.
[cwd] Absolutely! And I do appreciate it. I’m engaged in this discussion because I want to understand what maven can do for us if we change our development practices to embrace it fully. I don’t know that I personally need any more convincing,
having seen that at the very least our development environment won’t take any kind of backward step and that we would have a better handle on our build dependencies. I just want it done right for the right reasons.
[cwd] That’s a good point. I’ve even forgotten now what the motivation was for migrating the builds to Tycho in the first place. And I think I was one of those that were advocating for it!
|