[JBoss JIRA] (JBIDE-13671) parent pom should use last-mod-timestamp from git for a plugin/feature instead of current timestamp when building
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13671?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-13671 at 3/11/13 9:58 AM:
-------------------------------------------------------------
[~mickael_istria] Good point. We'd have to implement an override in the JBDS root pom that would turn off jgit timestamp provider.
As to the question about correlated sentences, my proposal was to do *these 4 things together*:
a) profile for Jenkins needs to be updated to use "-CI" instead of "-B$\{BUILD_NUMBER\}"
b) profile for Jenkins uses jgit timestamp provider
c) default profile omits the "-CI" and "-Bxxxx" suffix, as it does today
d) default profile uses the default timestamp provider, as it does today
I thought that was obvious from the PR, but I guess not.
https://github.com/jbosstools/jbosstools-build/pull/73
Perhaps instead of talking about how to code, we could just review PRs, and run some tests?
was (Author: nickboldt):
[~mickael_istria] Good point. We'd have to implement an override in the JBDS root pom that would turn off jgit timestamp provider.
As to the question about correlated sentences, my proposal was to do *these 4 things together*:
a) profile for Jenkins needs to be updated to use "-CI" instead of "-B${BUILD_NUMBER}"
b) profile for Jenkins uses jgit timestamp provider
c) default profile omits the "-CI" and "-Bxxxx" suffix, as it does today
d) default profile uses the default timestamp provider, as it does today
I thought that was obvious from the PR, but I guess not.
https://github.com/jbosstools/jbosstools-build/pull/73
Perhaps instead of talking about how to code, we could just review PRs, and run some tests?
> parent pom should use last-mod-timestamp from git for a plugin/feature instead of current timestamp when building
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-13671
> URL: https://issues.jboss.org/browse/JBIDE-13671
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.1.x
>
> Attachments: jbide13671-before-and-after.png
>
>
> This needs to be added to master parent pom:
> {code}
> <plugin>
> <groupId>org.eclipse.tycho</groupId>
> <artifactId>tycho-packaging-plugin</artifactId>
> <version>${tycho.version}</version>
> <dependencies>
> <dependency>
> <groupId>org.eclipse.tycho.extras</groupId>
> <artifactId>tycho-buildtimestamp-jgit</artifactId>
> <version>${tycho-extras.version}</version>
> </dependency>
> </dependencies>
> <configuration>
> <strictBinIncludes>false</strictBinIncludes>
> <format>'v'yyyyMMdd-HHmm</format>
> <timestampProvider>jgit</timestampProvider>
> <jgit.ignore>
> </jgit.ignore>
> </configuration>
> </plugin>
> {code}
> Ref: http://pweclipse.blogspot.ch/2012_09_01_archive.html
--
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
13 years, 1 month
[JBoss JIRA] (JBIDE-13408) investigate using mvn deploy of non-SNAPSHOT target platforms to JBoss Public Nexus
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13408?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-13408:
------------------------------------
So you want to introduce a "mandatory waiting period" between ['new TP available' announcement in mailing list] and [update jobs to point explicitly to new version] during which time all devs will magically find time to run their local builds w/ the -DTARGET_PLATFORM_VERSION=<new version>.
How will we enforce that everyone has done that? Will we expect signoffs? Or just wait x days before changing the jobs, assuming that after x days any problems will have been reported?
> investigate using mvn deploy of non-SNAPSHOT target platforms to JBoss Public Nexus
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-13408
> URL: https://issues.jboss.org/browse/JBIDE-13408
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: target-platform
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Mickael Istria
> Priority: Blocker
> Fix For: 4.1.0.Alpha2
>
>
> investigate using `mvn deploy` from Jenkins CI job of non-SNAPSHOT target platforms to JBoss Public Nexus so that we can have *final* versions rather than ongoing snapshots.
> Last time I attempted to deploy something without a -SNAPSHOT suffix in its version, I got this error:
> {quote}
> {code:title=https://github.com/nickboldt/jbosstools-target-platforms/tree/d14d79e71d62b77f73d19d96e6bb1a03db90d5f1}
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project multiple: Failed to deploy artifacts: Could not transfer artifact org.jboss.tools.target-platforms.jbdevstudio:multiple:pom:4.21.3.Final from/to jboss-releases-repository (https://repository.jboss.org/nexus/content/repositories/releases/): Failed to transfer file: https://repository.jboss.org/nexus/content/repositories/releases/org/jbos.... Return code is: 502, ReasonPhrase:Proxy Error. -> [Help 1]
> {code}
> {quote}
--
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
13 years, 1 month
[JBoss JIRA] (JBIDE-13159) gwt-kitchensink fails to deploy - class not found
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13159?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-13159:
---------------------------------------
I'd like to add, that using mvn clean package still works correctly. So it is only "mvn package" alone (as described in the readme) that causes the problem.
> gwt-kitchensink fails to deploy - class not found
> -------------------------------------------------
>
> Key: JBIDE-13159
> URL: https://issues.jboss.org/browse/JBIDE-13159
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: GWT, maven
> Affects Versions: 4.0.0.CR1
> Environment: JBDS 6.0.0.CR1a B133
> JBT 4.0.0.CR1a B97
> OS X 10.8.2
> Oracle Java 1.7
> Reporter: Martin Malina
> Assignee: Snjezana Peco
> Fix For: 4.0.1.Final
>
>
> When you try to deploy the gwt project from Central, it fails to deploy with the following error:
> {code}
> 15:27:18,698 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015003: Found jboss-gwt-webapp.war in deployment directory. To trigger deployment create a file called jboss-gwt-webapp.war.dodeploy
> 15:27:18,713 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "jboss-gwt-webapp.war"
> 15:27:20,830 INFO [org.jboss.as.jpa] (MSC service thread 1-3) JBAS011401: Read persistence.xml for primary
> 15:27:20,978 WARN [org.jboss.as.dependency.private] (MSC service thread 1-3) JBAS018567: Deployment "deployment.jboss-gwt-webapp.war" is using a private module ("org.jboss.as.naming:main") which may be changed or removed in future versions without notice.
> 15:27:20,979 WARN [org.jboss.as.dependency.private] (MSC service thread 1-3) JBAS018567: Deployment "deployment.jboss-gwt-webapp.war" is using a private module ("org.jboss.as.server:main") which may be changed or removed in future versions without notice.
> 15:27:21,021 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) JBAS016002: Processing weld deployment jboss-gwt-webapp.war
> 15:27:21,301 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016005: Starting Services for CDI deployment: jboss-gwt-webapp.war
> 15:27:21,332 INFO [org.jboss.weld.Version] (MSC service thread 1-2) WELD-000900 1.1.5 (AS71)
> 15:27:21,364 INFO [org.jboss.as.jpa] (MSC service thread 1-1) JBAS011402: Starting Persistence Unit Service 'jboss-gwt-webapp.war#primary'
> 15:27:21,461 INFO [org.hibernate.annotations.common.Version] (MSC service thread 1-1) HCANN000001: Hibernate Commons Annotations {4.0.1.Final}
> 15:27:21,467 INFO [org.hibernate.Version] (MSC service thread 1-1) HHH000412: Hibernate Core {4.0.1.Final}
> 15:27:21,469 INFO [org.hibernate.cfg.Environment] (MSC service thread 1-1) HHH000206: hibernate.properties not found
> 15:27:21,473 INFO [org.hibernate.cfg.Environment] (MSC service thread 1-1) HHH000021: Bytecode provider name : javassist
> 15:27:21,490 INFO [org.hibernate.ejb.Ejb3Configuration] (MSC service thread 1-1) HHH000204: Processing PersistenceUnitInfo [
> name: primary
> ...]
> 15:27:21,499 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.persistenceunit."jboss-gwt-webapp.war#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."jboss-gwt-webapp.war#primary": Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07]
> Caused by: java.lang.RuntimeException: error trying to scan <jar-file>: vfs:/Users/rasp/jbossqa/runtimes/jboss-as-7.1.1.Final/standalone/deployments/jboss-gwt-webapp.war/WEB-INF/classes/
> at org.hibernate.ejb.Ejb3Configuration.scanForClasses(Ejb3Configuration.java:854)
> at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:596)
> at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:72)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.createContainerEntityManagerFactory(PersistenceUnitServiceImpl.java:162)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.start(PersistenceUnitServiceImpl.java:85)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> ... 3 more
> Caused by: java.lang.RuntimeException: JBAS011431: Could not load entity class 'org.jboss.errai.marshalling.server.impl.ServerMarshallingFactoryImpl$30' with PersistenceUnitInfo.getClassLoader()
> at org.jboss.as.jpa.hibernate4.HibernateAnnotationScanner.getPackagesInJar(HibernateAnnotationScanner.java:175)
> at org.hibernate.ejb.Ejb3Configuration.addScannedEntries(Ejb3Configuration.java:489)
> at org.hibernate.ejb.Ejb3Configuration.scanForClasses(Ejb3Configuration.java:851)
> ... 9 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.errai.marshalling.server.impl.ServerMarshallingFactoryImpl$30 from [Module "deployment.jboss-gwt-webapp.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
> at org.jboss.as.jpa.hibernate4.HibernateAnnotationScanner.getPackagesInJar(HibernateAnnotationScanner.java:171)
> ... 11 more
> 15:27:21,714 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment "jboss-gwt-webapp.war" was rolled back with failure message {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jboss-gwt-webapp.war#primary\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jboss-gwt-webapp.war#primary\": Failed to start service"}}
> 15:27:21,742 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment jboss-gwt-webapp.war in 27ms
> 15:27:21,743 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) JBAS014774: Service status report
> JBAS014777: Services which failed to start: service jboss.persistenceunit."jboss-gwt-webapp.war#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."jboss-gwt-webapp.war#primary": Failed to start service
> 15:27:21,745 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jboss-gwt-webapp.war#primary\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jboss-gwt-webapp.war#primary\": Failed to start service"}}}}
> {code}
--
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
13 years, 1 month
[JBoss JIRA] (JBIDE-13690) Detect future EAP 6 based server like SOA-P
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13690?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-13690:
---------------------------------------
ok, I will check again with the next build - I'm pretty sure the fix is not included in the current CR1 build.
> Detect future EAP 6 based server like SOA-P
> -------------------------------------------
>
> Key: JBIDE-13690
> URL: https://issues.jboss.org/browse/JBIDE-13690
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: JBossAS/Servers, runtime-detection
> Reporter: Max Rydahl Andersen
> Assignee: Len DiMaggio
> Priority: Blocker
> Labels: new_and_noteworthy, respin-a
> Fix For: 4.0.1.Final, 4.1.0.Alpha2
>
>
> To be sure future AS7/EAP 6 based servers such as SOA-P 6 can be detected and started as an EAP 6 we need to provide a fallback for this instead of the currrent hardcoding of eap slots.
--
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
13 years, 1 month
[JBoss JIRA] (JBIDE-13690) Detect future EAP 6 based server like SOA-P
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13690?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-13690:
---------------------------------------------
[~mmalina] it should be detected according to what is in the manifest.mf inside that wonka "slot" .
Thus if you copied the content verbatim from eap 6.1 it should be picked up as such.
> Detect future EAP 6 based server like SOA-P
> -------------------------------------------
>
> Key: JBIDE-13690
> URL: https://issues.jboss.org/browse/JBIDE-13690
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: JBossAS/Servers, runtime-detection
> Reporter: Max Rydahl Andersen
> Assignee: Len DiMaggio
> Priority: Blocker
> Labels: new_and_noteworthy, respin-a
> Fix For: 4.0.1.Final, 4.1.0.Alpha2
>
>
> To be sure future AS7/EAP 6 based servers such as SOA-P 6 can be detected and started as an EAP 6 we need to provide a fallback for this instead of the currrent hardcoding of eap slots.
--
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
13 years, 1 month
[JBoss JIRA] (JBIDE-13408) investigate using mvn deploy of non-SNAPSHOT target platforms to JBoss Public Nexus
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13408?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-13408:
---------------------------------------------
[~nickboldt] i'm not so much concerned about the build being slow in this context - i'm concerned about why the CI builds are being used with the target platform before local testing is/have been done. i.e. to avoid more build failures.
> investigate using mvn deploy of non-SNAPSHOT target platforms to JBoss Public Nexus
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-13408
> URL: https://issues.jboss.org/browse/JBIDE-13408
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: target-platform
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Mickael Istria
> Priority: Blocker
> Fix For: 4.1.0.Alpha2
>
>
> investigate using `mvn deploy` from Jenkins CI job of non-SNAPSHOT target platforms to JBoss Public Nexus so that we can have *final* versions rather than ongoing snapshots.
> Last time I attempted to deploy something without a -SNAPSHOT suffix in its version, I got this error:
> {quote}
> {code:title=https://github.com/nickboldt/jbosstools-target-platforms/tree/d14d79e71d62b77f73d19d96e6bb1a03db90d5f1}
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project multiple: Failed to deploy artifacts: Could not transfer artifact org.jboss.tools.target-platforms.jbdevstudio:multiple:pom:4.21.3.Final from/to jboss-releases-repository (https://repository.jboss.org/nexus/content/repositories/releases/): Failed to transfer file: https://repository.jboss.org/nexus/content/repositories/releases/org/jbos.... Return code is: 502, ReasonPhrase:Proxy Error. -> [Help 1]
> {code}
> {quote}
--
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
13 years, 1 month
[JBoss JIRA] (JBIDE-13671) parent pom should use last-mod-timestamp from git for a plugin/feature instead of current timestamp when building
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13671?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-13671:
---------------------------------------------
nick - already reviewed, see my comment:
Nick Boldt(d) is problematic. Then you would have never versions of something that might be build from older than the actual real build. Adding -CI or just a -dev qualifer or something could work.
> parent pom should use last-mod-timestamp from git for a plugin/feature instead of current timestamp when building
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-13671
> URL: https://issues.jboss.org/browse/JBIDE-13671
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.1.x
>
> Attachments: jbide13671-before-and-after.png
>
>
> This needs to be added to master parent pom:
> {code}
> <plugin>
> <groupId>org.eclipse.tycho</groupId>
> <artifactId>tycho-packaging-plugin</artifactId>
> <version>${tycho.version}</version>
> <dependencies>
> <dependency>
> <groupId>org.eclipse.tycho.extras</groupId>
> <artifactId>tycho-buildtimestamp-jgit</artifactId>
> <version>${tycho-extras.version}</version>
> </dependency>
> </dependencies>
> <configuration>
> <strictBinIncludes>false</strictBinIncludes>
> <format>'v'yyyyMMdd-HHmm</format>
> <timestampProvider>jgit</timestampProvider>
> <jgit.ignore>
> </jgit.ignore>
> </configuration>
> </plugin>
> {code}
> Ref: http://pweclipse.blogspot.ch/2012_09_01_archive.html
--
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
13 years, 1 month
.jpeg){kind=link}