[jbosstools-issues] [JBoss JIRA] (JBIDE-16128) Publish component sites to Nexus

[Mickael Istria (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-16128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12926841#comment-12926841 ] 

Mickael Istria commented on JBIDE-16128:
----------------------------------------

The whole purpose of relying to Nexus is to reduce the amount of maintainance/gouvernance we have when it comes to publishing stuff. If we can rely on standard Maven mechanism, we provide more portability, with less effort.

> If you're not going to consume the sites, when why bother? How will you know what the performance pros/cons are if we don't stress-test the system?

The goal is first to see the issues that we'll have at publication (such as colliding versions). It's a first step. Ultimately, we'll also try to consume these Nexus site for aggregation.

> Is the point of this to publish just milestones and .Final bits? Or every single nightly build? If the former, that's semi-reasonable, especially if we are planning to move toward the IS model of "components can release their Final earlier than the rest of the stack".

Point is to publish SNAPSHOTs in a first time, through the CI jobs. Just that will require projects to start working on releasing their own "Final" as dealing with version is a necessary step in that direction.

> Thus instead of these sites: ... we'd have the equivalent bits in Nexus: ....

Nexus URLs are a bit ugly, that probably won't be the one we'll provide to end-users. If we go for a "build-on-nexus" approach, we'll probably release stuff by mirroring the output of Nexus to a nicer location, such as the ones we're using now.

> What exactly does moving to nexus get us? 

Remove necessity to maintain:
* publish.sh
* URL conventions
and many stuff related to publication of CI builds

> Also, are you assuming that component owners will be responsible for doing their own promotes from nexus-staging to nexus-public?

First, I would test it only for SNAPSHOTs. Component developers will learn that they need to take care of not having the same version on different streams. That would already be a great step forward.
Then we may be interested in teaching them how to release their own component, but I see that as a secondary step, after simply publishing of SNAPSHOTs on Nexus.


                
> Publish component sites to Nexus
> --------------------------------
>
>                 Key: JBIDE-16128
>                 URL: https://issues.jboss.org/browse/JBIDE-16128
>             Project: Tools (JBoss Tools)
>          Issue Type: Enhancement
>          Components: build
>            Reporter: Mickael Istria
>            Assignee: Mickael Istria
>             Fix For: 4.2.0.Alpha1
>
>
> In order to get a first idea of how easy/difficult it would be to rely on Nexus for publication,we could simply start by configuring CI jobs to also run a "mvn deploy" to deploy the output p2 repository onto Nexus.
> Then we'll see what are the pros/cons of this approach.
> Current publication process and locations will be kept. These p2 repo on Nexus won't be consumed by aggregator, at least not until we are sure it's worth it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira