[JBoss JIRA] (JBTIS-171) Don't override other connectors in discovery.xml
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBTIS-171?page=com.atlassian.jira.plugin.... ]
Nick Boldt edited comment on JBTIS-171 at 9/13/13 7:54 PM:
-----------------------------------------------------------
I was able to reproduce your problem using the Beta1 site. But I have a simpler solution, which uses the existing build.xml script to generate the staging discovery site that QE can use to perform an installation.
I've fixed the two JBTIS and JBDSIS jobs [1], [2] so that they now pass in a value of UPSTREAM_EXTRAS_SITE to the composite site, which will therefore allow installation of JBDS Central and JBDS IS Central content from a single overriding URL.
[1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate-disc/
[2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBDSIS-aggregate-disc/
To verify this is fixed, try one of these URLs when configuring jbdevstudio.ini:
{code}
-Djboss.discovery.directory.url=http://www.qa.jboss.com/binaries/RHDS/discovery/integration/integration-stack/7.0.0.Beta1a/devstudio-integration-stack-directory.xml
-Djboss.discovery.site.url=http://www.qa.jboss.com/binaries/RHDS/discovery/integration/integration-stack/7.0.0.Beta1a/
{code}
or
{code}
-Djboss.discovery.directory.url=http://www.qa.jboss.com/binaries/RHDS/discovery/integration/integration-stack/7.0.0.Beta2/devstudio-integration-stack-directory.xml
-Djboss.discovery.site.url=http://www.qa.jboss.com/binaries/RHDS/discovery/integration/integration-stack/7.0.0.Beta2/
{code}
The benefit here is that the job can now be configured when run to produce a composite site which is a mix of any specific upstream versions of JBDS+Central+TP or JBT+Central+TP (or simply use the latest changing released version). So we can produce a staging discovery site that would target JBDS 7.0 or 7.1, simply by re-running the job.
was (Author: nickboldt):
I was able to reproduce your problem using the Beta1 site. But I have a simpler solution, which uses the existing build.xml script to generate the staging discovery site that QE can use to perform an installation.
I've fixed the two JBTIS and JBDSIS jobs [1], [2] so that they now pass in a value of UPSTREAM_EXTRAS_SITE to the composite site, which will therefore allow installation of JBDS Central and JBDS IS Central content from a single overriding URL.
[1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate-disc/
[2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBDSIS-aggregate-disc/
To verify this is fixed, try one of these URLs when configuring jbdevstudio.ini:
{code}
-Djboss.discovery.directory.url=http://www.qa.jboss.com/binaries/RHDS/discovery/integration/integration-stack/7.0.0.Beta1a/devstudio-integration-stack-directory.xml
-Djboss.discovery.site.url=http://www.qa.jboss.com/binaries/RHDS/discovery/integration/integration-stack/7.0.0.Beta1a/
{code}
or
{code}
-Djboss.discovery.directory.url=http://www.qa.jboss.com/binaries/RHDS/discovery/integration/integration-stack/7.0.0.Beta2a/devstudio-integration-stack-directory.xml
-Djboss.discovery.site.url=http://www.qa.jboss.com/binaries/RHDS/discovery/integration/integration-stack/7.0.0.Beta2a/
{code}
The benefit here is that the job can now be configured when run to produce a composite site which is a mix of any specific upstream versions of JBDS+Central+TP or JBT+Central+TP (or simply use the latest changing released version). So we can produce a staging discovery site that would target JBDS 7.0 or 7.1, simply by re-running the job.
> Don't override other connectors in discovery.xml
> ------------------------------------------------
>
> Key: JBTIS-171
> URL: https://issues.jboss.org/browse/JBTIS-171
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: distribution
> Reporter: Max Rydahl Andersen
> Assignee: Paul Leacu
>
> Currently this is in discovery plugin:
> siteUrl="$\{jboss.discovery.site.url:https://devstudio.jboss.com/updates/7.0-development/central/integration-stack/}"
>
> And instructions to test it says:
> -vmargs -Djboss.discovery.directory.url=http://www.qa.jboss.com/binaries/RHDS/discovery/integration/integration-stack/7.0.0.Beta1/devstudio-integration-stack-directory.xml -Djboss.discovery.site.url=http://www.qa.jboss.com/binaries/RHDS/discovery/integration/integration-stack/7.0.0.Beta1
> This is all great but it disables all other connectors in JBDS/eclipse thus it makes it hard to get together.
> I suggest you use your own specific site url instead, something like:
> siteUrl="$\{jboss.discovery.integration-stack.site.url:https://devstudio.jboss.com/updates/7.0-development/central/integration-stack/}"
> Then the base connectors will still work.
> We might even consider using recursive properties to allow for a global override, this would need changing in both IS And core discovery.xml to the tune of:
> in core: siteUrl="$\{jboss.global.discovery.site.url,jboss.discovery.site.url:https://devstudio.jboss.com/updates/7.0-development/central/core}"
> in stack:
> siteUrl="$\{jboss.global.discovery.site.url,jboss.discovery.integration-stack.site.url:https://devstudio.jboss.com/updates/7.0-development/central/integration-stack/}"
--
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-14514) openshift-java-client: remove workaround for https://bugzilla.redhat.com/show_bug.cgi?id=812046
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14514?page=com.atlassian.jira.plugi... ]
Andre Dietisheim closed JBIDE-14514.
------------------------------------
closing since nothing for QE to verify
> openshift-java-client: remove workaround for https://bugzilla.redhat.com/show_bug.cgi?id=812046
> -----------------------------------------------------------------------------------------------
>
> Key: JBIDE-14514
> URL: https://issues.jboss.org/browse/JBIDE-14514
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.1.0.Beta1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.2.0.Alpha1
>
>
> In the latest implementations the OpenShift broker returns the embedded cartridges within the application as follows:
> {code}
> "embedded":{
> "mongodb-2.2":{
> "connection_url":"mongodb://$OPENSHIFT_MONGODB_DB_HOST:$OPENSHIFT_MONGODB_DB_PORT/",
> "username":"admin",
> "password":"NNxXMT1z8dVj",
> "database_name":"springeap6",
> "info":"Connection URL: mongodb://$OPENSHIFT_MONGODB_DB_HOST:$OPENSHIFT_MONGODB_DB_PORT/"
> }
> },
> {code}
> Prior code was only returning the *info* property where we had to exctract the url via regex. The new broker is returning the *connection_url* which does not require any regex-treatment any more
> The code in openshift-java-client marks this workaround with a TODO:
> {code}
> protected EmbeddedCartridgeResource(final String name, final String displayName, final String description, final CartridgeType type, String info, final Map<String, Link> links,
> final Map<String, Message> messages, final ApplicationResource application) {
> super(application.getService(), links, messages);
> this.name = name;
> this.displayName = displayName;
> this.description = description;
> this.type = type;
> // TODO: fix this workaround once
> // https://bugzilla.redhat.com/show_bug.cgi?id=812046 is fixed
> this.url = extractUrl(info, messages);
> this.application = application;
> }
> {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
12 years, 7 months
[JBoss JIRA] (JBIDE-15151) NullPointerException reported in Eclipse Error view after using "Materialize Library..." on uninitialized classpath container
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15151?page=com.atlassian.jira.plugi... ]
Fred Bricon commented on JBIDE-15151:
-------------------------------------
Wow I can't wait to meet the guy having such a workflow :-)
> NullPointerException reported in Eclipse Error view after using "Materialize Library..." on uninitialized classpath container
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15151
> URL: https://issues.jboss.org/browse/JBIDE-15151
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: common/jst/core, maven
> Reporter: Denis Golovin
> Assignee: Fred Bricon
> Fix For: 4.2.0.Alpha1
>
> Attachments: JBIDE-15363.ogv
>
>
> {code}
> org.eclipse.e4.core.di.InjectionException: java.lang.NullPointerException
> at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:63)
> at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:243)
> at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:224)
> at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
> at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:167)
> at org.eclipse.core.commands.Command.executeWithChecks(Command.java:499)
> at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
> at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:213)
> at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.executeItem(HandledContributionItem.java:850)
> at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.handleWidgetSelection(HandledContributionItem.java:743)
> at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.access$7(HandledContributionItem.java:727)
> at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem$4.handleEvent(HandledContributionItem.java:662)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1392)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3742)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3363)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:138)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:610)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
> Caused by: java.lang.NullPointerException
> at org.jboss.tools.common.jdt.ui.buildpath.dialog.MaterializeLibraryDialog.<init>(MaterializeLibraryDialog.java:102)
> at org.jboss.tools.common.jdt.ui.buildpath.handlers.MaterializeLibraryHandler.execute(MaterializeLibraryHandler.java:80)
> at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:290)
> at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
> ... 37 more{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
12 years, 7 months
[JBoss JIRA] (TOOLSDOC-386) Review: Devs to review Maven Tools content spec
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/TOOLSDOC-386?page=com.atlassian.jira.plug... ]
Fred Bricon commented on TOOLSDOC-386:
--------------------------------------
{quote}...for building and managing Java-based projects;{quote}
No, maven is not restricted to building java projects. It can actually build any kind of project (flex, groovy, docs ...)
{quote}• What Maven support is already in eclipse? m2e, m2e-wtp{quote}
m2e provides Java support, Dependency management, a POM editor and most importantly is a platform for other eclipse plugins to provide support for different maven plugins and technologies (android, groovy, ...).
m2e-wtp aims at providing a bridge between m2e and Eclipse WTP, in other words, provide easy configuration for JavaEE projects.
{quote}
• Convert Java classpaths to Maven dependencies when convert to Maven project
{quote}
actually, it converts java dependencies (classpath entries for java projects, component references for EARs) to Maven dependencies
{quote}• Ease of specifying Maven profiles on per project basis
{quote}
It's all about profile selection, through a new UI over the existing m2e functionality. We don't add anything to specify/create new profiles.
{quote}
• Ease of specifying Maven profiles on per project basis
• Maven integration for JBoss-specific technologies (Hibernate, Portlet, ...)
{quote}
• Maven integration for JBoss-specific (Hibernate, CDI, Portlet, Seam, JBoss SAR) or 3rd party technologies (GWT)
{quote}• JBoss Maven repository identification
{quote}
• Easy Maven repository management in settings.xml, using a specific UI in the preferences
Also can define new maven repositories to be used for dependency identification or source lookup
Other features (can be filed under Enhanced Maven integration for Java technologies) :
- quick fixes for missing JBoss (project or product) dependencies
- provides support for Endorsed Libraries (libraries that must be declared before other JDK or maven jars. http://docs.jboss.org/tools/whatsnew/maven/maven-news-3.3.0.CR1.html)
- add support for annotation processing (disabled by default http://docs.jboss.org/tools/whatsnew/maven/maven-news-3.3.0.Beta3.html#it...)
Although not related to maven directly (but using m2e's infrastructure) and applicable to any non-maven java projects :
- source lookup for any jar in a project classpath
- source lookup for any jar while debugging, at runtime
{quote}
• Use: Add Maven (M2) capabilities to a Java project, so makes pom.xml and sets up file system structure
for designated output type (JAR, WAR, ...)
{quote}
I wouldn't promote that approach, as it's largely been superceded (but not completely) by m2e's "Convert to Maven" menu. It might still be relevant for Seam projects though. Other use case where the M2 Facet is still relevant is when using maven-based Library providers (JSF, Hibernate).But I personally don't find this approach reliable as it references quickly outdated libraries (hardcoded in JBDS).
Another feature you could mention (though not directly a Maven tool): the ability to materialize _any_ library, as described in http://docs.jboss.org/tools/whatsnew/core/core-news-3.3.0.M4.html, useful if you want to drop maven (or gradle or ivy...)
As for the rest, I believe you're gonna add more details based on existing N&N. Ping me if you need more explanations as you progress.
> Review: Devs to review Maven Tools content spec
> -----------------------------------------------
>
> Key: TOOLSDOC-386
> URL: https://issues.jboss.org/browse/TOOLSDOC-386
> Project: Documentation for JBoss Tools and Developer Studio
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: User Guide - Maven Tools
> Affects Versions: 4.1.0
> Reporter: Michelle Murray
> Assignee: Fred Bricon
> Fix For: 4.2.0
>
> Attachments: MavenTools_contentspec.pdf
>
>
> Please review the content spec of the Maven Tools chapter from a technical viewpoint:
> 1) Is the info about features correct?
> 2) Are any features missing?
> The content spec will be used to write the Maven Tools chapter in the JBDS User Guide. It is important that any issues are resolved before writing starts.
> For ease of tracking by docs, please give feedback as comments in this JIRA. Estimated page and graphics counts will be added by docs later.
> The content spec is available here as a pdf. Alternatively, the content spec is also available at:
> https://mojo.redhat.com/docs/DOC-19224
--
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] (JBDS-2623) Create target platform for mirrored parts of Central / 3rd Party Extras
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-2623?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBDS-2623:
-----------------------------
Attachment: 2623-remove-and-regen.png
2623-manual-hack.png
Thanks to [~mickael_istria], I was able to solve this problem:
First, a manual hack to remove the partial IU in the metadata:
!2623-manual-hack.png!
Then, a more reproduceable solution, which uses p2.remove.iu to remove the offending IU and p2.publish.featuresAndBundles to add it back:
{code}
<p2.remove.iu>
<repository location="file:${workDir}" name="Spring IDE ${version}" format="http://download.jboss.org/jbosstools/updates/requirements/_FORMAT_TEMPLATE_"/>
<iu id="org.datanucleus.ide.eclipse"/>
</p2.remove.iu>
<p2.publish.featuresAndBundles metadataRepository="file:${workDir}" artifactRepository="file:${workDir}" publishartifacts="true" source="${workDir}" compress="true">
<bundles dir="${workDir}/plugins" includes="org.datanucleus.ide.eclipse*"/>
</p2.publish.featuresAndBundles>
{code}
2623-remove-and-regen.png
> Create target platform for mirrored parts of Central / 3rd Party Extras
> -----------------------------------------------------------------------
>
> Key: JBDS-2623
> URL: https://issues.jboss.org/browse/JBDS-2623
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: 3rd-party-certification, 3rd-party-dependencies, central, requirements, updatesite, upstream
> Affects Versions: 7.0.0.Beta1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 7.1.x
>
> Attachments: 2623-manual-hack.png, 2623-remove-and-regen.png
>
>
> As discussed in JBDS-2486 ( https://issues.jboss.org/browse/JBDS-2486?focusedCommentId=12770186&page=... ) we need to produce a target file for use with Central.
> Goal here would be to build the Extras site (used by Central) as a TP update site rather than a composite of mirrors, which would provide us with a manifest of exactly which versions of these duped IUs were to be contained in the Extras site. If something bad happens, we can add duplicate versions of IUs to the TP and know exactly why we include both Jetty 8.1.3 and 8.1.9 (for example) or two different spins of WindowBuilder. This would mean it wouldn't matter if we filtered content out of the mirrors, because we'd be handling the filtering in a single place (extras.target) rather than multiple build.xml files.
> In future, we would:
> * mirror the individual upstream projects into /updates/requirements/<project> [on dl.jb.org]
> * mirror the individual upstream projects into /updates/requirements/<project> [on www.qa]
> * produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on dl.jb.org]
> * produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on www.qa]
> * produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on ds.jb.com]
> * add a whole new aggregate for old + new content
--
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] (JBDS-2623) Create target platform for mirrored parts of Central / 3rd Party Extras
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-2623?page=com.atlassian.jira.plugin.... ]
Nick Boldt edited comment on JBDS-2623 at 9/13/13 12:36 PM:
------------------------------------------------------------
Thanks to [~mickael_istria], I was able to solve this problem:
First, a manual hack to remove the partial IU in the metadata:
!2623-manual-hack.png!
Then, a more reproduceable solution, which uses p2.remove.iu to remove the offending IU and p2.publish.featuresAndBundles to add it back:
{code}
<p2.remove.iu>
<repository location="file:${workDir}" name="Spring IDE ${version}" format="http://download.jboss.org/jbosstools/updates/requirements/_FORMAT_TEMPLATE_"/>
<iu id="org.datanucleus.ide.eclipse"/>
</p2.remove.iu>
<p2.publish.featuresAndBundles metadataRepository="file:${workDir}" artifactRepository="file:${workDir}" publishartifacts="true" source="${workDir}" compress="true">
<bundles dir="${workDir}/plugins" includes="org.datanucleus.ide.eclipse*"/>
</p2.publish.featuresAndBundles>
{code}
!2623-remove-and-regen.png!
was (Author: nickboldt):
Thanks to [~mickael_istria], I was able to solve this problem:
First, a manual hack to remove the partial IU in the metadata:
!2623-manual-hack.png!
Then, a more reproduceable solution, which uses p2.remove.iu to remove the offending IU and p2.publish.featuresAndBundles to add it back:
{code}
<p2.remove.iu>
<repository location="file:${workDir}" name="Spring IDE ${version}" format="http://download.jboss.org/jbosstools/updates/requirements/_FORMAT_TEMPLATE_"/>
<iu id="org.datanucleus.ide.eclipse"/>
</p2.remove.iu>
<p2.publish.featuresAndBundles metadataRepository="file:${workDir}" artifactRepository="file:${workDir}" publishartifacts="true" source="${workDir}" compress="true">
<bundles dir="${workDir}/plugins" includes="org.datanucleus.ide.eclipse*"/>
</p2.publish.featuresAndBundles>
{code}
2623-remove-and-regen.png
> Create target platform for mirrored parts of Central / 3rd Party Extras
> -----------------------------------------------------------------------
>
> Key: JBDS-2623
> URL: https://issues.jboss.org/browse/JBDS-2623
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: 3rd-party-certification, 3rd-party-dependencies, central, requirements, updatesite, upstream
> Affects Versions: 7.0.0.Beta1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 7.1.x
>
> Attachments: 2623-manual-hack.png, 2623-remove-and-regen.png
>
>
> As discussed in JBDS-2486 ( https://issues.jboss.org/browse/JBDS-2486?focusedCommentId=12770186&page=... ) we need to produce a target file for use with Central.
> Goal here would be to build the Extras site (used by Central) as a TP update site rather than a composite of mirrors, which would provide us with a manifest of exactly which versions of these duped IUs were to be contained in the Extras site. If something bad happens, we can add duplicate versions of IUs to the TP and know exactly why we include both Jetty 8.1.3 and 8.1.9 (for example) or two different spins of WindowBuilder. This would mean it wouldn't matter if we filtered content out of the mirrors, because we'd be handling the filtering in a single place (extras.target) rather than multiple build.xml files.
> In future, we would:
> * mirror the individual upstream projects into /updates/requirements/<project> [on dl.jb.org]
> * mirror the individual upstream projects into /updates/requirements/<project> [on www.qa]
> * produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on dl.jb.org]
> * produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on www.qa]
> * produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on ds.jb.com]
> * add a whole new aggregate for old + new content
--
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-15151) NullPointerException reported in Eclipse Error view after using "Materialize Library..." on uninitialized classpath container
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15151?page=com.atlassian.jira.plugi... ]
Denis Golovin updated JBIDE-15151:
----------------------------------
Attachment: JBIDE-15363.ogv
Look in [^JBIDE-15363.ogv] how to replicate issue
> NullPointerException reported in Eclipse Error view after using "Materialize Library..." on uninitialized classpath container
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15151
> URL: https://issues.jboss.org/browse/JBIDE-15151
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: common/jst/core, maven
> Reporter: Denis Golovin
> Assignee: Fred Bricon
> Fix For: 4.2.0.Alpha1
>
> Attachments: JBIDE-15363.ogv
>
>
> {code}
> org.eclipse.e4.core.di.InjectionException: java.lang.NullPointerException
> at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:63)
> at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:243)
> at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:224)
> at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
> at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:167)
> at org.eclipse.core.commands.Command.executeWithChecks(Command.java:499)
> at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
> at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:213)
> at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.executeItem(HandledContributionItem.java:850)
> at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.handleWidgetSelection(HandledContributionItem.java:743)
> at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.access$7(HandledContributionItem.java:727)
> at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem$4.handleEvent(HandledContributionItem.java:662)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1392)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3742)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3363)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:138)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:610)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
> Caused by: java.lang.NullPointerException
> at org.jboss.tools.common.jdt.ui.buildpath.dialog.MaterializeLibraryDialog.<init>(MaterializeLibraryDialog.java:102)
> at org.jboss.tools.common.jdt.ui.buildpath.handlers.MaterializeLibraryHandler.execute(MaterializeLibraryHandler.java:80)
> at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:290)
> at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
> ... 37 more{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
12 years, 7 months
[JBoss JIRA] (JBIDE-14929) Verbose application type type dissapears after refreshing the connection
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14929?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-14929:
------------------------------------------
Clayton answered on the mailing list that the cartridges may get included in the response by including an additional request parameter:
{quote}
?include=cartridges
{quote}
This produces a response that includes the application and the full-blown description of its cartridges:
{code}
{
{
"api_version":1.2,
"data":{
"aliases":[
],
"app_url":"http://ticketmonst-foobarz.rhcloud.com/",
"build_job_url":null,
"building_app":"jenkins",
"building_with":null,
"cartridges":[
{
"additional_gear_storage":0,
"base_gear_storage":1,
"collocated_with":[
],
"current_scale":1,
"description":"The leading open source Java EE6 application server for enterprise Java applications. Popular development frameworks include Seam, CDI, Weld, and Spring.",
"display_name":"JBoss Application Server 7",
...
"website":"http://www.jboss.org"
}
],
"creation_time":"2013-09-09T13:18:56Z",
"domain_id":"foobarz",
"embedded":{
},
"framework":"jbossas-7",
"gear_count":1,
...
],
"type":"application",
"version":"1.2"
}
{code}
> Verbose application type type dissapears after refreshing the connection
> ------------------------------------------------------------------------
>
> Key: JBIDE-14929
> URL: https://issues.jboss.org/browse/JBIDE-14929
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.0.Beta2
> Reporter: Stefan Bunciak
> Assignee: Andre Dietisheim
> Priority: Minor
> Fix For: 4.2.x
>
> Attachments: shorthand-label.png, type1.png, type2.png, verbose-application-type.png
>
>
> !type1.png! -> !type2.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