[JBoss JIRA] (JBIDE-13672) could publish.sh check previous build's GIT_REVISION.txt or ALL_REVISIONS.txt before overriding existing update site w/ new content?
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13672?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-13672 at 3/1/13 12:55 PM:
-------------------------------------------------------------
Now, if the previous build's git revision (SHA) is the same as the current one, it won't bother to push the new bits to the staging/\{jobname\}/all/repo site, which means the composite site will not change, and therefore the downstream aggregation will not happen. This minimizes builds for the sake of building, but still allows us to rebuild/retest as a result of upstream changes (like a new target platform or a possible API change).
So, should Base change, you can manually kick off Server to ensure everything still builds. But if the CODE in Server is unchanged, Server will not be *published*, only built & tested. You can scan the build logs for this message:
{code}
=======================================================================================================
GIT revision(s) UNCHANGED. Publish cancelled (nothing to do). Skip this check with 'EXPORT skipRevisionCheckWhenPublishing=true;
=======================================================================================================
{code}
was (Author: nickboldt):
Now, if the previous build's git revision (SHA) is the same as the current one, it won't bother to push the new bits to the staging/{jobname}/all/repo site, which means the composite site will not change, and therefore the downstream aggregation will not happen. This minimizes builds for the sake of building, but still allows us to rebuild/retest as a result of upstream changes (like a new target platform or a possible API change).
So, should Base change, you can manually kick off Server to ensure everything still builds. But if the CODE in Server is unchanged, Server will not be *published*, only built & tested. You can scan the build logs for this message:
{code}
=======================================================================================================
GIT revision(s) UNCHANGED. Publish cancelled (nothing to do). Skip this check with 'EXPORT skipRevisionCheckWhenPublishing=true;
=======================================================================================================
{code}
> could publish.sh check previous build's GIT_REVISION.txt or ALL_REVISIONS.txt before overriding existing update site w/ new content?
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-13672
> URL: https://issues.jboss.org/browse/JBIDE-13672
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng, updatesite
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.1.0.Alpha2
>
>
> Before we rsync new content from the job's workspace to www.qa or download.jboss.org, we should compare the previous build's git revision(s) to decide if the new build needs to be published.
> May want to add an override flag in the job to FORCE a publish (ie., a manually built aggregate).
> Sample files to check:
> http://download.jboss.org/jbosstools/builds/staging/jbosstools-base_41/lo...
> http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-site...
--
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-13672) could publish.sh check previous build's GIT_REVISION.txt or ALL_REVISIONS.txt before overriding existing update site w/ new content?
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13672?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-13672:
------------------------------------
Now, if the previous build's git revision (SHA) is the same as the current one, it won't bother to push the new bits to the staging/{jobname}/all/repo site, which means the composite site will not change, and therefore the downstream aggregation will not happen. This minimizes builds for the sake of building, but still allows us to rebuild/retest as a result of upstream changes (like a new target platform or a possible API change).
So, should Base change, you can manually kick off Server to ensure everything still builds. But if the CODE in Server is unchanged, Server will not be *published*, only built & tested. You can scan the build logs for this message:
{code}
=======================================================================================================
GIT revision(s) UNCHANGED. Publish cancelled (nothing to do). Skip this check with 'EXPORT skipRevisionCheckWhenPublishing=true;
=======================================================================================================
{code}
> could publish.sh check previous build's GIT_REVISION.txt or ALL_REVISIONS.txt before overriding existing update site w/ new content?
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-13672
> URL: https://issues.jboss.org/browse/JBIDE-13672
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng, updatesite
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.1.0.Alpha2
>
>
> Before we rsync new content from the job's workspace to www.qa or download.jboss.org, we should compare the previous build's git revision(s) to decide if the new build needs to be published.
> May want to add an override flag in the job to FORCE a publish (ie., a manually built aggregate).
> Sample files to check:
> http://download.jboss.org/jbosstools/builds/staging/jbosstools-base_41/lo...
> http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-site...
--
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 Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13671?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-13671:
------------------------------------
A related change I did recently (in master branch only so far) is this: JBIDE-13672
Now, if the previous build's git revision (SHA) is the same as the current one, it won't bother to push the new bits to the staging/{jobname}/all/repo site, which means the composite site will not change, and therefore the downstream aggregation will not happen. This minimizes builds for the sake of building, but still allows us to rebuild/retest as a result of upstream changes (like a new target platform or a possible API change).
So, should Base change, you can manually kick off Server to ensure everything still builds. But if the CODE in Server is unchanged, Server will not be *published*, only built & tested. You can scan the build logs for this message:
{code}
=======================================================================================================
GIT revision(s) UNCHANGED. Publish cancelled (nothing to do). Skip this check with 'EXPORT skipRevisionCheckWhenPublishing=true;
=======================================================================================================
{code}
> 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.0.Alpha2
>
> 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-13704) Cannot build integration-tests from branch 4.0.x
by Tomas Remes (JIRA)
Tomas Remes created JBIDE-13704:
-----------------------------------
Summary: Cannot build integration-tests from branch 4.0.x
Key: JBIDE-13704
URL: https://issues.jboss.org/browse/JBIDE-13704
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: QA
Reporter: Tomas Remes
Assignee: Len DiMaggio
Running mvn clean install -DskipTests on the clean repo, I got:
{noformat}
[ERROR] Cannot resolve project dependencies:
[ERROR] Software being installed: org.jboss.ide.eclipse.as.ui.bot.test 4.0.0.qualifier
[ERROR] Missing requirement: org.jboss.tools.ui.bot.ext 4.0.0.qualifier requires 'bundle org.eclipse.zest.core 1.2.0' but it could not be found
[ERROR] Cannot satisfy dependency: org.jboss.ide.eclipse.as.ui.bot.test 4.0.0.qualifier depends on: bundle org.jboss.tools.ui.bot.ext 1.0.0
[ERROR]
[ERROR] Internal error: java.lang.RuntimeException: "No solution found because the problem is unsatisfiable.": ["Unable to satisfy dependency from org.jboss.tools.ui.bot.ext 4.0.0.qualifier to bundle org.eclipse.zest.core 1.2.0.", "Unable to satisfy dependency from org.jboss.tools.ui.bot.ext 4.0.0.qualifier to bundle org.eclipse.zest.layouts 1.1.0.", "No solution found because the problem is unsatisfiable."] -> [Help 1]
org.apache.maven.InternalErrorException: Internal error: java.lang.RuntimeException: "No solution found because the problem is unsatisfiable.": ["Unable to satisfy dependency from org.jboss.tools.ui.bot.ext 4.0.0.qualifier to bundle org.eclipse.zest.core 1.2.0.", "Unable to satisfy dependency from org.jboss.tools.ui.bot.ext 4.0.0.qualifier to bundle org.eclipse.zest.layouts 1.1.0.", "No solution found because the problem is unsatisfiable."]
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: java.lang.RuntimeException: "No solution found because the problem is unsatisfiable.": ["Unable to satisfy dependency from org.jboss.tools.ui.bot.ext 4.0.0.qualifier to bundle org.eclipse.zest.core 1.2.0.", "Unable to satisfy dependency from org.jboss.tools.ui.bot.ext 4.0.0.qualifier to bundle org.eclipse.zest.layouts 1.1.0.", "No solution found because the problem is unsatisfiable."]
at org.eclipse.tycho.p2.resolver.AbstractResolutionStrategy.newResolutionException(AbstractResolutionStrategy.java:77)
at org.eclipse.tycho.p2.resolver.ProjectorResolutionStrategy.resolve(ProjectorResolutionStrategy.java:89)
at org.eclipse.tycho.p2.impl.resolver.P2ResolverImpl.resolveProject(P2ResolverImpl.java:122)
at org.eclipse.tycho.p2.impl.resolver.P2ResolverImpl.resolveProject(P2ResolverImpl.java:80)
at org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.doResolvePlatform(P2TargetPlatformResolver.java:377)
at org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.resolveDependencies(P2TargetPlatformResolver.java:354)
at org.eclipse.tycho.core.resolver.DefaultTychoDependencyResolver.resolveProject(DefaultTychoDependencyResolver.java:103)
at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:82)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:274)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
... 11 more
{noformat}
--
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-13703) Team - Verify the workflow
by Burr Sutter (JIRA)
Burr Sutter created JBIDE-13703:
-----------------------------------
Summary: Team - Verify the workflow
Key: JBIDE-13703
URL: https://issues.jboss.org/browse/JBIDE-13703
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Reporter: Burr Sutter
Assignee: Burr Sutter
The average end-user would like to:
check out (clone) a project from CVS, SVN or Git
-- project may or may not have .classpath, .project or .settings files
-- project may be Maven-based
and see if the following work
2) Are the appropriate facets enabled?
3) Does it build immediately?
4) Can I immediately hit the run button to launch it on my app server?
5) Can I immediately hit the debug button to debug it on my favorite app server?
- how do I step if there are no break points?
6) Make a change to a file
7) Run tests
8) Check the change back in with comments
--
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-13702) ForgeCorePlugin could use an installed Forge 2 Runtime
by George Gastaldi (JIRA)
George Gastaldi created JBIDE-13702:
---------------------------------------
Summary: ForgeCorePlugin could use an installed Forge 2 Runtime
Key: JBIDE-13702
URL: https://issues.jboss.org/browse/JBIDE-13702
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: forge
Reporter: George Gastaldi
Assignee: Koen Aers
In Forge 1, it is possible to configure external Forge runtimes. In Forge 2 it would be nice to allow configuration of that, but also avoid the need to unzip the files in the startup.
--
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