[Modelinterpreter] körkörös függőség

[Karácsony Máté]

Sziasztok!

Van egy érdekesség, amibe nem gondoltam bele:

"If you add a dependency (to a plug-in or a package) in a fragment, then you effectively modify the class path of the host project as well."

Tehát a helyzet a következő. Az, hogy a model.tests fragment dependál az stdlib-re, azt okozza, hogy ezáltal a model is fog implicit. Az stdlib meg már explicit dependál rá, kész a kör.

Javasolt megoldás: a model.tests ne tartalmazzon stdlib-re dependency-t. Egyszerűen anélkül kell tesztelni. Az olyan teszteket, amik meg az stdlib-et is bevonják, az stdlib teszt fragmentjébe kell tenni. Ez lehet, hogy pont az, amit Gábor javasolt az előbb.

Üdv,
 Máté


On Friday, November 20, 2015 15:01 CET, Kovács Gábor Ferenc <kovacsgabor at caesar.elte.hu> wrote:
  Sziasztok!

A Gergő által felvázolt kört feloldhatjuk egészen könnyedén, ha a Timer-t használó teszteket áttesszük egy új api.stdlib.tests projekt alá, hiszen igazság szerint ezek ide tartoznának (mikor ezek a tesztek születtek, az api.stdlib és api.model még egy projekt volt .api néven).

Üdv:
Gábor
 2015.11.20. 12:54 keltezéssel, Karácsony Máté írta:Sziasztok!

Én ebben valahogy nem látom a kört, mert a fragment-host nyíl szerintem fordítva megy.
Tehát ez van (jelölés: a -(label)-> b, a függ valahogy b-től amit a label ír le):

stdlib -(manifest-dependency)-> model
model.tests -(fragment-host)-> model
model.tests -(manifest-dependency)-> stdlib -(manifest-dependency)-> model

Szóval szerintem ez simán tranzitív, de nem kör. Vagy nem értek valamit.

Üdv,
 Máté

On Friday, November 20, 2015 11:40 CET, Dévai Gergely <deva at caesar.elte.hu> wrote:
   Sziasztok!

Leírom az egyik konkrét problémát, hátha az előrébb visz:

* hu.elte.txtuml.api.stdlib --> hu.elte.txtuml.api.model
Normál plugin függőség, a Timer API implementációjához szükséges az API többi része.
* hu.elte.txtuml.api.model --> hu.elte.txtuml.api.model.tests
Implicit függőség a test manifestjében lévő "Fragment-Host: hu.elte.txtuml.api.model" miatt.
* hu.elte.txtuml.api.model.tests --> hu.elte.txtuml.api.stdlib
Normál plugin függőség, a tesztek használnak Timer-t.

Az update site generáláshoz a test pluginek nem kellenek, tehát lehet az a Jenkins megoldás, hogy a tesztek lefuttatása után csak az update site létrehozásában szerepet játszó plugineket tartjuk a workspace-ben.

Üdv,
Gergő

On Friday, November 20, 2015 09:57 CET, Karácsony Máté <kmate at caesar.elte.hu> wrote:
   Sziasztok!

Ha Eclipse-ben előjön, akkor igen nagy valószínűséggel ez lesz a helyzet a Jenkins-ben is, mert a tycho-nak ugyanúgy kellene dependency-t számolnia. Nem tudom pontosan mi a helyzet azzal a két teszttel, de ez teljesen bevett és működő dolog, hogy fragment-host-ként a teszt hivatkozik a tesztelt dologra, és nem fordítva (furcsa is lenne eléggé). Szóval szerintem az lenne az előnyös, ha ez a konkrét eset lenne valahogy kibogozva, és nem találnánk fel újra valami más, nem igazán standard eljárást a tesztek kezelésére.

Üdv,
 Máté

On Thursday, November 19, 2015 23:17 CET, Dévai Gergely <deva at caesar.elte.hu> wrote:
   Sziasztok!

A megbeszélésen emlegettem, hogy a 'mars' branchben elbukik az update site generálás körkörös függőség miatt. A furcsa az, hogy a plugin függőségekben nincs kör.
A valódi ok az, hogy a test projektjeink most "Fragment-Host: ..." deklarációval hivatkoznak a tesztelt pluginra, és ez a tesztelt pluginhoz implicit függőségként felveszi a tesztprojektet (igen, igy és nem forditva!). A körkörös függőségről szóló hibaüzenetben sajnos nem jelenik meg maga a tesztprojekt, ezért google nélkül esélytelen rájönni...
http://stackoverflow.com/questions/5516215/despite-circular-dependency-error-in-eclipse-plugin-export-i-cannot-find-cycle

Ha eltávolitok két teszt projektet a workspace-ből, akkor sikeres az update site generálás. Nem tudom, hogy jenkins-ben is előjön-e majd ez a gond. Mindenesetre el lehetne gondolkozni a Fragment-Host helyett valami más megoldáson.

Üdv,
Gergő
 


 


 


   _______________________________________________
Modelinterpreter mailing list
Modelinterpreter at plc.inf.elte.hu
https://plc.inf.elte.hu/mailman/listinfo/modelinterpreter



 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://plc.inf.elte.hu/pipermail/modelinterpreter/attachments/20151120/28ffeb6b/attachment-0001.html>