- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Package Pool und Tags / Revisionen
Hallo Community,
ich verwende die Paketverwaltung, um Content aus einem Masterprojekt in ein Zielprojekt auszurollen. Im Zielprojekt mรถchte ich in einem Workflow die durch den Rollout entstandenen รnderungen analysieren. Hierfรผr habe ich an das Ereignis "Freigabe" einen Workflow gehรคngt, in dessen erster Aktivitรคt ein Skript ausgefรผhrt wird. Die Idee war nun, anhand der durch den Package Pool erzeugten Tags die relevanten Revisionen zu finden. Das Problem ist, dass im Skript ein Tag nicht gefunden wird, welches jedoch bei einer folgenden Abfrage รผber die Beanshell-Konsole vorhanden ist.
Der Aufruf:
context.project.getTags(null, 10);
innerhalb des Skriptes im Workflow liefert z. B.:
<[de.espirit.firstspirit.storage.TagImpl@6e5, de.espirit.firstspirit.storage.TagImpl@6e4, ...
wohingegen der Aufruf auf der Beanshell-Console ein Tag mehr liefert (das neueste):
<[de.espirit.firstspirit.storage.TagImpl@6e6, de.espirit.firstspirit.storage.TagImpl@6e5, de.espirit.firstspirit.storage.TagImpl@6e4, ...
Das zusรคtzliche Tag ist eindeutig durch den Paket-Rollout entstanden, was ich anhand der Tag-Properties "PackageName" und "PackageVersionNumber" validiere.
Die erste Frage wรคre, worin das Verhalten des Skriptes innerhalb des Workflows begrรผndet ist. Warum fehlt das zusรคtzliche Tag beim Aufruf aus dem Skript, obwohl es durch den Paket-Rollout erzeugt wurde?
Die nรคchste Frage wรคre, ob es einen anderen Weg gibt, verlรคsslich *alle* Revisionen zu finden, die durch einen Package-Rollout erzeugt wurden. Ich gehe รผber die Tags, da anhand der Tag-Properties eindeutige Kriterien vorhanden sind, worรผber ein Tag dem Package-Rollout zugeordnet werden kann (Properties "PackageVersionNumber" und "PackageName"). Gibt es ein anderes Vorgehen?
Fรผr jedwede Hilfe bedanke ich mich im Vorraus. Grรผรe,
Tilman Linden
- Labels:
-
Developers
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Was soll den dadurch erreicht werden?
Generell kann man รผber das "ImportInfo" arbeiten hier gibt es dann 4 Arten von Knoten (neu, gelรถscht, geรคndert, Konflikt). Fรผr "neu" und "gelรถscht" und "Konflikt" ist damit schon klar was verรคndert wurde. Auf den Objekten, die "geรคndert" wurden kann man jetzt die รnderungen analysieren (Stichwort: HistoryProvider).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hallo Tobias,
der Ansatz mit den Tags ist wie beschrieben darin begrรผndet, dass sich anscheinend Tags รผber die Properties "PackageVersionNumber" und "PackageName" eindeutig einem Paket-Rollout zuordnen lassen. Ein solches Kriterium habe ich bei Revisionen nicht finden kรถnnen. Zwar finden sich im Kommentar der Revisionen ebenfalls Hinweise auf den Paket-Rollout, jedoch nach meinem Wissensstand verpackt in einem einzigen String. Dieses Kriterium war mir "zu weich"(anders gesagt: aVersionNumber.equals(Tag.getProperty("PackageVersionNumber")) finde ich belastbarer als Revision.getComment().indexOf(aVersionNumber) >= 0). Ich lasse mich aber gerne eines besseren belehren.
Mein erster Ansatz war รผbrigens, รผber ImportInfo zu gehen und mir nur die neueste Revision der neuen/geรคnderten Knoten geben zu lassen und diese zu analysieren. Mir ist dann jedoch aufgefallen, dass es unter (mir unbekannten) Umstรคnden anscheinend mehrere Revisionen fรผr einen Knoten pro Paket-Rollout geben kann. Daher suche ich eben nach einem Kriterium, diese Revisionen verlรคsslich finden zu kรถnnen.
Weitere Hilfe gerne! Gruร,
Tilman
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Gibt es hier noch weitere Erkenntnisse?
Danke und Grรผรe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hier hat sich nun รผber andere Kanรคle einiges klรคren lassen, was ich hier nochmal kurz zusammenfasse:
- Die durch einen Paketrollout gesetzten Tags werden tatsรคchlich erst *nach* der Ausfรผhrung von mit Paket-Ereignissen verbundenen Workflows vollstรคndig gesetzt.
- Ich verwende nun folgenden Ansatz, um die relevanten Revisionen zu finden:
- Die untere Grenze der zu analysierenden Revisionen ist durch die Revision gegeben, die mit einem "Restore-Tag" versehen ist. Dieses Tag wird durch die Paketverwaltung gesetzt, bevor irgendwelche รnderungen im Zielprojekt vorgenommen werden, und lรคsst sich folgendermaรen identifizieren:
Arrays.asList("RestoreImportPackage", "RestoreInstallUpdate").contains(theTag.getName()) && theNameOfThePackage.equals(theTag.getProperty("PackageName") &&theVersionNumberOfThePackage.equals(theTag.getProperty("PackageVersionNumber")
- Fรผr alle geรคnderten / neuen Knoten sind jetzt die Revisionen nach der Revision des Restore-Tags bis zur aktuellen Revision relevant. (Die Revision mit dem Restore-Tag selber ist nicht zu betrachten.)
- Die untere Grenze der zu analysierenden Revisionen ist durch die Revision gegeben, die mit einem "Restore-Tag" versehen ist. Dieses Tag wird durch die Paketverwaltung gesetzt, bevor irgendwelche รnderungen im Zielprojekt vorgenommen werden, und lรคsst sich folgendermaรen identifizieren:

