[JBoss JIRA] (JBIDE-14448) Build doesn't detect cycle dependencies between JBossTools modules
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14448?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-14448 at 10/15/13 2:14 PM:
--------------------------------------------------------------
OK, so what I'm hearing here is that we need two things for each and every project:
* a way to easily build a given project based on THE LATEST upstream builds of dependencies for a given stream (_40, _410, _41, _master), both locally and in Jenkins [this we already do]
* a way to easily build a given project based on SPECIFIC upstream builds of dependencies (eg., Base build #456 and Server build #567), both locally and in Jenkins [this is a new requirement - see JBIDE-15482 ]
Therefore we need to:
* replace staging/JOB_NAME/all/repo/ with ci/JOB_NAME/BUILD_ID/all/repo/ when publishing [0] (JBIDE-15482)
* automatically clean out old builds [1] to avoid filling download.jboss.org and crashing it (JBIDE-15482)
* a tool [2] to generate a composite site on dl.jb.org, fed a series of URLs for upstream projects against which you want to build (using the latest by default + some static sites) [3]
* a tool [2] to generate a composite site *locally*, fed a series of URLs for upstream projects SPECIFIC BUILDS against which you want to build (likely a subset of the full site above [3]
[0] https://github.com/jbosstools/jbosstools-build-ci/blob/master/publish/pub...
[1] https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/cleanu...
[2] https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/genera...
[3] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.1....
Once all the above is in place, we would then need a profile or -Dflag in parent pom (such as *-Djbosstools-nightly*) to allow a user to point at their locally-generated composite site (from the previous item) instead of using the default composite.
For example, we might want to do this, to build LiveReload against specific upstream builds:
{code}
wget https://raw.github.com/jbosstools/jbosstools-build-ci/master/util/generat... && chmod +x generateCompositeStagingSiteMetadata.sh
./generateCompositeStagingSiteMetadata.sh -NAME 'My Local Upstream Composite Site' -DESTINATION /tmp/my-local-site/ -SITES http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
{code}
then this:
{code}
cd ~/path/to/jbosstools-livereload
mvn clean verify -Djbosstools-nightly=file:///tmp/my-local-site/
{code}
... and boom goes the dynamite.
was (Author: nickboldt):
OK, so what I'm hearing here is that we need two things for each and every project:
* a way to easily build a given project based on THE LATEST upstream builds of dependencies for a given stream (_40, _410, _41, _master), both locally and in Jenkins [this we already do]
* a way to easily build a given project based on SPECIFIC upstream builds of dependencies (eg., Base build #456 and Server build #567), both locally and in Jenkins [this is a new requirement - see JBIDE-15482]
Therefore we need to:
* replace staging/JOB_NAME/all/repo/ with ci/JOB_NAME/BUILD_ID/all/repo/ when publishing [0] (JBIDE-15482)
* automatically clean out old builds [1] to avoid filling download.jboss.org and crashing it (JBIDE-15482)
* a tool [2] to generate a composite site on dl.jb.org, fed a series of URLs for upstream projects against which you want to build (using the latest by default + some static sites) [3]
* a tool [2] to generate a composite site *locally*, fed a series of URLs for upstream projects SPECIFIC BUILDS against which you want to build (likely a subset of the full site above [3]
[0] https://github.com/jbosstools/jbosstools-build-ci/blob/master/publish/pub...
[1] https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/cleanu...
[2] https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/genera...
[3] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.1....
Once all the above is in place, we would then need a profile or -Dflag in parent pom (such as *-Djbosstools-nightly*) to allow a user to point at their locally-generated composite site (from the previous item) instead of using the default composite.
For example, we might want to do this, to build LiveReload against specific upstream builds:
{code}
wget https://raw.github.com/jbosstools/jbosstools-build-ci/master/util/generat... && chmod +x generateCompositeStagingSiteMetadata.sh
./generateCompositeStagingSiteMetadata.sh -NAME 'My Local Upstream Composite Site' -DESTINATION /tmp/my-local-site/ -SITES http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
{code}
then this:
{code}
cd ~/path/to/jbosstools-livereload
mvn clean verify -Djbosstools-nightly=file:///tmp/my-local-site/
{code}
... and boom goes the dynamite.
> Build doesn't detect cycle dependencies between JBossTools modules
> ------------------------------------------------------------------
>
> Key: JBIDE-14448
> URL: https://issues.jboss.org/browse/JBIDE-14448
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.1.0.Beta1
> Reporter: Denis Golovin
> Assignee: Nick Boldt
> Priority: Blocker
> Fix For: 4.2.0.Alpha1
>
>
> Currently every component references nightly composite update site during the build to get dependencies. That leads to possibility to introduce cycle dependencies between components that is not detected by build.
> Here is example of PR introduced a cycle between JST and VPE. Build works because JST have access to VPE BrowserSim through nightly composite update site.
> The solution would be to reference specific nightly update sites for modules that are dependencies for current one.
> In this case JST should have reference only to base composite nightly update site. That would solve cycle dependency detection problem and speed up the build because it would not require to download and analyse all metadata from jbosstools nightly composite update 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
12 years, 7 months
[JBoss JIRA] (JBIDE-14448) Build doesn't detect cycle dependencies between JBossTools modules
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14448?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-14448 at 10/15/13 2:15 PM:
--------------------------------------------------------------
OK, so what I'm hearing here is that we need two things for each and every project:
* a way to easily build a given project based on THE LATEST upstream builds of dependencies for a given stream (_40, _410, _41, _master), both locally and in Jenkins - this we already do
* a way to easily build a given project based on SPECIFIC upstream builds of dependencies (eg., Base build #456 and Server build #567), both locally and in Jenkins - this is a new requirement - see JBIDE-15482
Therefore we need to:
* replace staging/JOB_NAME/all/repo/ with ci/JOB_NAME/BUILD_ID/all/repo/ when publishing [0] (JBIDE-15482)
* automatically clean out old builds [1] to avoid filling download.jboss.org and crashing it (JBIDE-15482)
* a tool [2] to generate a composite site on dl.jb.org, fed a series of URLs for upstream projects against which you want to build (using the latest by default + some static sites) [3]
* a tool [2] to generate a composite site *locally*, fed a series of URLs for upstream projects SPECIFIC BUILDS against which you want to build (likely a subset of the full site above [3]
[0] https://github.com/jbosstools/jbosstools-build-ci/blob/master/publish/pub...
[1] https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/cleanu...
[2] https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/genera...
[3] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.1....
Once all the above is in place, we would then need a profile or -Dflag in parent pom (such as *-Djbosstools-nightly*) to allow a user to point at their locally-generated composite site (from the previous item) instead of using the default composite.
For example, we might want to do this, to build LiveReload against specific upstream builds:
{code}
wget https://raw.github.com/jbosstools/jbosstools-build-ci/master/util/generat... && chmod +x generateCompositeStagingSiteMetadata.sh
./generateCompositeStagingSiteMetadata.sh -NAME 'My Local Upstream Composite Site' -DESTINATION /tmp/my-local-site/ -SITES http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
{code}
then this:
{code}
cd ~/path/to/jbosstools-livereload
mvn clean verify -Djbosstools-nightly=file:///tmp/my-local-site/
{code}
... and boom goes the dynamite.
was (Author: nickboldt):
OK, so what I'm hearing here is that we need two things for each and every project:
* a way to easily build a given project based on THE LATEST upstream builds of dependencies for a given stream (_40, _410, _41, _master), both locally and in Jenkins [this we already do]
* a way to easily build a given project based on SPECIFIC upstream builds of dependencies (eg., Base build #456 and Server build #567), both locally and in Jenkins [this is a new requirement - see JBIDE-15482 ]
Therefore we need to:
* replace staging/JOB_NAME/all/repo/ with ci/JOB_NAME/BUILD_ID/all/repo/ when publishing [0] (JBIDE-15482)
* automatically clean out old builds [1] to avoid filling download.jboss.org and crashing it (JBIDE-15482)
* a tool [2] to generate a composite site on dl.jb.org, fed a series of URLs for upstream projects against which you want to build (using the latest by default + some static sites) [3]
* a tool [2] to generate a composite site *locally*, fed a series of URLs for upstream projects SPECIFIC BUILDS against which you want to build (likely a subset of the full site above [3]
[0] https://github.com/jbosstools/jbosstools-build-ci/blob/master/publish/pub...
[1] https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/cleanu...
[2] https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/genera...
[3] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.1....
Once all the above is in place, we would then need a profile or -Dflag in parent pom (such as *-Djbosstools-nightly*) to allow a user to point at their locally-generated composite site (from the previous item) instead of using the default composite.
For example, we might want to do this, to build LiveReload against specific upstream builds:
{code}
wget https://raw.github.com/jbosstools/jbosstools-build-ci/master/util/generat... && chmod +x generateCompositeStagingSiteMetadata.sh
./generateCompositeStagingSiteMetadata.sh -NAME 'My Local Upstream Composite Site' -DESTINATION /tmp/my-local-site/ -SITES http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
{code}
then this:
{code}
cd ~/path/to/jbosstools-livereload
mvn clean verify -Djbosstools-nightly=file:///tmp/my-local-site/
{code}
... and boom goes the dynamite.
> Build doesn't detect cycle dependencies between JBossTools modules
> ------------------------------------------------------------------
>
> Key: JBIDE-14448
> URL: https://issues.jboss.org/browse/JBIDE-14448
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.1.0.Beta1
> Reporter: Denis Golovin
> Assignee: Nick Boldt
> Priority: Blocker
> Fix For: 4.2.0.Alpha1
>
>
> Currently every component references nightly composite update site during the build to get dependencies. That leads to possibility to introduce cycle dependencies between components that is not detected by build.
> Here is example of PR introduced a cycle between JST and VPE. Build works because JST have access to VPE BrowserSim through nightly composite update site.
> The solution would be to reference specific nightly update sites for modules that are dependencies for current one.
> In this case JST should have reference only to base composite nightly update site. That would solve cycle dependency detection problem and speed up the build because it would not require to download and analyse all metadata from jbosstools nightly composite update 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
12 years, 7 months
[JBoss JIRA] (JBIDE-15302) CordovaSim: support of cordova 3.1
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15302?page=com.atlassian.jira.plugi... ]
Ilya Buziuk updated JBIDE-15302:
--------------------------------
Description:
The next major release of cordova 3.1 is already available for download.
CordovaSim should support it.
was:
The next major release of Cordova 3.1 is already available for download.
CordovaSim should support it.
> CordovaSim: support of cordova 3.1
> ----------------------------------
>
> Key: JBIDE-15302
> URL: https://issues.jboss.org/browse/JBIDE-15302
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: browsersim
> Affects Versions: 4.1.0.Final
> Reporter: Yahor Radtsevich
> Assignee: Ilya Buziuk
> Fix For: 4.2.x
>
>
> The next major release of cordova 3.1 is already available for download.
> CordovaSim should support it.
--
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
12 years, 7 months
[JBoss JIRA] (JBIDE-14448) Build doesn't detect cycle dependencies between JBossTools modules
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14448?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-14448 at 10/15/13 2:14 PM:
--------------------------------------------------------------
OK, so what I'm hearing here is that we need two things for each and every project:
* a way to easily build a given project based on THE LATEST upstream builds of dependencies for a given stream (_40, _410, _41, _master), both locally and in Jenkins [this we already do]
* a way to easily build a given project based on SPECIFIC upstream builds of dependencies (eg., Base build #456 and Server build #567), both locally and in Jenkins [this is a new requirement - see JBIDE-15482]
Therefore we need to:
* replace staging/JOB_NAME/all/repo/ with ci/JOB_NAME/BUILD_ID/all/repo/ when publishing [0] (JBIDE-15482)
* automatically clean out old builds [1] to avoid filling download.jboss.org and crashing it (JBIDE-15482)
* a tool [2] to generate a composite site on dl.jb.org, fed a series of URLs for upstream projects against which you want to build (using the latest by default + some static sites) [3]
* a tool [2] to generate a composite site *locally*, fed a series of URLs for upstream projects SPECIFIC BUILDS against which you want to build (likely a subset of the full site above [3]
[0] https://github.com/jbosstools/jbosstools-build-ci/blob/master/publish/pub...
[1] https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/cleanu...
[2] https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/genera...
[3] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.1....
Once all the above is in place, we would then need a profile or -Dflag in parent pom (such as *-Djbosstools-nightly*) to allow a user to point at their locally-generated composite site (from the previous item) instead of using the default composite.
For example, we might want to do this, to build LiveReload against specific upstream builds:
{code}
wget https://raw.github.com/jbosstools/jbosstools-build-ci/master/util/generat... && chmod +x generateCompositeStagingSiteMetadata.sh
./generateCompositeStagingSiteMetadata.sh -NAME 'My Local Upstream Composite Site' -DESTINATION /tmp/my-local-site/ -SITES http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
{code}
then this:
{code}
cd ~/path/to/jbosstools-livereload
mvn clean verify -Djbosstools-nightly=file:///tmp/my-local-site/
{code}
... and boom goes the dynamite.
was (Author: nickboldt):
OK, so what I'm hearing here is that we need two things for each and every project:
* a way to easily build a given project based on SPECIFIC upstream builds of dependencies (eg., Base build #456 and Server build #567), both locally and in Jenkins
* a way to easily build a given project based on THE LATEST upstream builds of dependencies for a given stream (_40, _410, _41, _master)
Therefore we need to:
* replace staging/JOB_NAME/all/repo/ with ci/JOB_NAME/BUILD_ID/all/repo/ when publishing [0] (JBIDE-15482)
* automatically clean out old builds [1] to avoid filling download.jboss.org and crashing it (JBIDE-15482)
* a tool [2] to generate a composite site on dl.jb.org, fed a series of URLs for upstream projects against which you want to build (using the latest by default + some static sites) [3]
* a tool [2] to generate a composite site *locally*, fed a series of URLs for upstream projects SPECIFIC BUILDS against which you want to build (likely a subset of the full site above [3]
[0] https://github.com/jbosstools/jbosstools-build-ci/blob/master/publish/pub...
[1] https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/cleanu...
[2] https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/genera...
[3] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.1....
Once all the above is in place, we would then need a profile or -Dflag in parent pom (such as * -Djbosstools-nightly*) to allow a user to point at their locally-generated composite site (from the previous item) instead of using the default composite.
For example, we might want to do this:
{code}
wget https://raw.github.com/jbosstools/jbosstools-build-ci/master/util/generat... && chmod +x generateCompositeStagingSiteMetadata.sh
./generateCompositeStagingSiteMetadata.sh -NAME 'My Local Upstream Composite Site' -DESTINATION /tmp/my-local-site/ -SITES http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
{code}
then this:
{code}
cd ~/path/to/jbosstools-livereload
mvn clean verify -Djbosstools-nightly=file:///tmp/my-local-site/
{code}
... and boom goes the dynamite.
> Build doesn't detect cycle dependencies between JBossTools modules
> ------------------------------------------------------------------
>
> Key: JBIDE-14448
> URL: https://issues.jboss.org/browse/JBIDE-14448
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.1.0.Beta1
> Reporter: Denis Golovin
> Assignee: Nick Boldt
> Priority: Blocker
> Fix For: 4.2.0.Alpha1
>
>
> Currently every component references nightly composite update site during the build to get dependencies. That leads to possibility to introduce cycle dependencies between components that is not detected by build.
> Here is example of PR introduced a cycle between JST and VPE. Build works because JST have access to VPE BrowserSim through nightly composite update site.
> The solution would be to reference specific nightly update sites for modules that are dependencies for current one.
> In this case JST should have reference only to base composite nightly update site. That would solve cycle dependency detection problem and speed up the build because it would not require to download and analyse all metadata from jbosstools nightly composite update 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
12 years, 7 months
[JBoss JIRA] (JBIDE-15302) CordovaSim: support of Cordova 3.1
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15302?page=com.atlassian.jira.plugi... ]
Ilya Buziuk updated JBIDE-15302:
--------------------------------
Description:
The next major release of Cordova 3.1 is already available for download.
CordovaSim should support it.
was:
The next major release of Cordova 3.0 is already available for download.
CordovaSim should support it.
> CordovaSim: support of Cordova 3.1
> ----------------------------------
>
> Key: JBIDE-15302
> URL: https://issues.jboss.org/browse/JBIDE-15302
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: browsersim
> Affects Versions: 4.1.0.Final
> Reporter: Yahor Radtsevich
> Assignee: Ilya Buziuk
> Fix For: 4.2.x
>
>
> The next major release of Cordova 3.1 is already available for download.
> CordovaSim should support it.
--
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
12 years, 7 months
[JBoss JIRA] (JBIDE-14448) Build doesn't detect cycle dependencies between JBossTools modules
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14448?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-14448:
------------------------------------
OK, so what I'm hearing here is that we need two things for each and every project:
* a way to easily build a given project based on SPECIFIC upstream builds of dependencies (eg., Base build #456 and Server build #567), both locally and in Jenkins
* a way to easily build a given project based on THE LATEST upstream builds of dependencies for a given stream (_40, _410, _41, _master)
Therefore we need to:
* replace staging/JOB_NAME/all/repo/ with ci/JOB_NAME/BUILD_ID/all/repo/ when publishing [0] (JBIDE-15482)
* automatically clean out old builds [1] to avoid filling download.jboss.org and crashing it (JBIDE-15482)
* a tool [2] to generate a composite site on dl.jb.org, fed a series of URLs for upstream projects against which you want to build (using the latest by default + some static sites) [3]
* a tool [2] to generate a composite site *locally*, fed a series of URLs for upstream projects SPECIFIC BUILDS against which you want to build (likely a subset of the full site above [3]
[0] https://github.com/jbosstools/jbosstools-build-ci/blob/master/publish/pub...
[1] https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/cleanu...
[2] https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/genera...
[3] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.1....
Once all the above is in place, we would then need a profile or -Dflag in parent pom (such as * -Djbosstools-nightly*) to allow a user to point at their locally-generated composite site (from the previous item) instead of using the default composite.
For example, we might want to do this:
{code}
wget https://raw.github.com/jbosstools/jbosstools-build-ci/master/util/generat... && chmod +x generateCompositeStagingSiteMetadata.sh
./generateCompositeStagingSiteMetadata.sh -NAME 'My Local Upstream Composite Site' -DESTINATION /tmp/my-local-site/ -SITES http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2...
{code}
then this:
{code}
cd ~/path/to/jbosstools-livereload
mvn clean verify -Djbosstools-nightly=file:///tmp/my-local-site/
{code}
... and boom goes the dynamite.
> Build doesn't detect cycle dependencies between JBossTools modules
> ------------------------------------------------------------------
>
> Key: JBIDE-14448
> URL: https://issues.jboss.org/browse/JBIDE-14448
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.1.0.Beta1
> Reporter: Denis Golovin
> Assignee: Nick Boldt
> Priority: Blocker
> Fix For: 4.2.0.Alpha1
>
>
> Currently every component references nightly composite update site during the build to get dependencies. That leads to possibility to introduce cycle dependencies between components that is not detected by build.
> Here is example of PR introduced a cycle between JST and VPE. Build works because JST have access to VPE BrowserSim through nightly composite update site.
> The solution would be to reference specific nightly update sites for modules that are dependencies for current one.
> In this case JST should have reference only to base composite nightly update site. That would solve cycle dependency detection problem and speed up the build because it would not require to download and analyse all metadata from jbosstools nightly composite update 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
12 years, 7 months
[JBoss JIRA] (JBIDE-15653) Import application wizard: Errors "Could not publish: Attempted to begin rule"
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15653?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-15653:
------------------------------------------
so the suggested fix is currently to end the current rule (which locks 0 projects) and start a new rule that locks the published project:
{code}
if (allSubModulesPublished
|| (destFolder != null && destFolder.isAccessible())) {
ISchedulingRule originalRule = Job.getJobManager().currentRule();
Job.getJobManager().endRule(originalRule);
ISchedulingRule tmpRule = ResourcesPlugin.getWorkspace().getRuleFactory().modifyRule(destProj);
try {
Job.getJobManager().beginRule(tmpRule);
refreshProject(destProj, submon(monitor, 100));
commitAndPushProject(destProj, behaviour, submon(monitor, 100));
} finally {
Job.getJobManager().endRule(tmpRule);
Job.getJobManager().beginRule(originalRule);
}
} // else ignore. (one or more modules not published AND magic
// folder doesn't exist
// The previous exception will be propagated.
}
{code}
This then made the git pushing fail with a similar locking issue. EGit tries to lock the whole workspace:
{code}
java.lang.IllegalArgumentException: Attempted to beginRule: R/, does not match outer scope rule: P/jbas7
at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63)
at org.eclipse.core.internal.jobs.ThreadJob.illegalPush(ThreadJob.java:134)
at org.eclipse.core.internal.jobs.ThreadJob.push(ThreadJob.java:333)
at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:63)
at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:286)
at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:118)
at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:2283)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2340)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2327)
at org.eclipse.egit.core.op.CommitOperation.execute(CommitOperation.java:200)
at org.jboss.tools.openshift.egit.core.EGitUtils.commit(EGitUtils.java:392)
at org.jboss.tools.openshift.egit.core.EGitUtils.commit(EGitUtils.java:363)
at org.jboss.tools.openshift.egit.core.EGitUtils.commit(EGitUtils.java:368)
at org.jboss.tools.openshift.express.internal.core.behaviour.OpenShiftServerPublishMethod.commitAndPushProject(OpenShiftServerPublishMethod.java:215)
at org.jboss.tools.openshift.express.internal.core.behaviour.OpenShiftServerPublishMethod.publishFinish(OpenShiftServerPublishMethod.java:85)
at org.jboss.ide.eclipse.as.core.server.internal.DeployableServerBehavior.publishFinish(DeployableServerBehavior.java:102)
at org.jboss.ide.eclipse.as.core.server.internal.DelegatingServerBehavior.publishFinish(DelegatingServerBehavior.java:168)
at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:1011)
at org.jboss.tools.openshift.express.internal.core.behaviour.OpenShiftServerBehaviour.publish(OpenShiftServerBehaviour.java:38)
at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:774)
at org.jboss.tools.openshift.express.internal.core.behaviour.OpenShiftServerBehaviour.publish(OpenShiftServerBehaviour.java:45)
at org.eclipse.wst.server.core.internal.Server.publishImpl(Server.java:3153)
at org.eclipse.wst.server.core.internal.Server$PublishJob.run(Server.java:345)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
{code}
To solve this we have to lock the whole workspace:
{code}
IResourceRuleFactory ruleFactory = ResourcesPlugin.getWorkspace().getRuleFactory();
ISchedulingRule workspaceLock = ruleFactory.modifyRule(ResourcesPlugin.getWorkspace().getRoot());
try {
Job.getJobManager().beginRule(workspaceLock, monitor);
refreshProject(destProj, submon(monitor, 100));
commitAndPushProject(destProj, behaviour, submon(monitor, 100));
} finally {
Job.getJobManager().endRule(workspaceLock);
Job.getJobManager().beginRule(originalRule, monitor);
}
{code}
> Import application wizard: Errors "Could not publish: Attempted to begin rule"
> ------------------------------------------------------------------------------
>
> Key: JBIDE-15653
> URL: https://issues.jboss.org/browse/JBIDE-15653
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.2.0.Alpha1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Priority: Blocker
> Fix For: 4.2.0.Alpha1
>
> Attachments: could-not-import.png, gitignore-committed-locally.png
>
>
--
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
12 years, 7 months