[JBoss JIRA] (JBIDE-15135) Attach metadata during assembly instead of publish time
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-15135 at 12/22/14 11:55 AM:
---------------------------------------------------------------
Apologies for the great delay in getting around testing this out and reviewing the output. Overall, this is a vast improvement over what we had before w/ a hodge-podge of shell scripts.
First, some clarifications to answer your questions & outline a bit more what I think this mojo has to do (beyond what it already does).
*{color:orange}CLARIFICATION{color}*
I don't think we need zip file references for two reasons:
a) they were originally added because we didn't have Eclipse-SourceReferences in the MANIFEST.MF files, and needed a way to collect all the upstream sources
b) they have generic names (rather than timestamped/buildID'd) so they're not really useful UNLESS the zips themselves are colocated in the build folder, which we no longer need.
*{color:orange}CLARIFICATION{color}*
As to the included metadata, we need:
* build details (re: the server/VM config, JDK version/paths, etc.), eg., http://download.jboss.org/jbosstools/builds/staging/jbosstools-openshift_...
* build log (only useful when things go wrong and access to Jenkins is slow/impossible, so not strictly REQUIRED, only helpful)
* git revs for upstream sources, eg., http://download.jboss.org/jbosstools/builds/stable/4.1.2.Final.core/2014-...
----
Next, I tried to build & test this out.
*{color:blue}STEPS TO REPRO{color}*
In trying to use the above locally, I've realized 3 things:
a) you need to use <version>0.22.1-SNAPSHOT</version> as 0.22.0-SNAPSHOT is no longer available in Nexus or in your fork
b) you need to run a build of something like jbosstools-build-sites/aggregate/site/pom.xml with -DtychoVersion=0.22.0, as repository-utils now depends on on that
c) you need to build with JDK8, or get:
{code}
[ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site (generate-full-site) on project org.jboss.tools.site.core: Execution generate-full-site of goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site failed: An API incompatibility was encountered while executing org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site: java.lang.UnsupportedClassVersionError: org/json/JSONObject : Unsupported major.minor version 52.0
{code}
So, I inserted the above block into jbosstools-build-sites/aggregate/site/pom.xml (and fixed the version to be 0.22.1-SNAPSHOT), then:
{code}
$➔ mvn --version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400)
Maven home: /opt/maven3
Java version: 1.8.0, vendor: Oracle Corporation
Java home: /opt/jdk1.8.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.17.4-200.fc20.x86_64", arch: "amd64", family: "unix"
{code}
{code}
$➔ mvn clean install -DtychoVersion=0.22.0 -DBUILD_ID=666 -DJOB_NAME=jbosstools-build-sites.aggregate.site_master -DHUDSON_SLAVE=dev69 -DRELEASE=no
{code}
And here are the results::
{code:title=aggregate/site/target/fullSite/all/repo/buildInfo.json}{
"upstream": {},
"properties": {
"BUILD_NUMBER": "666",
"RELEASE": "no",
"JOB_NAME": "jbosstools-build-sites.aggregate.site_master",
"HUDSON_SLAVE": "dev69"
},
"timestamp": 1419266314705,
"revision": {
"HEAD": "89898db85f9e38972360c42782247f0e2b7304b0",
"knownReferences": [{
"ref": "JBIDE-18869",
"name": "nickboldt",
"url": "git@github.com:nickboldt/jbosstools-build-sites.git"
}]
}
}{code}
{code:title=aggregate/site/target/fullSite/logs/GIT_REVISION.txt}
#Mon Dec 22 11:21:56 EST 2014
git@github.com\:nickboldt/jbosstools-build-sites.git\:JBIDE-18869=89898db85f9e38972360c42782247f0e2b7304b0
HEAD=89898db85f9e38972360c42782247f0e2b7304b0
{code}
{code:title=aggregate/site/target/fullSite/logs/build.properties}
BUILD_ALIAS=null
JOB_NAME=jbosstools-build-sites.aggregate.site_master
BUILD_NUMBER=666
BUILD_ID=null
HUDSON_SLAVE=dev69
RELEASE=no
ZIPSUFFIX=null
TARGET_PLATFORM_VERSION=null
TARGET_PLATFORM_VERSION_MAXIMUM=null
{code}
Now, some questions:
* *{color:red}QUESTION{color}* Should there be something in upstream?
* *{color:red}QUESTION{color}* What about details about the OS & JDK version?
* *{color:red}QUESTION{color}* 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
* *{color:red}QUESTION{color}* 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._
* *{color:red}QUESTION{color}* 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?
was (Author: nickboldt):
*{color:orange}CLARIFICATION{color}*
I don't think we need zip file references for two reasons:
a) they were originally added because we didn't have Eclipse-SourceReferences in the MANIFEST.MF files, and needed a way to collect all the upstream sources
b) they have generic names (rather than timestamped/buildID'd) so they're not really useful UNLESS the zips themselves are colocated in the build folder, which we no longer need.
*{color:orange}CLARIFICATION{color}*
As to the included metadata, we need:
* build details (re: the server/VM config, JDK version/paths, etc.), eg., http://download.jboss.org/jbosstools/builds/staging/jbosstools-openshift_...
* build log (only useful when things go wrong and access to Jenkins is slow/impossible, so not strictly REQUIRED, only helpful)
* git revs for upstream sources, eg., http://download.jboss.org/jbosstools/builds/stable/4.1.2.Final.core/2014-...
*{color:blue}STEPS TO REPRO{color}*
In trying to use the above locally, I've realized 3 things:
a) you need to use <version>0.22.1-SNAPSHOT</version> as 0.22.0-SNAPSHOT is no longer available in Nexus or in your fork
b) you need to run a build of something like jbosstools-build-sites/aggregate/site/pom.xml with -DtychoVersion=0.22.0, as repository-utils now depends on on that
c) you need to build with JDK8, or get:
{code}
[ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site (generate-full-site) on project org.jboss.tools.site.core: Execution generate-full-site of goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site failed: An API incompatibility was encountered while executing org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site: java.lang.UnsupportedClassVersionError: org/json/JSONObject : Unsupported major.minor version 52.0
{code}
So, I inserted the above block into jbosstools-build-sites/aggregate/site/pom.xml (and fixed the version to be 0.22.1-SNAPSHOT), then:
{code}
$➔ mvn --version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400)
Maven home: /opt/maven3
Java version: 1.8.0, vendor: Oracle Corporation
Java home: /opt/jdk1.8.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.17.4-200.fc20.x86_64", arch: "amd64", family: "unix"
{code}
{code}
$➔ mvn clean install -DtychoVersion=0.22.0 -DBUILD_ID=666 -DJOB_NAME=jbosstools-build-sites.aggregate.site_master -DHUDSON_SLAVE=dev69 -DRELEASE=no
{code}
Results:
{code:title=aggregate/site/target/fullSite/all/repo/buildInfo.json}{
"upstream": {},
"properties": {
"BUILD_NUMBER": "666",
"RELEASE": "no",
"JOB_NAME": "jbosstools-build-sites.aggregate.site_master",
"HUDSON_SLAVE": "dev69"
},
"timestamp": 1419266314705,
"revision": {
"HEAD": "89898db85f9e38972360c42782247f0e2b7304b0",
"knownReferences": [{
"ref": "JBIDE-18869",
"name": "nickboldt",
"url": "git@github.com:nickboldt/jbosstools-build-sites.git"
}]
}
}{code}
{code:title=aggregate/site/target/fullSite/logs/GIT_REVISION.txt}
#Mon Dec 22 11:21:56 EST 2014
git@github.com\:nickboldt/jbosstools-build-sites.git\:JBIDE-18869=89898db85f9e38972360c42782247f0e2b7304b0
HEAD=89898db85f9e38972360c42782247f0e2b7304b0
{code}
{code:title=aggregate/site/target/fullSite/logs/build.properties}
BUILD_ALIAS=null
JOB_NAME=jbosstools-build-sites.aggregate.site_master
BUILD_NUMBER=666
BUILD_ID=null
HUDSON_SLAVE=dev69
RELEASE=no
ZIPSUFFIX=null
TARGET_PLATFORM_VERSION=null
TARGET_PLATFORM_VERSION_MAXIMUM=null
{code}
* *{color:red}QUESTION{color}* Should there be something in upstream?
* *{color:red}QUESTION{color}* What about details about the OS & JDK version?
* *{color:red}QUESTION{color}* 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
* *{color:red}QUESTION{color}* 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._
* *{color:red}QUESTION{color}* 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?
> 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)
11 years, 3 months
- 1
- 0
[JBoss JIRA] (JBIDE-15135) Attach metadata during assembly instead of publish time
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-15135 at 12/22/14 11:56 AM:
---------------------------------------------------------------
Apologies for the great delay in getting around testing this out and reviewing the output. Overall, this is a vast improvement over what we had before w/ a hodge-podge of shell scripts.
First, some clarifications to answer your questions & outline a bit more what I think this mojo has to do (beyond what it already does).
*{color:orange}CLARIFICATION{color}*
I don't think we need zip file references for two reasons:
a) they were originally added because we didn't have Eclipse-SourceReferences in the MANIFEST.MF files, and needed a way to collect all the upstream sources
b) they have generic names (rather than timestamped/buildID'd) so they're not really useful UNLESS the zips themselves are colocated in the build folder, which we no longer need.
*{color:orange}CLARIFICATION{color}*
As to the included metadata, we need:
* build details (re: the server/VM config, JDK version/paths, etc.), eg., http://download.jboss.org/jbosstools/builds/staging/jbosstools-openshift_...
* build log (only useful when things go wrong and access to Jenkins is slow/impossible, so not strictly REQUIRED, only helpful)
* git revs for upstream sources, eg., http://download.jboss.org/jbosstools/builds/stable/4.1.2.Final.core/2014-...
----
Next, I tried to build & test this out.
*{color:blue}STEPS TO REPRO{color}*
In trying to use the above locally, I've realized 3 things:
a) you need to use <version>0.22.1-SNAPSHOT</version> as 0.22.0-SNAPSHOT is no longer available in Nexus or in your fork
b) you need to run a build of something like jbosstools-build-sites/aggregate/site/pom.xml with -DtychoVersion=0.22.0, as repository-utils now depends on on that
c) you need to build with JDK8, or get:
{code}
[ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site (generate-full-site) on project org.jboss.tools.site.core: Execution generate-full-site of goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site failed: An API incompatibility was encountered while executing org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site: java.lang.UnsupportedClassVersionError: org/json/JSONObject : Unsupported major.minor version 52.0
{code}
So, I inserted the above block into jbosstools-build-sites/aggregate/site/pom.xml (and fixed the version to be 0.22.1-SNAPSHOT), then:
{code}
$➔ mvn --version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400)
Maven home: /opt/maven3
Java version: 1.8.0, vendor: Oracle Corporation
Java home: /opt/jdk1.8.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.17.4-200.fc20.x86_64", arch: "amd64", family: "unix"
{code}
{code}
$➔ mvn clean install -DtychoVersion=0.22.0 -DBUILD_ID=666 -DJOB_NAME=jbosstools-build-sites.aggregate.site_master -DHUDSON_SLAVE=dev69 -DRELEASE=no
{code}
----
And here are the results::
{code:title=aggregate/site/target/fullSite/all/repo/buildInfo.json}{
"upstream": {},
"properties": {
"BUILD_NUMBER": "666",
"RELEASE": "no",
"JOB_NAME": "jbosstools-build-sites.aggregate.site_master",
"HUDSON_SLAVE": "dev69"
},
"timestamp": 1419266314705,
"revision": {
"HEAD": "89898db85f9e38972360c42782247f0e2b7304b0",
"knownReferences": [{
"ref": "JBIDE-18869",
"name": "nickboldt",
"url": "git@github.com:nickboldt/jbosstools-build-sites.git"
}]
}
}{code}
{code:title=aggregate/site/target/fullSite/logs/GIT_REVISION.txt}
#Mon Dec 22 11:21:56 EST 2014
git@github.com\:nickboldt/jbosstools-build-sites.git\:JBIDE-18869=89898db85f9e38972360c42782247f0e2b7304b0
HEAD=89898db85f9e38972360c42782247f0e2b7304b0
{code}
{code:title=aggregate/site/target/fullSite/logs/build.properties}
BUILD_ALIAS=null
JOB_NAME=jbosstools-build-sites.aggregate.site_master
BUILD_NUMBER=666
BUILD_ID=null
HUDSON_SLAVE=dev69
RELEASE=no
ZIPSUFFIX=null
TARGET_PLATFORM_VERSION=null
TARGET_PLATFORM_VERSION_MAXIMUM=null
{code}
----
Now, some questions:
* *{color:red}QUESTION{color}* Should there be something in upstream?
* *{color:red}QUESTION{color}* What about details about the OS & JDK version?
* *{color:red}QUESTION{color}* 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
* *{color:red}QUESTION{color}* 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._
* *{color:red}QUESTION{color}* 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?
was (Author: nickboldt):
Apologies for the great delay in getting around testing this out and reviewing the output. Overall, this is a vast improvement over what we had before w/ a hodge-podge of shell scripts.
First, some clarifications to answer your questions & outline a bit more what I think this mojo has to do (beyond what it already does).
*{color:orange}CLARIFICATION{color}*
I don't think we need zip file references for two reasons:
a) they were originally added because we didn't have Eclipse-SourceReferences in the MANIFEST.MF files, and needed a way to collect all the upstream sources
b) they have generic names (rather than timestamped/buildID'd) so they're not really useful UNLESS the zips themselves are colocated in the build folder, which we no longer need.
*{color:orange}CLARIFICATION{color}*
As to the included metadata, we need:
* build details (re: the server/VM config, JDK version/paths, etc.), eg., http://download.jboss.org/jbosstools/builds/staging/jbosstools-openshift_...
* build log (only useful when things go wrong and access to Jenkins is slow/impossible, so not strictly REQUIRED, only helpful)
* git revs for upstream sources, eg., http://download.jboss.org/jbosstools/builds/stable/4.1.2.Final.core/2014-...
----
Next, I tried to build & test this out.
*{color:blue}STEPS TO REPRO{color}*
In trying to use the above locally, I've realized 3 things:
a) you need to use <version>0.22.1-SNAPSHOT</version> as 0.22.0-SNAPSHOT is no longer available in Nexus or in your fork
b) you need to run a build of something like jbosstools-build-sites/aggregate/site/pom.xml with -DtychoVersion=0.22.0, as repository-utils now depends on on that
c) you need to build with JDK8, or get:
{code}
[ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site (generate-full-site) on project org.jboss.tools.site.core: Execution generate-full-site of goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site failed: An API incompatibility was encountered while executing org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site: java.lang.UnsupportedClassVersionError: org/json/JSONObject : Unsupported major.minor version 52.0
{code}
So, I inserted the above block into jbosstools-build-sites/aggregate/site/pom.xml (and fixed the version to be 0.22.1-SNAPSHOT), then:
{code}
$➔ mvn --version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400)
Maven home: /opt/maven3
Java version: 1.8.0, vendor: Oracle Corporation
Java home: /opt/jdk1.8.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.17.4-200.fc20.x86_64", arch: "amd64", family: "unix"
{code}
{code}
$➔ mvn clean install -DtychoVersion=0.22.0 -DBUILD_ID=666 -DJOB_NAME=jbosstools-build-sites.aggregate.site_master -DHUDSON_SLAVE=dev69 -DRELEASE=no
{code}
And here are the results::
{code:title=aggregate/site/target/fullSite/all/repo/buildInfo.json}{
"upstream": {},
"properties": {
"BUILD_NUMBER": "666",
"RELEASE": "no",
"JOB_NAME": "jbosstools-build-sites.aggregate.site_master",
"HUDSON_SLAVE": "dev69"
},
"timestamp": 1419266314705,
"revision": {
"HEAD": "89898db85f9e38972360c42782247f0e2b7304b0",
"knownReferences": [{
"ref": "JBIDE-18869",
"name": "nickboldt",
"url": "git@github.com:nickboldt/jbosstools-build-sites.git"
}]
}
}{code}
{code:title=aggregate/site/target/fullSite/logs/GIT_REVISION.txt}
#Mon Dec 22 11:21:56 EST 2014
git@github.com\:nickboldt/jbosstools-build-sites.git\:JBIDE-18869=89898db85f9e38972360c42782247f0e2b7304b0
HEAD=89898db85f9e38972360c42782247f0e2b7304b0
{code}
{code:title=aggregate/site/target/fullSite/logs/build.properties}
BUILD_ALIAS=null
JOB_NAME=jbosstools-build-sites.aggregate.site_master
BUILD_NUMBER=666
BUILD_ID=null
HUDSON_SLAVE=dev69
RELEASE=no
ZIPSUFFIX=null
TARGET_PLATFORM_VERSION=null
TARGET_PLATFORM_VERSION_MAXIMUM=null
{code}
Now, some questions:
* *{color:red}QUESTION{color}* Should there be something in upstream?
* *{color:red}QUESTION{color}* What about details about the OS & JDK version?
* *{color:red}QUESTION{color}* 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
* *{color:red}QUESTION{color}* 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._
* *{color:red}QUESTION{color}* 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?
> 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)
11 years, 3 months
- 1
- 0
[JBoss JIRA] (JBIDE-15135) Attach metadata during assembly instead of publish time
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-15135 at 12/22/14 11:51 AM:
---------------------------------------------------------------
*{color:orange}CLARIFICATION{color}*
I don't think we need zip file references for two reasons:
a) they were originally added because we didn't have Eclipse-SourceReferences in the MANIFEST.MF files, and needed a way to collect all the upstream sources
b) they have generic names (rather than timestamped/buildID'd) so they're not really useful UNLESS the zips themselves are colocated in the build folder, which we no longer need.
*{color:orange}CLARIFICATION{color}*
As to the included metadata, we need:
* build details (re: the server/VM config, JDK version/paths, etc.), eg., http://download.jboss.org/jbosstools/builds/staging/jbosstools-openshift_...
* build log (only useful when things go wrong and access to Jenkins is slow/impossible, so not strictly REQUIRED, only helpful)
* git revs for upstream sources, eg., http://download.jboss.org/jbosstools/builds/stable/4.1.2.Final.core/2014-...
*{color:blue}STEPS TO REPRO{color}*
In trying to use the above locally, I've realized 3 things:
a) you need to use <version>0.22.1-SNAPSHOT</version> as 0.22.0-SNAPSHOT is no longer available in Nexus or in your fork
b) you need to run a build of something like jbosstools-build-sites/aggregate/site/pom.xml with -DtychoVersion=0.22.0, as repository-utils now depends on on that
c) you need to build with JDK8, or get:
{code}
[ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site (generate-full-site) on project org.jboss.tools.site.core: Execution generate-full-site of goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site failed: An API incompatibility was encountered while executing org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site: java.lang.UnsupportedClassVersionError: org/json/JSONObject : Unsupported major.minor version 52.0
{code}
So, I inserted the above block into jbosstools-build-sites/aggregate/site/pom.xml (and fixed the version to be 0.22.1-SNAPSHOT), then:
{code}
$➔ mvn --version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400)
Maven home: /opt/maven3
Java version: 1.8.0, vendor: Oracle Corporation
Java home: /opt/jdk1.8.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.17.4-200.fc20.x86_64", arch: "amd64", family: "unix"
{code}
{code}
$➔ mvn clean install -DtychoVersion=0.22.0 -DBUILD_ID=666 -DJOB_NAME=jbosstools-build-sites.aggregate.site_master -DHUDSON_SLAVE=dev69 -DRELEASE=no
{code}
Results:
{code:title=aggregate/site/target/fullSite/all/repo/buildInfo.json}{
"upstream": {},
"properties": {
"BUILD_NUMBER": "666",
"RELEASE": "no",
"JOB_NAME": "jbosstools-build-sites.aggregate.site_master",
"HUDSON_SLAVE": "dev69"
},
"timestamp": 1419266314705,
"revision": {
"HEAD": "89898db85f9e38972360c42782247f0e2b7304b0",
"knownReferences": [{
"ref": "JBIDE-18869",
"name": "nickboldt",
"url": "git@github.com:nickboldt/jbosstools-build-sites.git"
}]
}
}{code}
{code:title=aggregate/site/target/fullSite/logs/GIT_REVISION.txt}
#Mon Dec 22 11:21:56 EST 2014
git@github.com\:nickboldt/jbosstools-build-sites.git\:JBIDE-18869=89898db85f9e38972360c42782247f0e2b7304b0
HEAD=89898db85f9e38972360c42782247f0e2b7304b0
{code}
{code:title=aggregate/site/target/fullSite/logs/build.properties}
BUILD_ALIAS=null
JOB_NAME=jbosstools-build-sites.aggregate.site_master
BUILD_NUMBER=666
BUILD_ID=null
HUDSON_SLAVE=dev69
RELEASE=no
ZIPSUFFIX=null
TARGET_PLATFORM_VERSION=null
TARGET_PLATFORM_VERSION_MAXIMUM=null
{code}
* *{color:red}QUESTION{color}* Should there be something in upstream?
* *{color:red}QUESTION{color}* What about details about the OS & JDK version?
* *{color:red}QUESTION{color}* 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
* *{color:red}QUESTION{color}* 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._
* *{color:red}QUESTION{color}* 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?
was (Author: nickboldt):
*{color:orange}CLARIFICATION{color}*
I don't think we need zip file references for two reasons:
a) they were originally added because we didn't have Eclipse-SourceReferences in the MANIFEST.MF files, and needed a way to collect all the upstream sources
b) they have generic names (rather than timestamped/buildID'd) so they're not really useful UNLESS the zips themselves are colocated in the build folder, which we no longer need.
*{color:orange}CLARIFICATION{color}*
As to the included metadata, we need:
* build details (re: the server/VM config, JDK version/paths, etc.), eg., http://download.jboss.org/jbosstools/builds/staging/jbosstools-openshift_...
* build log (only useful when things go wrong and access to Jenkins is slow/impossible, so not strictly REQUIRED, only helpful)
* git revs for upstream sources, eg., http://download.jboss.org/jbosstools/builds/stable/4.1.2.Final.core/2014-...
*{color:blue}STEPS TO REPRO{color}*
In trying to use the above locally, I've realized 3 things:
a) you need to use <version>0.22.1-SNAPSHOT</version> as 0.22.0-SNAPSHOT is no longer available in Nexus or in your fork
b) you need to run a build of something like jbosstools-build-sites/aggregate/site/pom.xml with -DtychoVersion=0.22.0, as repository-utils now depends on on that
c) you need to build with JDK8, or get:
{code}
[ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site (generate-full-site) on project org.jboss.tools.site.core: Execution generate-full-site of goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site failed: An API incompatibility was encountered while executing org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site: java.lang.UnsupportedClassVersionError: org/json/JSONObject : Unsupported major.minor version 52.0
{code}
So, I inserted the above block into jbosstools-build-sites/aggregate/site/pom.xml (and fixed the version to be 0.22.1-SNAPSHOT), then:
{code}
$➔ mvn --version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400)
Maven home: /opt/maven3
Java version: 1.8.0, vendor: Oracle Corporation
Java home: /opt/jdk1.8.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.17.4-200.fc20.x86_64", arch: "amd64", family: "unix"
{code}
{code}
$➔ mvn clean install -DtychoVersion=0.22.0 -DBUILD_ID=666 -DJOB_NAME=jbosstools-build-sites.aggregate.site_master -DHUDSON_SLAVE=dev69 -DRELEASE=no
{code}
Results:
{code:title=aggregate/site/target/fullSite/all/repo/buildInfo.json}{
"upstream": {},
"properties": {
"BUILD_NUMBER": "666",
"RELEASE": "no",
"JOB_NAME": "jbosstools-build-sites.aggregate.site_master",
"HUDSON_SLAVE": "dev69"
},
"timestamp": 1419266314705,
"revision": {
"HEAD": "89898db85f9e38972360c42782247f0e2b7304b0",
"knownReferences": [{
"ref": "JBIDE-18869",
"name": "nickboldt",
"url": "git@github.com:nickboldt/jbosstools-build-sites.git"
}]
}
}{code}
{code:title=aggregate/site/target/fullSite/logs/GIT_REVISION.txt}
#Mon Dec 22 11:21:56 EST 2014
git@github.com\:nickboldt/jbosstools-build-sites.git\:JBIDE-18869=89898db85f9e38972360c42782247f0e2b7304b0
HEAD=89898db85f9e38972360c42782247f0e2b7304b0
{code}
{code:title=aggregate/site/target/fullSite/logs/build.properties}
BUILD_ALIAS=null
JOB_NAME=null
BUILD_NUMBER=null
BUILD_ID=null
HUDSON_SLAVE=null
RELEASE=null
ZIPSUFFIX=null
TARGET_PLATFORM_VERSION=null
TARGET_PLATFORM_VERSION_MAXIMUM=null
{code}
* *{color:red}QUESTION{color}* Should there be something in upstream?
* *{color:red}QUESTION{color}* What about details about the OS & JDK version?
* *{color:red}QUESTION{color}* 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
* *{color:red}QUESTION{color}* 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._
* *{color:red}QUESTION{color}* 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?
> 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)
11 years, 3 months
- 1
- 0
[JBoss JIRA] (JBIDE-15135) Attach metadata during assembly instead of publish time
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-15135 at 12/22/14 11:50 AM:
---------------------------------------------------------------
*{color:orange}CLARIFICATION{color}*
I don't think we need zip file references for two reasons:
a) they were originally added because we didn't have Eclipse-SourceReferences in the MANIFEST.MF files, and needed a way to collect all the upstream sources
b) they have generic names (rather than timestamped/buildID'd) so they're not really useful UNLESS the zips themselves are colocated in the build folder, which we no longer need.
*{color:orange}CLARIFICATION{color}*
As to the included metadata, we need:
* build details (re: the server/VM config, JDK version/paths, etc.), eg., http://download.jboss.org/jbosstools/builds/staging/jbosstools-openshift_...
* build log (only useful when things go wrong and access to Jenkins is slow/impossible, so not strictly REQUIRED, only helpful)
* git revs for upstream sources, eg., http://download.jboss.org/jbosstools/builds/stable/4.1.2.Final.core/2014-...
*{color:blue}STEPS TO REPRO{color}*
In trying to use the above locally, I've realized 3 things:
a) you need to use <version>0.22.1-SNAPSHOT</version> as 0.22.0-SNAPSHOT is no longer available in Nexus or in your fork
b) you need to run a build of something like jbosstools-build-sites/aggregate/site/pom.xml with -DtychoVersion=0.22.0, as repository-utils now depends on on that
c) you need to build with JDK8, or get:
{code}
[ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site (generate-full-site) on project org.jboss.tools.site.core: Execution generate-full-site of goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site failed: An API incompatibility was encountered while executing org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site: java.lang.UnsupportedClassVersionError: org/json/JSONObject : Unsupported major.minor version 52.0
{code}
So, I inserted the above block into jbosstools-build-sites/aggregate/site/pom.xml (and fixed the version to be 0.22.1-SNAPSHOT), then:
{code}
$➔ mvn --version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400)
Maven home: /opt/maven3
Java version: 1.8.0, vendor: Oracle Corporation
Java home: /opt/jdk1.8.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.17.4-200.fc20.x86_64", arch: "amd64", family: "unix"
{code}
{code}
$➔ mvn clean install -DtychoVersion=0.22.0 -DBUILD_ID=666 -DJOB_NAME=jbosstools-build-sites.aggregate.site_master -DHUDSON_SLAVE=dev69 -DRELEASE=no
{code}
Results:
{code:title=aggregate/site/target/fullSite/all/repo/buildInfo.json}{
"upstream": {},
"properties": {
"BUILD_NUMBER": "666",
"RELEASE": "no",
"JOB_NAME": "jbosstools-build-sites.aggregate.site_master",
"HUDSON_SLAVE": "dev69"
},
"timestamp": 1419266314705,
"revision": {
"HEAD": "89898db85f9e38972360c42782247f0e2b7304b0",
"knownReferences": [{
"ref": "JBIDE-18869",
"name": "nickboldt",
"url": "git@github.com:nickboldt/jbosstools-build-sites.git"
}]
}
}{code}
{code:title=aggregate/site/target/fullSite/logs/GIT_REVISION.txt}
#Mon Dec 22 11:21:56 EST 2014
git@github.com\:nickboldt/jbosstools-build-sites.git\:JBIDE-18869=89898db85f9e38972360c42782247f0e2b7304b0
HEAD=89898db85f9e38972360c42782247f0e2b7304b0
{code}
{code:title=aggregate/site/target/fullSite/logs/build.properties}
BUILD_ALIAS=null
JOB_NAME=null
BUILD_NUMBER=null
BUILD_ID=null
HUDSON_SLAVE=null
RELEASE=null
ZIPSUFFIX=null
TARGET_PLATFORM_VERSION=null
TARGET_PLATFORM_VERSION_MAXIMUM=null
{code}
* *{color:red}QUESTION{color}* Should there be something in upstream?
* *{color:red}QUESTION{color}* What about details about the OS & JDK version?
* *{color:red}QUESTION{color}* 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
*{color:red}QUESTION{color}* 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._
* *{color:red}QUESTION{color}* 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?
was (Author: nickboldt):
*{color:orange}CLARIFICATION{color}*
I don't think we need zip file references for two reasons:
a) they were originally added because we didn't have Eclipse-SourceReferences in the MANIFEST.MF files, and needed a way to collect all the upstream sources
b) they have generic names (rather than timestamped/buildID'd) so they're not really useful UNLESS the zips themselves are colocated in the build folder, which we no longer need.
*{color:orange}CLARIFICATION{color}*
As to the included metadata, we need:
* build details (re: the server/VM config, JDK version/paths, etc.), eg., http://download.jboss.org/jbosstools/builds/staging/jbosstools-openshift_...
* build log (only useful when things go wrong and access to Jenkins is slow/impossible, so not strictly REQUIRED, only helpful)
* git revs for upstream sources, eg., http://download.jboss.org/jbosstools/builds/stable/4.1.2.Final.core/2014-...
*{color:orange}STEPS TO REPRO{color}*
In trying to use the above locally, I've realized 3 things:
a) you need to use <version>0.22.1-SNAPSHOT</version> as 0.22.0-SNAPSHOT is no longer available in Nexus or in your fork
b) you need to run a build of something like jbosstools-build-sites/aggregate/site/pom.xml with -DtychoVersion=0.22.0, as repository-utils now depends on on that
c) you need to build with JDK8, or get:
{code}
[ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site (generate-full-site) on project org.jboss.tools.site.core: Execution generate-full-site of goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site failed: An API incompatibility was encountered while executing org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site: java.lang.UnsupportedClassVersionError: org/json/JSONObject : Unsupported major.minor version 52.0
{code}
So, I inserted the above block into jbosstools-build-sites/aggregate/site/pom.xml (and fixed the version to be 0.22.1-SNAPSHOT), then:
{code}
$➔ mvn --version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400)
Maven home: /opt/maven3
Java version: 1.8.0, vendor: Oracle Corporation
Java home: /opt/jdk1.8.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.17.4-200.fc20.x86_64", arch: "amd64", family: "unix"
{code}
{code}
$➔ mvn clean install -DtychoVersion=0.22.0 -DBUILD_ID=666 -DJOB_NAME=jbosstools-build-sites.aggregate.site_master -DHUDSON_SLAVE=dev69 -DRELEASE=no
{code}
Results:
{code:title=aggregate/site/target/fullSite/all/repo/buildInfo.json}{
"upstream": {},
"properties": {
"BUILD_NUMBER": "666",
"RELEASE": "no",
"JOB_NAME": "jbosstools-build-sites.aggregate.site_master",
"HUDSON_SLAVE": "dev69"
},
"timestamp": 1419266314705,
"revision": {
"HEAD": "89898db85f9e38972360c42782247f0e2b7304b0",
"knownReferences": [{
"ref": "JBIDE-18869",
"name": "nickboldt",
"url": "git@github.com:nickboldt/jbosstools-build-sites.git"
}]
}
}{code}
{code:title=aggregate/site/target/fullSite/logs/GIT_REVISION.txt}
#Mon Dec 22 11:21:56 EST 2014
git@github.com\:nickboldt/jbosstools-build-sites.git\:JBIDE-18869=89898db85f9e38972360c42782247f0e2b7304b0
HEAD=89898db85f9e38972360c42782247f0e2b7304b0
{code}
{code:title=aggregate/site/target/fullSite/logs/build.properties}
BUILD_ALIAS=null
JOB_NAME=null
BUILD_NUMBER=null
BUILD_ID=null
HUDSON_SLAVE=null
RELEASE=null
ZIPSUFFIX=null
TARGET_PLATFORM_VERSION=null
TARGET_PLATFORM_VERSION_MAXIMUM=null
{code}
* *{color:red}QUESTION{color}* Should there be something in upstream?
* *{color:red}QUESTION{color}* What about details about the OS & JDK version?
* *{color:red}QUESTION{color}* 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
*{color:red}QUESTION{color}* 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._
* *{color:red}QUESTION{color}* 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?
> 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)
11 years, 3 months
- 1
- 0
[JBoss JIRA] (JBIDE-15135) Attach metadata during assembly instead of publish time
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-15135 at 12/22/14 11:51 AM:
---------------------------------------------------------------
*{color:orange}CLARIFICATION{color}*
I don't think we need zip file references for two reasons:
a) they were originally added because we didn't have Eclipse-SourceReferences in the MANIFEST.MF files, and needed a way to collect all the upstream sources
b) they have generic names (rather than timestamped/buildID'd) so they're not really useful UNLESS the zips themselves are colocated in the build folder, which we no longer need.
*{color:orange}CLARIFICATION{color}*
As to the included metadata, we need:
* build details (re: the server/VM config, JDK version/paths, etc.), eg., http://download.jboss.org/jbosstools/builds/staging/jbosstools-openshift_...
* build log (only useful when things go wrong and access to Jenkins is slow/impossible, so not strictly REQUIRED, only helpful)
* git revs for upstream sources, eg., http://download.jboss.org/jbosstools/builds/stable/4.1.2.Final.core/2014-...
*{color:blue}STEPS TO REPRO{color}*
In trying to use the above locally, I've realized 3 things:
a) you need to use <version>0.22.1-SNAPSHOT</version> as 0.22.0-SNAPSHOT is no longer available in Nexus or in your fork
b) you need to run a build of something like jbosstools-build-sites/aggregate/site/pom.xml with -DtychoVersion=0.22.0, as repository-utils now depends on on that
c) you need to build with JDK8, or get:
{code}
[ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site (generate-full-site) on project org.jboss.tools.site.core: Execution generate-full-site of goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site failed: An API incompatibility was encountered while executing org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site: java.lang.UnsupportedClassVersionError: org/json/JSONObject : Unsupported major.minor version 52.0
{code}
So, I inserted the above block into jbosstools-build-sites/aggregate/site/pom.xml (and fixed the version to be 0.22.1-SNAPSHOT), then:
{code}
$➔ mvn --version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400)
Maven home: /opt/maven3
Java version: 1.8.0, vendor: Oracle Corporation
Java home: /opt/jdk1.8.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.17.4-200.fc20.x86_64", arch: "amd64", family: "unix"
{code}
{code}
$➔ mvn clean install -DtychoVersion=0.22.0 -DBUILD_ID=666 -DJOB_NAME=jbosstools-build-sites.aggregate.site_master -DHUDSON_SLAVE=dev69 -DRELEASE=no
{code}
Results:
{code:title=aggregate/site/target/fullSite/all/repo/buildInfo.json}{
"upstream": {},
"properties": {
"BUILD_NUMBER": "666",
"RELEASE": "no",
"JOB_NAME": "jbosstools-build-sites.aggregate.site_master",
"HUDSON_SLAVE": "dev69"
},
"timestamp": 1419266314705,
"revision": {
"HEAD": "89898db85f9e38972360c42782247f0e2b7304b0",
"knownReferences": [{
"ref": "JBIDE-18869",
"name": "nickboldt",
"url": "git@github.com:nickboldt/jbosstools-build-sites.git"
}]
}
}{code}
{code:title=aggregate/site/target/fullSite/logs/GIT_REVISION.txt}
#Mon Dec 22 11:21:56 EST 2014
git@github.com\:nickboldt/jbosstools-build-sites.git\:JBIDE-18869=89898db85f9e38972360c42782247f0e2b7304b0
HEAD=89898db85f9e38972360c42782247f0e2b7304b0
{code}
{code:title=aggregate/site/target/fullSite/logs/build.properties}
BUILD_ALIAS=null
JOB_NAME=null
BUILD_NUMBER=null
BUILD_ID=null
HUDSON_SLAVE=null
RELEASE=null
ZIPSUFFIX=null
TARGET_PLATFORM_VERSION=null
TARGET_PLATFORM_VERSION_MAXIMUM=null
{code}
* *{color:red}QUESTION{color}* Should there be something in upstream?
* *{color:red}QUESTION{color}* What about details about the OS & JDK version?
* *{color:red}QUESTION{color}* 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
* *{color:red}QUESTION{color}* 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._
* *{color:red}QUESTION{color}* 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?
was (Author: nickboldt):
*{color:orange}CLARIFICATION{color}*
I don't think we need zip file references for two reasons:
a) they were originally added because we didn't have Eclipse-SourceReferences in the MANIFEST.MF files, and needed a way to collect all the upstream sources
b) they have generic names (rather than timestamped/buildID'd) so they're not really useful UNLESS the zips themselves are colocated in the build folder, which we no longer need.
*{color:orange}CLARIFICATION{color}*
As to the included metadata, we need:
* build details (re: the server/VM config, JDK version/paths, etc.), eg., http://download.jboss.org/jbosstools/builds/staging/jbosstools-openshift_...
* build log (only useful when things go wrong and access to Jenkins is slow/impossible, so not strictly REQUIRED, only helpful)
* git revs for upstream sources, eg., http://download.jboss.org/jbosstools/builds/stable/4.1.2.Final.core/2014-...
*{color:blue}STEPS TO REPRO{color}*
In trying to use the above locally, I've realized 3 things:
a) you need to use <version>0.22.1-SNAPSHOT</version> as 0.22.0-SNAPSHOT is no longer available in Nexus or in your fork
b) you need to run a build of something like jbosstools-build-sites/aggregate/site/pom.xml with -DtychoVersion=0.22.0, as repository-utils now depends on on that
c) you need to build with JDK8, or get:
{code}
[ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site (generate-full-site) on project org.jboss.tools.site.core: Execution generate-full-site of goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site failed: An API incompatibility was encountered while executing org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site: java.lang.UnsupportedClassVersionError: org/json/JSONObject : Unsupported major.minor version 52.0
{code}
So, I inserted the above block into jbosstools-build-sites/aggregate/site/pom.xml (and fixed the version to be 0.22.1-SNAPSHOT), then:
{code}
$➔ mvn --version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400)
Maven home: /opt/maven3
Java version: 1.8.0, vendor: Oracle Corporation
Java home: /opt/jdk1.8.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.17.4-200.fc20.x86_64", arch: "amd64", family: "unix"
{code}
{code}
$➔ mvn clean install -DtychoVersion=0.22.0 -DBUILD_ID=666 -DJOB_NAME=jbosstools-build-sites.aggregate.site_master -DHUDSON_SLAVE=dev69 -DRELEASE=no
{code}
Results:
{code:title=aggregate/site/target/fullSite/all/repo/buildInfo.json}{
"upstream": {},
"properties": {
"BUILD_NUMBER": "666",
"RELEASE": "no",
"JOB_NAME": "jbosstools-build-sites.aggregate.site_master",
"HUDSON_SLAVE": "dev69"
},
"timestamp": 1419266314705,
"revision": {
"HEAD": "89898db85f9e38972360c42782247f0e2b7304b0",
"knownReferences": [{
"ref": "JBIDE-18869",
"name": "nickboldt",
"url": "git@github.com:nickboldt/jbosstools-build-sites.git"
}]
}
}{code}
{code:title=aggregate/site/target/fullSite/logs/GIT_REVISION.txt}
#Mon Dec 22 11:21:56 EST 2014
git@github.com\:nickboldt/jbosstools-build-sites.git\:JBIDE-18869=89898db85f9e38972360c42782247f0e2b7304b0
HEAD=89898db85f9e38972360c42782247f0e2b7304b0
{code}
{code:title=aggregate/site/target/fullSite/logs/build.properties}
BUILD_ALIAS=null
JOB_NAME=null
BUILD_NUMBER=null
BUILD_ID=null
HUDSON_SLAVE=null
RELEASE=null
ZIPSUFFIX=null
TARGET_PLATFORM_VERSION=null
TARGET_PLATFORM_VERSION_MAXIMUM=null
{code}
* *{color:red}QUESTION{color}* Should there be something in upstream?
* *{color:red}QUESTION{color}* What about details about the OS & JDK version?
* *{color:red}QUESTION{color}* 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
*{color:red}QUESTION{color}* 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._
* *{color:red}QUESTION{color}* 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?
> 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)
11 years, 3 months
- 1
- 0
[JBoss JIRA] (JBIDE-15135) Attach metadata during assembly instead of publish time
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-15135 at 12/22/14 11:50 AM:
---------------------------------------------------------------
*{color:orange}CLARIFICATION{color}*
I don't think we need zip file references for two reasons:
a) they were originally added because we didn't have Eclipse-SourceReferences in the MANIFEST.MF files, and needed a way to collect all the upstream sources
b) they have generic names (rather than timestamped/buildID'd) so they're not really useful UNLESS the zips themselves are colocated in the build folder, which we no longer need.
*{color:orange}CLARIFICATION{color}*
As to the included metadata, we need:
* build details (re: the server/VM config, JDK version/paths, etc.), eg., http://download.jboss.org/jbosstools/builds/staging/jbosstools-openshift_...
* build log (only useful when things go wrong and access to Jenkins is slow/impossible, so not strictly REQUIRED, only helpful)
* git revs for upstream sources, eg., http://download.jboss.org/jbosstools/builds/stable/4.1.2.Final.core/2014-...
*{color:orange}STEPS TO REPRO{color}*
In trying to use the above locally, I've realized 3 things:
a) you need to use <version>0.22.1-SNAPSHOT</version> as 0.22.0-SNAPSHOT is no longer available in Nexus or in your fork
b) you need to run a build of something like jbosstools-build-sites/aggregate/site/pom.xml with -DtychoVersion=0.22.0, as repository-utils now depends on on that
c) you need to build with JDK8, or get:
{code}
[ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site (generate-full-site) on project org.jboss.tools.site.core: Execution generate-full-site of goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site failed: An API incompatibility was encountered while executing org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site: java.lang.UnsupportedClassVersionError: org/json/JSONObject : Unsupported major.minor version 52.0
{code}
So, I inserted the above block into jbosstools-build-sites/aggregate/site/pom.xml (and fixed the version to be 0.22.1-SNAPSHOT), then:
{code}
$➔ mvn --version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400)
Maven home: /opt/maven3
Java version: 1.8.0, vendor: Oracle Corporation
Java home: /opt/jdk1.8.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.17.4-200.fc20.x86_64", arch: "amd64", family: "unix"
{code}
{code}
$➔ mvn clean install -DtychoVersion=0.22.0 -DBUILD_ID=666 -DJOB_NAME=jbosstools-build-sites.aggregate.site_master -DHUDSON_SLAVE=dev69 -DRELEASE=no
{code}
Results:
{code:title=aggregate/site/target/fullSite/all/repo/buildInfo.json}{
"upstream": {},
"properties": {
"BUILD_NUMBER": "666",
"RELEASE": "no",
"JOB_NAME": "jbosstools-build-sites.aggregate.site_master",
"HUDSON_SLAVE": "dev69"
},
"timestamp": 1419266314705,
"revision": {
"HEAD": "89898db85f9e38972360c42782247f0e2b7304b0",
"knownReferences": [{
"ref": "JBIDE-18869",
"name": "nickboldt",
"url": "git@github.com:nickboldt/jbosstools-build-sites.git"
}]
}
}{code}
{code:title=aggregate/site/target/fullSite/logs/GIT_REVISION.txt}
#Mon Dec 22 11:21:56 EST 2014
git@github.com\:nickboldt/jbosstools-build-sites.git\:JBIDE-18869=89898db85f9e38972360c42782247f0e2b7304b0
HEAD=89898db85f9e38972360c42782247f0e2b7304b0
{code}
{code:title=aggregate/site/target/fullSite/logs/build.properties}
BUILD_ALIAS=null
JOB_NAME=null
BUILD_NUMBER=null
BUILD_ID=null
HUDSON_SLAVE=null
RELEASE=null
ZIPSUFFIX=null
TARGET_PLATFORM_VERSION=null
TARGET_PLATFORM_VERSION_MAXIMUM=null
{code}
* *{color:red}QUESTION{color}* Should there be something in upstream?
* *{color:red}QUESTION{color}* What about details about the OS & JDK version?
* *{color:red}QUESTION{color}* 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
*{color:red}QUESTION{color}* 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._
* *{color:red}QUESTION{color}* 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?
was (Author: nickboldt):
I don't think we need zip file references for two reasons:
a) they were originally added because we didn't have Eclipse-SourceReferences in the MANIFEST.MF files, and needed a way to collect all the upstream sources
b) they have generic names (rather than timestamped/buildID'd) so they're not really useful UNLESS the zips themselves are colocated in the build folder, which we no longer need.
As to the included metadata, we need:
* build details (re: the server/VM config, JDK version/paths, etc.), eg., http://download.jboss.org/jbosstools/builds/staging/jbosstools-openshift_...
* build log (only useful when things go wrong and access to Jenkins is slow/impossible, so not strictly REQUIRED, only helpful)
* git revs for upstream sources, eg., http://download.jboss.org/jbosstools/builds/stable/4.1.2.Final.core/2014-...
In trying to use the above locally, I've realized 3 things:
a) you need to use <version>0.22.1-SNAPSHOT</version> as 0.22.0-SNAPSHOT is no longer available in Nexus or in your fork
b) you need to run a build of something like jbosstools-build-sites/aggregate/site/pom.xml with -DtychoVersion=0.22.0, as repository-utils now depends on on that
c) you need to build with JDK8, or get:
{code}
[ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site (generate-full-site) on project org.jboss.tools.site.core: Execution generate-full-site of goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site failed: An API incompatibility was encountered while executing org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site: java.lang.UnsupportedClassVersionError: org/json/JSONObject : Unsupported major.minor version 52.0
{code}
So, I inserted the above block into jbosstools-build-sites/aggregate/site/pom.xml (and fixed the version to be 0.22.1-SNAPSHOT), then:
{code}
$➔ mvn --version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400)
Maven home: /opt/maven3
Java version: 1.8.0, vendor: Oracle Corporation
Java home: /opt/jdk1.8.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.17.4-200.fc20.x86_64", arch: "amd64", family: "unix"
{code}
{code}
$➔ mvn clean install -DtychoVersion=0.22.0 -DBUILD_ID=666 -DJOB_NAME=jbosstools-build-sites.aggregate.site_master -DHUDSON_SLAVE=dev69 -DRELEASE=no
{code}
Results:
{code:title=aggregate/site/target/fullSite/all/repo/buildInfo.json}{
"upstream": {},
"properties": {
"BUILD_NUMBER": "666",
"RELEASE": "no",
"JOB_NAME": "jbosstools-build-sites.aggregate.site_master",
"HUDSON_SLAVE": "dev69"
},
"timestamp": 1419266314705,
"revision": {
"HEAD": "89898db85f9e38972360c42782247f0e2b7304b0",
"knownReferences": [{
"ref": "JBIDE-18869",
"name": "nickboldt",
"url": "git@github.com:nickboldt/jbosstools-build-sites.git"
}]
}
}{code}
Should there be something in upstream?
What about details about the OS & JDK version?
{code:title=aggregate/site/target/fullSite/logs/GIT_REVISION.txt}
#Mon Dec 22 11:21:56 EST 2014
git@github.com\:nickboldt/jbosstools-build-sites.git\:JBIDE-18869=89898db85f9e38972360c42782247f0e2b7304b0
HEAD=89898db85f9e38972360c42782247f0e2b7304b0
{code}
{code:title=aggregate/site/target/fullSite/logs/build.properties}
BUILD_ALIAS=null
JOB_NAME=null
BUILD_NUMBER=null
BUILD_ID=null
HUDSON_SLAVE=null
RELEASE=null
ZIPSUFFIX=null
TARGET_PLATFORM_VERSION=null
TARGET_PLATFORM_VERSION_MAXIMUM=null
{code}
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
Also, I don't see *WORKSPACE* being resolved to a path - 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.
Can you also generate an ALL_VERSIONS.txt for aggregate builds? Or does that 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?
> 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)
11 years, 3 months
- 1
- 0
[JBoss JIRA] (JBIDE-15135) Attach metadata during assembly instead of publish time
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-15135 at 12/22/14 11:46 AM:
---------------------------------------------------------------
I don't think we need zip file references for two reasons:
a) they were originally added because we didn't have Eclipse-SourceReferences in the MANIFEST.MF files, and needed a way to collect all the upstream sources
b) they have generic names (rather than timestamped/buildID'd) so they're not really useful UNLESS the zips themselves are colocated in the build folder, which we no longer need.
As to the included metadata, we need:
* build details (re: the server/VM config, JDK version/paths, etc.), eg., http://download.jboss.org/jbosstools/builds/staging/jbosstools-openshift_...
* build log (only useful when things go wrong and access to Jenkins is slow/impossible, so not strictly REQUIRED, only helpful)
* git revs for upstream sources, eg., http://download.jboss.org/jbosstools/builds/stable/4.1.2.Final.core/2014-...
In trying to use the above locally, I've realized 3 things:
a) you need to use <version>0.22.1-SNAPSHOT</version> as 0.22.0-SNAPSHOT is no longer available in Nexus or in your fork
b) you need to run a build of something like jbosstools-build-sites/aggregate/site/pom.xml with -DtychoVersion=0.22.0, as repository-utils now depends on on that
c) you need to build with JDK8, or get:
{code}
[ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site (generate-full-site) on project org.jboss.tools.site.core: Execution generate-full-site of goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site failed: An API incompatibility was encountered while executing org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site: java.lang.UnsupportedClassVersionError: org/json/JSONObject : Unsupported major.minor version 52.0
{code}
So, I inserted the above block into jbosstools-build-sites/aggregate/site/pom.xml (and fixed the version to be 0.22.1-SNAPSHOT), then:
{code}
$➔ mvn --version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400)
Maven home: /opt/maven3
Java version: 1.8.0, vendor: Oracle Corporation
Java home: /opt/jdk1.8.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.17.4-200.fc20.x86_64", arch: "amd64", family: "unix"
{code}
{code}
$➔ mvn clean install -DtychoVersion=0.22.0 -DBUILD_ID=666 -DJOB_NAME=jbosstools-build-sites.aggregate.site_master -DHUDSON_SLAVE=dev69 -DRELEASE=no
{code}
Results:
{code:title=aggregate/site/target/fullSite/all/repo/buildInfo.json}{
"upstream": {},
"properties": {
"BUILD_NUMBER": "666",
"RELEASE": "no",
"JOB_NAME": "jbosstools-build-sites.aggregate.site_master",
"HUDSON_SLAVE": "dev69"
},
"timestamp": 1419266314705,
"revision": {
"HEAD": "89898db85f9e38972360c42782247f0e2b7304b0",
"knownReferences": [{
"ref": "JBIDE-18869",
"name": "nickboldt",
"url": "git@github.com:nickboldt/jbosstools-build-sites.git"
}]
}
}{code}
Should there be something in upstream?
What about details about the OS & JDK version?
{code:title=aggregate/site/target/fullSite/logs/GIT_REVISION.txt}
#Mon Dec 22 11:21:56 EST 2014
git@github.com\:nickboldt/jbosstools-build-sites.git\:JBIDE-18869=89898db85f9e38972360c42782247f0e2b7304b0
HEAD=89898db85f9e38972360c42782247f0e2b7304b0
{code}
{code:title=aggregate/site/target/fullSite/logs/build.properties}
BUILD_ALIAS=null
JOB_NAME=null
BUILD_NUMBER=null
BUILD_ID=null
HUDSON_SLAVE=null
RELEASE=null
ZIPSUFFIX=null
TARGET_PLATFORM_VERSION=null
TARGET_PLATFORM_VERSION_MAXIMUM=null
{code}
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
Also, I don't see *WORKSPACE* being resolved to a path - 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.
Can you also generate an ALL_VERSIONS.txt for aggregate builds? Or does that 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?
was (Author: nickboldt):
I don't think we need zip file references for two reasons:
a) they were originally added because we didn't have Eclipse-SourceReferences in the MANIFEST.MF files, and needed a way to collect all the upstream sources
b) they have generic names (rather than timestamped/buildID'd) so they're not really useful UNLESS the zips themselves are colocated in the build folder, which we no longer need.
As to the included metadata, we need:
* build details (re: the server/VM config, JDK version/paths, etc.), eg., http://download.jboss.org/jbosstools/builds/staging/jbosstools-openshift_...
* build log (only useful when things go wrong and access to Jenkins is slow/impossible, so not strictly REQUIRED, only helpful)
* git revs for upstream sources, eg., http://download.jboss.org/jbosstools/builds/stable/4.1.2.Final.core/2014-...
In trying to use the above locally, I've realized 3 things:
a) you need to use <version>0.22.1-SNAPSHOT</version> as 0.22.0-SNAPSHOT is no longer available in Nexus or in your fork
b) you need to run a build of something like jbosstools-build-sites/aggregate/site/pom.xml with -DtychoVersion=0.22.0, as repository-utils now depends on on that
c) you need to build with JDK8, or get:
{code}
[ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site (generate-full-site) on project org.jboss.tools.site.core: Execution generate-full-site of goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site failed: An API incompatibility was encountered while executing org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site: java.lang.UnsupportedClassVersionError: org/json/JSONObject : Unsupported major.minor version 52.0
{code}
So, I inserted the above block into jbosstools-build-sites/aggregate/site/pom.xml (and fixed the version to be 0.22.1-SNAPSHOT), then:
{code}
$➔ mvn --version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400)
Maven home: /opt/maven3
Java version: 1.8.0, vendor: Oracle Corporation
Java home: /opt/jdk1.8.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.17.4-200.fc20.x86_64", arch: "amd64", family: "unix"
$➔ mvn clean install -DtychoVersion=0.22.0{code}
Results:
{code:title=aggregate/site/target/fullSite/all/repo/buildInfo.json}
{
"upstream": {},
"properties": {},
"timestamp": 1419265316379,
"revision": {
"HEAD": "89898db85f9e38972360c42782247f0e2b7304b0",
"knownReferences": [{
"ref": "JBIDE-18869",
"name": "nickboldt",
"url": "git@github.com:nickboldt/jbosstools-build-sites.git"
}]
}
}
{code}
Should there be something in upstream and properties?
What about details about the OS & JDK version?
> 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)
11 years, 3 months
- 1
- 0
[JBoss JIRA] (JBIDE-18983) Project cannot be built. Possible open file handle
by Cody Lerum (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18983?page=com.atlassian.jira.plugi... ]
Cody Lerum commented on JBIDE-18983:
------------------------------------
Cleaning the project or doing a maven-update in eclipse rarely if ever works. I am forced to restart eclipse to rebuild.
> Project cannot be built. Possible open file handle
> --------------------------------------------------
>
> Key: JBIDE-18983
> URL: https://issues.jboss.org/browse/JBIDE-18983
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Affects Versions: 4.2.1.Final
> Environment: luna x64 windows 8.1 x64
> java 8u25 x64
> Reporter: Cody Lerum
>
> Frequently when working in a Java EE7 project I will get an error like.
> "The project was not built due to "Could not delete '/gp-server/target/classes/META-INF`.". Fix the problem, then try refreshing this project and building since it may be inconsistent.
> I've looked into a process explorer in windows and then this case is happening there is always a javaw.exe process with a file handle to "V:\workspace\gp-server\target\classes\META-INF\persistence.xml
> It looks like either jboss tools or eclipse is holding on to a file handle for this.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
- 1
- 0
[JBoss JIRA] (JBIDE-18983) Project cannot be built. Possible open file handle
by Cody Lerum (JIRA)
Cody Lerum created JBIDE-18983:
----------------------------------
Summary: Project cannot be built. Possible open file handle
Key: JBIDE-18983
URL: https://issues.jboss.org/browse/JBIDE-18983
Project: Tools (JBoss Tools)
Issue Type: Bug
Affects Versions: 4.2.1.Final
Environment: luna x64 windows 8.1 x64
java 8u25 x64
Reporter: Cody Lerum
Frequently when working in a Java EE7 project I will get an error like.
"The project was not built due to "Could not delete '/gp-server/target/classes/META-INF`.". Fix the problem, then try refreshing this project and building since it may be inconsistent.
I've looked into a process explorer in windows and then this case is happening there is always a javaw.exe process with a file handle to "V:\workspace\gp-server\target\classes\META-INF\persistence.xml
It looks like either jboss tools or eclipse is holding on to a file handle for this.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
- 1
- 0
[JBoss JIRA] (JBIDE-15135) Attach metadata during assembly instead of publish time
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-15135:
------------------------------------
I don't think we need zip file references for two reasons:
a) they were originally added because we didn't have Eclipse-SourceReferences in the MANIFEST.MF files, and needed a way to collect all the upstream sources
b) they have generic names (rather than timestamped/buildID'd) so they're not really useful UNLESS the zips themselves are colocated in the build folder, which we no longer need.
As to the included metadata, we need:
* build details (re: the server/VM config, JDK version/paths, etc.), eg., http://download.jboss.org/jbosstools/builds/staging/jbosstools-openshift_...
* build log (only useful when things go wrong and access to Jenkins is slow/impossible, so not strictly REQUIRED, only helpful)
* git revs for upstream sources, eg., http://download.jboss.org/jbosstools/builds/stable/4.1.2.Final.core/2014-...
In trying to use the above locally, I've realized 3 things:
a) you need to use <version>0.22.1-SNAPSHOT</version> as 0.22.0-SNAPSHOT is no longer available in Nexus or in your fork
b) you need to run a build of something like jbosstools-build-sites/aggregate/site/pom.xml with -DtychoVersion=0.22.0, as repository-utils now depends on on that
c) you need to build with JDK8, or get:
{code}
[ERROR] Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site (generate-full-site) on project org.jboss.tools.site.core: Execution generate-full-site of goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site failed: An API incompatibility was encountered while executing org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:create-full-site: java.lang.UnsupportedClassVersionError: org/json/JSONObject : Unsupported major.minor version 52.0
{code}
So, I inserted the above block into jbosstools-build-sites/aggregate/site/pom.xml (and fixed the version to be 0.22.1-SNAPSHOT), then:
{code}
$➔ mvn --version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400)
Maven home: /opt/maven3
Java version: 1.8.0, vendor: Oracle Corporation
Java home: /opt/jdk1.8.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.17.4-200.fc20.x86_64", arch: "amd64", family: "unix"
$➔ mvn clean install -DtychoVersion=0.22.0{code}
Results:
{code:title=aggregate/site/target/fullSite/all/repo/buildInfo.json}
{
"upstream": {},
"properties": {},
"timestamp": 1419265316379,
"revision": {
"HEAD": "89898db85f9e38972360c42782247f0e2b7304b0",
"knownReferences": [{
"ref": "JBIDE-18869",
"name": "nickboldt",
"url": "git@github.com:nickboldt/jbosstools-build-sites.git"
}]
}
}
{code}
Should there be something in upstream and properties?
What about details about the OS & JDK version?
> 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)
11 years, 3 months
- 1
- 0