[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [incquery-dev] Repository freeze: project merge
- From: ZoltÃn Ujhelyi <zoltan.ujhelyi@xxxxxxxxxxxxxxxx>
- Date: Tue, 9 Feb 2016 21:24:01 +0000
- Accept-language: en-US
- Delivered-to: email@example.com
- Thread-index: AQHRYllNS86/SNe92Ea125oo+b24mJ8j8G6AgAA6qoCAABCXAA==
- Thread-topic: [incquery-dev] Repository freeze: project merge
>> However, if you could have a look at the structure to see what to expect after the merge is complete.
> One question: I see that the standard folders (plugins, features, â) are now subfolders of the top-level logical structure (addon, artwork, â). Why is this better than the other way around (i.e. having plugins, features on the top and addon, artwork as subfolders)?
> (Donât get me wrong, I would have also done it this way, Iâm just curious whether there is more than just preference behind this arrangement.)
Basically, I want to be able to split up the monster parent.pom in a reasonable way. It wonât be perfect because the way the projects/components depend on each other, but I still see there the promise of somehow being able to produce a more modular build.
I guess, during the next months, the build configuration will be adjusted in small bits to test out the possibilities; what I hope here is a way to have builds that are only responsible for the separate components. Truth to be told, this is not my first priority for now, this can be added later when the entire repository is not freezed (this is the main reason for releng stuff is globally stored, not specifically for each component).
Furthermore, it also allows easier manual management, as it should be clear what projects relate closer to each other.
>> Furthermore, we have found that the EMF metamodel in the org.eclipse.incquery.xcore.model project is very strange: it refers to both the Xcore and the IncQuery PatternLanguage metamodel using relative paths that is very hard to handle correctly.
> Isnât this a generated artefact that somehow got checked in?
It did not seem to me like that. If I understood it correctly, it was a hand-made EMF metamodel to store the custom elements of the xcoreiq grammar, that was referenced. To tell the truth, we noticed this with BalÃzs at the end of the day, when we were very tired to figure out exactly how should it work; and based on our previous experiments these relative paths are a big red flag for me, we basically left them as it is.
However, if someone remembers some details from the times when the Xcore integration was developed (e.g. something to watch for), it would be appreciated.
-- ZoltÃn Ujhelyi
Eclipse Technologies Expert