[jbosstools-issues] [JBoss JIRA] (JBIDE-15135) Attach metadata during assembly instead of publish time

Mickael Istria (JIRA) issues at jboss.org
Mon Jan 5 11:26:30 EST 2015


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

Mickael Istria commented on JBIDE-15135:
----------------------------------------

{quote}QUESTION Should there be something in upstream?{quote}
Upstream contains the buildInfo from upstream sites, when available (except there own upstream elements or we'd get huge files)

{quote}QUESTION What about details about the OS & JDK version?{quote}
I didn't include them because I never used them (I also use this mojo as an opportunity to think about what's not useful any more). It would be easy to re-introduce if you use them occasionally.

{quote}QUESTION Why are TARGET_PLATFORM_VERSION, TARGET_PLATFORM_VERSION_MAXIMUM, BUILD_ALIAS and BUILD_ID not resolved? The first 3 of those are from maven variables in the parent pom (if not set commandline), and BUILD_ID is a timestamp that could be the same as the one placed in GIT_REVISION.txt{quote}
This should report the build properties that are specified manually. So unless you set those properties, buildInfo reports null. On Jenkins, since we set thos properties, they would be set.

{quote}QUESTION Why is WORKSPACE not listed, and resolved to `pwd` ? This is often useful when builds fail to figure out where files have been created on a slave's filesystem, because they don't all use the same workspace path convention. And while you CAN browse the workspace within Jenkins, sometimes it's more efficient to do so over ssh.{quote}
Same reason, it's reporting the value of the property from Jenkins (or CLI).

{quote}QUESTION Can you also generate an ALL_VERSIONS.txt for aggregate builds? Or does that only happen when the mojo detects there are upstream projects? If so, how do I tell the mojo that there are upstream projects when building locally?{quote}
This is meant to go in the upstream block when upstream data is available

{quote}QUESTION Why did you change the format of GIT_REVSION.txt? I like that you've added details about the repo from which the code comes, but would a format such as the one below be more compact & easier to parse out the useful values of branch/tag, SHA, and source repo?{quote}
I created this new format because it would also list aliases when there are some. I don't mind much changing it since I believe the "revision" block of buildinfo.json is a better alternative.


> Attach metadata during assembly instead of publish time
> -------------------------------------------------------
>
>                 Key: JBIDE-15135
>                 URL: https://issues.jboss.org/browse/JBIDE-15135
>             Project: Tools (JBoss Tools)
>          Issue Type: Feature Request
>          Components: build
>            Reporter: Mickael Istria
>            Assignee: Mickael Istria
>             Fix For: 4.2.x
>
>
> In order to make it easier to deal with Nexus and to have an homogeneous way to access build metadata (commit id), it would be interesting to move creation of metadata at assembly time (same time as when we create index and so on), and put it directly into the site.
> Then whether we use Nexus or a home-made publication, we are sure that we can access metadata whenever we can access the binaries.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


More information about the jbosstools-issues mailing list