2

I'm looking for a better solution for a problem, I solved it yesterday, but I'm not happy ;)

My task: Create a fully functional Eclipse update site with Nexus (can be used for updates and target platform definitions)

My problem: The original extension for P2 sites for Nexus only considers plugins (Github: Nexus P2)

Unfortunately, the Fork, which considered features, is also out of date. But I found a workaround in Maven P2 plugin. If a plugin is categorized, you can install it with Eclipse.

Therefore, I searched for a way to categorize my plugins. I build with Tycho, but the Nexus does not consider the metadata of Tycho. So I had to find a way to let Nexus categorize my plugins without Tycho. Finally, I patched the Nexus P2 bridge plugin and add a default category to each plugin. In addition, we can use this way to omit features!

Categorization with Eclipse, I only know the composition of repositories. Tycho can categorize repositories as well, but the Nexus completely ignored the metadata.

Does anyone have a suggestion on how to categorize plugins or bundles? The target is to construct a more useful processing with these metadata in P2 Nexus plugin.

Nachtgold
  • 539
  • 1
  • 6
  • 27
  • What is the primary purpose of the update site you are trying to create: Delivering updates to users from a stable URL (which implies that the update site has to be mutable), or binary artifact exchange between builds (which is best done with immutable update sites)? – oberlies Nov 19 '12 at 10:21
  • A mutable site with a constant URL for the target platform description of all modules of the whole team. – Nachtgold Nov 20 '12 at 08:52

1 Answers1

0

Nexus' primary purpose is the exchange of artifact between builds, and not their delivery to end users. Therefore I doubt that Nexus is particularly well suited for what you are trying to achieve.

If you still want to use Nexus, I'd recommend to only use it to host the build results (as described in this answer), and host the location that your customers use as update URL as a (mutable) composite repository, pointing to the build result repositories in Nexus, on some other server. (You could also store the composite as snapshot in Nexus, but the SNAPSHOT in the URL may be confusing.)

However, I'm not aware of any good tooling supporting this approach.

Community
  • 1
  • 1
oberlies
  • 11,503
  • 4
  • 63
  • 110