[
https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi...
]
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)