[JBoss JIRA] (JBIDE-16128) Publish component sites to Nexus
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16128?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-16128:
------------------------------------
[~maxandersen]:
Tweaking our job configs to drop SNAPSHOT zips to Nexus is easy. Compositing them is also easy. We can follow the process that JBT IS uses for this, including PRs for requests to add new versions of zips to the composite.
Training devs to do so, and convincing them of the value as it outweighs the overhead incurred in having to do so, that's not so easy.
I'm all for the idea of having the various projects (components) releasing independently (at least for the ones that aren't closely interdependent), even though it may initially feel like we're moving away from a synchronized release train (JBT, Eclipse) and more toward a cat-herding exercise (JBT IS).
But before that can happen, you need to convince the team that this is a Good Idea. Mickael and I can support them in what they'll need to do to adopt the new workflow. But if they don't buy into the concept, they won't do it.
Proof of this is the fact that back in February 2013, I implemented a suggestion that all component nightlies would be automatically promoted to "integration" once a week [1], so that devs could then choose to promote their integration builds at some interval to stable milestone or even do an early release. Even the dev who'd specifically asked for this capability never ended up using it.
[1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS...
Replacing that process
- run automatically to create integration builds
- permit devs to selectively take the latest weekly integration build to promote to milestone or release
with a process that
- run automatically to drop builds into the Nexus staging repo
- permit devs to perform the release from staging to release repo
Achieves the same goal. Will it be perceived as "better?" Maybe.
Bottom line: if you can lead them to the water, I'll make sure the water is potable when they get there. But it's up to you to convince them to actually DRINK.
> Publish component sites to Nexus
> --------------------------------
>
> Key: JBIDE-16128
> URL: https://issues.jboss.org/browse/JBIDE-16128
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: 4.2.0.Alpha1
>
>
> In order to get a first idea of how easy/difficult it would be to rely on Nexus for publication,we could simply start by configuring CI jobs to also run a "mvn deploy" to deploy the output p2 repository onto Nexus.
> Then we'll see what are the pros/cons of this approach.
> Current publication process and locations will be kept. These p2 repo on Nexus won't be consumed by aggregator, at least not until we are sure it's worth 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
11 years, 11 months
[JBoss JIRA] (JBIDE-16132) XCode library search path is not set properly
by Gorkem Ercan (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16132?page=com.atlassian.jira.plugi... ]
Gorkem Ercan commented on JBIDE-16132:
--------------------------------------
[~nickboldt] fixed on 4.1.1.x branch as well
> XCode library search path is not set properly
> ---------------------------------------------
>
> Key: JBIDE-16132
> URL: https://issues.jboss.org/browse/JBIDE-16132
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: aerogear-hybrid
> Affects Versions: 4.1.1.CR1
> Reporter: Gorkem Ercan
> Assignee: Gorkem Ercan
> Priority: Critical
> Labels: respin-b
> Fix For: 4.1.1.CR1
>
>
> If a Cordova plugin adds a custom framework as a dependency for iOS the project fails to run and the exported XCode project does not compile.
> This is because the iOS project generator does not set the library search paths properly for custom frameworks.
> Aerogear Push Plugin now uses such a framework.
--
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
11 years, 11 months
[JBoss JIRA] (JBIDE-16132) XCode library search path is not set properly
by Gorkem Ercan (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16132?page=com.atlassian.jira.plugi... ]
Gorkem Ercan resolved JBIDE-16132.
----------------------------------
Resolution: Done
> XCode library search path is not set properly
> ---------------------------------------------
>
> Key: JBIDE-16132
> URL: https://issues.jboss.org/browse/JBIDE-16132
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: aerogear-hybrid
> Affects Versions: 4.1.1.CR1
> Reporter: Gorkem Ercan
> Assignee: Gorkem Ercan
> Priority: Critical
> Labels: respin-b
> Fix For: 4.1.1.CR1
>
>
> If a Cordova plugin adds a custom framework as a dependency for iOS the project fails to run and the exported XCode project does not compile.
> This is because the iOS project generator does not set the library search paths properly for custom frameworks.
> Aerogear Push Plugin now uses such a framework.
--
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
11 years, 11 months
[JBoss JIRA] (JBIDE-16093) NPEs when compiling wildfly codebase
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16093?page=com.atlassian.jira.plugi... ]
Snjezana Peco commented on JBIDE-16093:
---------------------------------------
The PR has been applied to the 4.1.1.x branch too.
> NPEs when compiling wildfly codebase
> ------------------------------------
>
> Key: JBIDE-16093
> URL: https://issues.jboss.org/browse/JBIDE-16093
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: testing-tools
> Affects Versions: 4.1.1.CR1
> Reporter: Andre Dietisheim
> Assignee: Max Rydahl Andersen
> Priority: Critical
> Labels: respin-b
> Fix For: 4.1.1.CR1, 4.2.0.Alpha1
>
> Attachments: .log, npes-building-wildfly-2.png, npes-building-wildfly.png
>
>
> When having arquillian org.jboss.tools.arquillian.core_1.0.5.CR1-v20131116-1823-B79 installed and building the wildfly workspace I run into several NPEs caused by arquillian.
> !npes-building-wildfly.png!
> !npes-building-wildfly-2.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
11 years, 11 months
[JBoss JIRA] (JBIDE-16093) NPEs when compiling wildfly codebase
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16093?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-16093 at 11/29/13 1:04 PM:
--------------------------------------------------------------
[~snjeza]:
The 4.1.x branch is for 4.1.2 builds that will start in February.
The 4.1.1.x branch is for 4.1.1.CR1 -> 4.1.1.Final builds that are going on now.
You must push this into the 4.1.1.x branch if you want it fixed in 4.1.1.Final.
was (Author: nickboldt):
4.1.x branch is for 4.1.2 builds that will start in February.
4.1.1.x branch is for 4.1.1.CR1 -> 4.1.1.Final builds that are going on now.
You must push this into the 4.1.1.x branch if you want it fixed in 4.1.1.Final.
> NPEs when compiling wildfly codebase
> ------------------------------------
>
> Key: JBIDE-16093
> URL: https://issues.jboss.org/browse/JBIDE-16093
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: testing-tools
> Affects Versions: 4.1.1.CR1
> Reporter: Andre Dietisheim
> Assignee: Max Rydahl Andersen
> Priority: Critical
> Labels: respin-b
> Fix For: 4.1.1.CR1, 4.2.0.Alpha1
>
> Attachments: .log, npes-building-wildfly-2.png, npes-building-wildfly.png
>
>
> When having arquillian org.jboss.tools.arquillian.core_1.0.5.CR1-v20131116-1823-B79 installed and building the wildfly workspace I run into several NPEs caused by arquillian.
> !npes-building-wildfly.png!
> !npes-building-wildfly-2.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
11 years, 11 months
[JBoss JIRA] (JBIDE-16093) NPEs when compiling wildfly codebase
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16093?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-16093:
------------------------------------
4.1.x branch is for 4.1.2 builds that will start in February.
4.1.1.x branch is for 4.1.1.CR1 -> 4.1.1.Final builds that are going on now.
You must push this into the 4.1.1.x branch if you want it fixed in 4.1.1.Final.
> NPEs when compiling wildfly codebase
> ------------------------------------
>
> Key: JBIDE-16093
> URL: https://issues.jboss.org/browse/JBIDE-16093
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: testing-tools
> Affects Versions: 4.1.1.CR1
> Reporter: Andre Dietisheim
> Assignee: Max Rydahl Andersen
> Priority: Critical
> Labels: respin-b
> Fix For: 4.1.1.CR1, 4.2.0.Alpha1
>
> Attachments: .log, npes-building-wildfly-2.png, npes-building-wildfly.png
>
>
> When having arquillian org.jboss.tools.arquillian.core_1.0.5.CR1-v20131116-1823-B79 installed and building the wildfly workspace I run into several NPEs caused by arquillian.
> !npes-building-wildfly.png!
> !npes-building-wildfly-2.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
11 years, 11 months
[JBoss JIRA] (JBIDE-16161) Tycho tests require org.eclipse.osgi.compatibility.state fragment on Luna
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16161?page=com.atlassian.jira.plugi... ]
Mickael Istria edited comment on JBIDE-16161 at 11/29/13 1:00 PM:
------------------------------------------------------------------
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=417429 , CompatibilityEditor should not depend on PlatformAdmin in the future. I guess your help on this issue on Platform side would be welcome.
So that means that hopefully, by 4.4.M4, this fragment won't be necessary any more, and will slowly disappear.
But until then the only workaround is to add the <dependency> to tycho-surefire-plugin as you suggested. But since some tests are working fine without it, and as you said, it's not easy to understand why a test is failing, I prefer avoiding enabling it by default and have it only added to the relevant surefire executions where it is necessary. It will be easier to figure out which tests actually require it.
I'll send a mail to jbosstools-dev to ask people who have failing tests to try with this bundle.
was (Author: mickael_istria):
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=417429 , CompatibilityEditor should not depend on PlatformAdmin in the future. I guess your help on this issue on Platform side would be welcome.
So that means that hopefully, by 4.4.M4, this fragment won't be necessary any more, and will slowly disappear.
But until then the only workaround is to add the <dependency> to tycho-surefire-plugin as you suggestion. But since some tests are working fine without it, and as you said, it's not easy to understand why a test is failing, I prefer avoiding enabling it by default and have it only added to the relevant surefire executions where it is necessary. It will be easier to figure out which tests actually require it.
I'll send a mail to jbosstools-dev to ask people who have failing tests to try with this bundle.
> Tycho tests require org.eclipse.osgi.compatibility.state fragment on Luna
> -------------------------------------------------------------------------
>
> Key: JBIDE-16161
> URL: https://issues.jboss.org/browse/JBIDE-16161
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.2.0.Alpha1
> Reporter: Snjezana Peco
> Assignee: Mickael Istria
>
> Since Tycho requires the PlatformAdmin service, we have to add the org.eclipse.osgi.compatibility.state fragment to tycho-surefire-plugin.
> The easiest way is to add the org.eclipse.e4.rcp feature to the main build.
--
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
11 years, 11 months
[JBoss JIRA] (JBIDE-16161) Tycho tests require org.eclipse.osgi.compatibility.state fragment on Luna
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16161?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-16161:
----------------------------------------
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=417429 , CompatibilityEditor should not depend on PlatformAdmin in the future. I guess your help on this issue on Platform side would be welcome.
So that means that hopefully, by 4.4.M4, this fragment won't be necessary any more, and will slowly disappear.
But until then the only workaround is to add the <dependency> to tycho-surefire-plugin as you suggestion. But since some tests are working fine without it, and as you said, it's not easy to understand why a test is failing, I prefer avoiding enabling it by default and have it only added to the relevant surefire executions where it is necessary. It will be easier to figure out which tests actually require it.
I'll send a mail to jbosstools-dev to ask people who have failing tests to try with this bundle.
> Tycho tests require org.eclipse.osgi.compatibility.state fragment on Luna
> -------------------------------------------------------------------------
>
> Key: JBIDE-16161
> URL: https://issues.jboss.org/browse/JBIDE-16161
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.2.0.Alpha1
> Reporter: Snjezana Peco
> Assignee: Mickael Istria
>
> Since Tycho requires the PlatformAdmin service, we have to add the org.eclipse.osgi.compatibility.state fragment to tycho-surefire-plugin.
> The easiest way is to add the org.eclipse.e4.rcp feature to the main build.
--
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
11 years, 11 months
[JBoss JIRA] (JBIDE-16161) Tycho tests require org.eclipse.osgi.compatibility.state fragment on Luna
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16161?page=com.atlassian.jira.plugi... ]
Snjezana Peco commented on JBIDE-16161:
---------------------------------------
{quote}
I agree, but I feel it's better to look for the more sustainable solution (Wiring API) instead of the easiest one.
{quote}
I think, we can't easily fix the issue in the tests since it can happen in some plugin that is used by a test (many JBT plugins use CompatibilityEditor that requires the compatibility fragment, for instance).
In this moment, the easiest way to fix the issue is to add the compatibility fragment. That can be done by adding the o.e.e4.rcp feature or by some other way. Any other solution would require a lot of changes in the JBT tests and plugins.
{quote}
See for example https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS...
{quote}
Openshift probably uses an older version of the server (and base) component since those components aren't built.
The compatibility fragment can be added to particular tests. However, it is not easy to determine whether a test fails due to the missing compatibility fragment or for some other reason.
> Tycho tests require org.eclipse.osgi.compatibility.state fragment on Luna
> -------------------------------------------------------------------------
>
> Key: JBIDE-16161
> URL: https://issues.jboss.org/browse/JBIDE-16161
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.2.0.Alpha1
> Reporter: Snjezana Peco
> Assignee: Mickael Istria
>
> Since Tycho requires the PlatformAdmin service, we have to add the org.eclipse.osgi.compatibility.state fragment to tycho-surefire-plugin.
> The easiest way is to add the org.eclipse.e4.rcp feature to the main build.
--
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
11 years, 11 months