[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=13068897#comment-13068897 ] 

Mickael Istria edited comment on JBIDE-16128 at 5/18/15 10:59 AM:
------------------------------------------------------------------

If we replace the BUILD_ALIAS by a fixed version in the root pom of each components, here is what we gain:
* We deploy to Nexus, using regular Maven deployment steps (less usage of in-house scripts)
* We don't have to maintain conventions on download.jboss.org for the CI builds
* We move to a more standard Maven approach, that several other Eclipse projects are using

So overall, are build/publication process becomes more accessible.
The simplicity to publish comes with the following drawbacks, mainly caused by the fact that Maven versions are statically defined and don't allow to reference variables (such as BUILD_ALIAS).
* It's very important that components do not forget to bump version in there root pom (and immediate children), to make sure master and branch do not collide to the same URL on Nexus. => Possible workaround: we add the BUILD_ALIAS property to jobs and add a step on CI or in pom.xml to guarantee that version ends with BUILD_ALIAS-SNAPSHOT.
* it's more complicated to update root pom + immediate children than to update only root pom.  => However, if you do it wrong, build fails explicitly, so not much surprise.

My impression is that it seems worth it, and that the cost in lower than the gain.


was (Author: mickael_istria):
If we replace the BUILD_ALIAS by a fixed version in the root pom of each components, here is what we gain:
* We deploy to Nexus, using regular Maven deployment steps (less usage of in-house scripts)
* We don't have to maintain conventions on download.jboss.org for the CI builds
* We move to a more standard Maven approach, that several other Eclipse projects are using
So overall, are build/publication process becomes more accessible.
The simplicity to publish comes with the following drawbacks, mainly caused by the fact that Maven versions are statically defined and don't allow to reference variables (such as BUILD_ALIAS).
* It's very important that components do not forget to bump version in there root pom (and immediate children), to make sure master and branch do not collide to the same URL on Nexus. => Possible workaround: we add the BUILD_ALIAS property to jobs and add a step on CI or in pom.xml to guarantee that version ends with BUILD_ALIAS-SNAPSHOT.
* it's more complicated to update root pom + immediate children than to update only root pom.  => However, if you do it wrong, build fails explicitly, so not much surprise.

My impression is that it seems worth it, and that the cost in lower than the gain.

> 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
>            Priority: Optional
>             Fix For: 4.3.x
>
>         Attachments: deployWithJenkins.png
>
>
> 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 was sent by Atlassian JIRA
(v6.3.15#6346)