Bug 473454 - Add Hook before resolving in reactor phase
Summary: Add Hook before resolving in reactor phase
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Tycho (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-24 03:30 EDT by Pieter-Jan Pintens CLA
Modified: 2021-04-28 16:53 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pieter-Jan Pintens CLA 2015-07-24 03:30:27 EDT
In our build we use tycho to build a fairly big amount of projects.
To keep things simple for regular developers I try to keep the amount of actions they need to perform to build our product themselves as small as possible.
That is 1 command.

Our setup also involves 'stages', that is we have multiple repositories with eclipse plugins/features/products that are build sequentially.
-> They depend on each other.
-> Is required because of internal teams etc
-> Otherwise build would take way to long

Our build environment assumes that multiple 'concurrent' builds are possible.
Each build can have different profiles to de less/more work. Say signing, findbugs test, add documentation etc. To keep performance optimal we defined some default build types resulting is faster en slower builds (30minutes -> >3h).

All artifacts are pushed to nexus and are referenced with the nexus unzip plugin in the target files.

Currently I defined the following types of build:
-integration
-nightly
-relaese

=> Each build pushes artifacts to nexus under a different name based on the type.
=> Each build thus has a different target file linking it to the correct nexus location based on its type.
=> The idea is the same over all our stages so builds simply pass there type and sequential builds work fine.

Now, I need to make things even more dynamic. That is I need to add custom 'types' to my list. The idea remains the same, a developer should be able to define a label (issue number) to his build so that he can create and run tests with his specific build (issue number is linked to a git repo). The problem here is that I cannot find a proper way to make target files dynamic. There does not seem to be a way to perform some action before the resolver kicks in and tries to do things with the target files. What I need would be some kind of hook that allows me to modify/generate a custom target file based on the type provided before the resolver kicks in.

From what I found there is a custom LiveCycleParticipant which starts the resolving process. Is it possible to somehow get in between? I'm not very familiar with the maven API / internal working but an optional custom component that has a method that is called would already be enough.

http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-core/src/main/java/org/eclipse/tycho/core/maven/TychoMavenLifecycleParticipant.java

For now I think that the only solution is to do some pre build step. Not a big issue I assume but it would be nice If I can stick to one command to do the build.

If there are other solutions I did not think off, that would be fine too.
Comment 1 Jan Sievers CLA 2015-07-24 03:32:56 EDT
I think this boils down to bug 353889
Comment 2 Jan Sievers CLA 2015-07-24 03:39:25 EDT
> 'types' to my list. The idea remains the same, a developer should be able to
> define a label (issue number) to his build so that he can create and run
> tests with his specific build (issue number is linked to a git repo). The
> problem here is that I cannot find a proper way to make target files
> dynamic. There does not seem to be a way to perform some action before the
> resolver kicks in and tries to do things with the target files. What I need
> would be some kind of hook that allows me to modify/generate a custom target
> file based on the type provided before the resolver kicks in.

If you have a fixed number of target files, one thing you can do is add them all to your build and activate one of them based on properties or maven profiles. 

Example:

http://git.eclipse.org/c/egit/egit.git/tree/org.eclipse.egit.target
Comment 3 Pieter-Jan Pintens CLA 2015-07-24 03:51:10 EDT
The problem is that I with the new requirement I no longer have a fixed number of target files.

Thanks for pointing to the other issue. Maybe I can find help there.
Comment 4 Mickael Istria CLA 2021-04-08 18:12:56 EDT
Eclipse Tycho is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse/tycho/issues/ instead. If this issue is relevant to you, your action is required.
0. Verify this issue is still happening with latest Tycho 2.4.0-SNAPSHOT
  if issue has disappeared, please change status of this issue to "CLOSED WORKFORME" with some details about your testing environment and how you did verify the issue; and you're done
  if issue is still present when latest release:
* Create a new issue at https://github.com/eclipse/tycho/issues/
  ** Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience)
  ** In the GitHub description, start with a link to this bugzilla ticket
  ** Optionally add new content to the description if it can helps towards resolution
  ** Submit GitHub issue
* Update bugzilla ticket
  ** Add to "See also" property (up right column) the link to the newly created GitHub issue
  ** Add a comment "Migrated to <link-to-newly-created-GitHub-issue>"
  ** Set status as CLOSED MOVED
  ** Submit

All issues that remain open will be automatically closed next week or so. Then the Bugzilla component for Tycho will be archived and made read-only.