[JBoss JIRA] (JBIDE-14416) RuntimeExtensionManager.findDownloadRuntime.only checking for string array, not single string
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14416?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-14416.
---------------------------------
Resolution: Done
pushed to master. A test of this can be found in astools, though I admit another test in runtiems would be appropriate.
> RuntimeExtensionManager.findDownloadRuntime.only checking for string array, not single string
> ---------------------------------------------------------------------------------------------
>
> Key: JBIDE-14416
> URL: https://issues.jboss.org/browse/JBIDE-14416
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection
> Affects Versions: 4.1.0.Beta1
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.1.0.Beta1
>
>
> RuntimeExtensionManager.findDownloadRuntime is a new internal method (with a public api in the runtime core activator) to find downloadRuntime objects of a specific id.
> It's introduced to be able to find downloadRuntimes that may have legacy id's or newer id's, ie, multiple ids.
> Currently it's assuming the property set is a String[], but if a client only sets a single string, it is not finding that element.
--
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, 11 months
[JBoss JIRA] (JBIDE-14416) RuntimeExtensionManager.findDownloadRuntime.only checking for string array, not single string
by Rob Stryker (JIRA)
Rob Stryker created JBIDE-14416:
-----------------------------------
Summary: RuntimeExtensionManager.findDownloadRuntime.only checking for string array, not single string
Key: JBIDE-14416
URL: https://issues.jboss.org/browse/JBIDE-14416
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: runtime-detection
Affects Versions: 4.1.0.Beta1
Reporter: Rob Stryker
Assignee: Rob Stryker
Fix For: 4.1.0.Beta1
RuntimeExtensionManager.findDownloadRuntime is a new internal method (with a public api in the runtime core activator) to find downloadRuntime objects of a specific id.
It's introduced to be able to find downloadRuntimes that may have legacy id's or newer id's, ie, multiple ids.
Currently it's assuming the property set is a String[], but if a client only sets a single string, it is not finding that element.
--
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, 11 months
[JBoss JIRA] (JBIDE-14415) Add unit tests for legacy downloadRuntime id's
by Rob Stryker (JIRA)
Rob Stryker created JBIDE-14415:
-----------------------------------
Summary: Add unit tests for legacy downloadRuntime id's
Key: JBIDE-14415
URL: https://issues.jboss.org/browse/JBIDE-14415
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: runtime-detection, server
Affects Versions: 4.1.0.Beta1
Reporter: Rob Stryker
Assignee: Rob Stryker
Fix For: 4.1.0.Beta1
Legacy id's are used by central and project examples. This requires unit tests to ensure that calls to find those downloadRuntime objects has not changed or broken in any way.
--
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, 11 months
[JBoss JIRA] (JBIDE-14414) ECFTransport fails on many platform urls
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14414?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-14414:
-------------------------------------
PR is located at https://github.com/jbosstools/jbosstools-base/pull/102
But since it's for a different jira, not asking for approval here.
> ECFTransport fails on many platform urls
> ----------------------------------------
>
> Key: JBIDE-14414
> URL: https://issues.jboss.org/browse/JBIDE-14414
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: common/jst/core
> Affects Versions: 4.1.0.Beta1
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.1.0.Beta1
>
>
> While making some new test cases, I discovered that the class fails badly (I experienced a deadlock I mentioned in email when using a bundleentry url) and did not have any support for urls that the class LOOKS like it supports.
> Support needs to be enhanced for this.
> I'm making tests in the new potential "core", and I do not wish to make temporary tests in 'common' before we move the class, so for now I will only be committing this to my 'creation of core' topic branch.
--
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, 11 months
[JBoss JIRA] (JBIDE-14414) ECFTransport fails on many platform urls
by Rob Stryker (JIRA)
Rob Stryker created JBIDE-14414:
-----------------------------------
Summary: ECFTransport fails on many platform urls
Key: JBIDE-14414
URL: https://issues.jboss.org/browse/JBIDE-14414
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: common/jst/core
Affects Versions: 4.1.0.Beta1
Reporter: Rob Stryker
Assignee: Rob Stryker
Fix For: 4.1.0.Beta1
While making some new test cases, I discovered that the class fails badly (I experienced a deadlock I mentioned in email when using a bundleentry url) and did not have any support for urls that the class LOOKS like it supports.
Support needs to be enhanced for this.
I'm making tests in the new potential "core", and I do not wish to make temporary tests in 'common' before we move the class, so for now I will only be committing this to my 'creation of core' topic branch.
--
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, 11 months
[JBoss JIRA] (JBIDE-13977) updates/requirements/*/build.xml scripts should include pack.gz artifacts (using p2.process.artifacts pack="true") to make resolving multiple.target faster
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13977?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-13977 at 5/10/13 1:18 PM:
-------------------------------------------------------------
As mentioned (incorrectly) over on JBIDE-13266... found a new problem.
If you mirror, gen metadata, then pack, you end up with metadata based on any packed artifacts you pulled down from eclipse.org... NOT metadata for those you REGENERATED via pack200.
And because pack200 sucks (or JDKs are different on eclipse.org vs. on www.qa, whatever) there's a chance that the NEW packed jar will have a different MD5 sum than the one that was previously fetched and pushed into the metadata.
So you might end up with this:
{code}
"MD5 hash is not as expected. Expected: c7e232e42e6fa41dc60dd5336d38a311 and found 4b89fe64fa8b13bd1de2082e59275482."]], "Artifact not found: packed: osgi.bundle,org.eclipse.wst.doc.user,1.2.0.v200806052254."
{code}
And because tycho can't seem to deal with this by falling back to the UNPACKED jar, the provisioning / build fails utterly. #sadPanda
So... I'm thinking the workaround here is to ensure that we run <p2.publish.featuresAndBundles> AFTER packing.
Not sure if we have to run it before and after; going to assume there's no harm in ONLY doing after. Testing that now for the wtp 3.5M7 site.
Alternatively, if we could tell <p2.process.artifacts> to only generate packed artifacts for things which don't already exist, that'd be great. Unfortunately the only supported filter mechanism is to nest a list of <feature> and <plugin> entries, which isn't as much fun as it sounds.
was (Author: nickboldt):
As mentioned (incorrectly) over on JBIDE-13266... found a new problem.
If you mirror, gen metadata, then pack, you end up with metadata based on any packed artifacts you pulled down from eclipse.org... NOT metadata for those you REGENERATED via pack200.
And because pack200 sucks (or JDKs are different on eclipse.org vs. on www.qa, whatever) there's a chance that the NEW packed jar will have a different MD5 sum than the one that was previously fetched and pushed into the metadata.
So... I'm thinking the workaround here is to ensure that we run <p2.publish.featuresAndBundles> AFTER packing.
Not sure if we have to run it before and after; going to assume there's no harm in ONLY doing after. Testing that now for the wtp 3.5M7 site.
Alternatively, if we could tell <p2.process.artifacts> to only generate packed artifacts for things which don't already exist, that'd be great. Unfortunately the only supported filter mechanism is to nest a list of <feature> and <plugin> entries, which isn't as much fun as it sounds.
> updates/requirements/*/build.xml scripts should include pack.gz artifacts (using p2.process.artifacts pack="true") to make resolving multiple.target faster
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-13977
> URL: https://issues.jboss.org/browse/JBIDE-13977
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng, target-platform, updatesite, upstream
> Affects Versions: 4.1.0.Alpha2
> Reporter: Nick Boldt
> Assignee: Mickael Istria
> Fix For: 4.1.0.Beta1
>
>
> All ant scripts (updates/requirements/*/build.xml) used to mirror 3rd party reqs from Eclipse.org and other places should be updated to generate .pack.gz artifacts too.
> {code}<p2.process.artifacts pack="true" repositoryPath="file:/${repoDirLocation}" />{code}
> Refs:
> * http://git.eclipse.org/c/platform/eclipse.platform.releng.eclipsebuilder....
> * http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc....
--
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, 11 months
[JBoss JIRA] (JBIDE-13977) updates/requirements/*/build.xml scripts should include pack.gz artifacts (using p2.process.artifacts pack="true") to make resolving multiple.target faster
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13977?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-13977:
------------------------------------
As mentioned (incorrectly) over on JBIDE-13266... found a new problem.
If you mirror, gen metadata, then pack, you end up with metadata based on any packed artifacts you pulled down from eclipse.org... NOT metadata for those you REGENERATED via pack200.
And because pack200 sucks (or JDKs are different on eclipse.org vs. on www.qa, whatever) there's a chance that the NEW packed jar will have a different MD5 sum than the one that was previously fetched and pushed into the metadata.
So... I'm thinking the workaround here is to ensure that we run <p2.publish.featuresAndBundles> AFTER packing.
Not sure if we have to run it before and after; going to assume there's no harm in ONLY doing after. Testing that now for the wtp 3.5M7 site.
Alternatively, if we could tell <p2.process.artifacts> to only generate packed artifacts for things which don't already exist, that'd be great. Unfortunately the only supported filter mechanism is to nest a list of <feature> and <plugin> entries, which isn't as much fun as it sounds.
> updates/requirements/*/build.xml scripts should include pack.gz artifacts (using p2.process.artifacts pack="true") to make resolving multiple.target faster
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-13977
> URL: https://issues.jboss.org/browse/JBIDE-13977
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng, target-platform, updatesite, upstream
> Affects Versions: 4.1.0.Alpha2
> Reporter: Nick Boldt
> Assignee: Mickael Istria
> Fix For: 4.1.0.Beta1
>
>
> All ant scripts (updates/requirements/*/build.xml) used to mirror 3rd party reqs from Eclipse.org and other places should be updated to generate .pack.gz artifacts too.
> {code}<p2.process.artifacts pack="true" repositoryPath="file:/${repoDirLocation}" />{code}
> Refs:
> * http://git.eclipse.org/c/platform/eclipse.platform.releng.eclipsebuilder....
> * http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc....
--
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, 11 months
[JBoss JIRA] (JBIDE-14413) AS Runtime Detection links to custom random github stacks.yaml! FIX!
by Rob Stryker (JIRA)
Rob Stryker created JBIDE-14413:
-----------------------------------
Summary: AS Runtime Detection links to custom random github stacks.yaml! FIX!
Key: JBIDE-14413
URL: https://issues.jboss.org/browse/JBIDE-14413
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: runtime-detection, server
Affects Versions: 4.1.0.Beta1
Reporter: Rob Stryker
Assignee: Rob Stryker
Fix For: 4.1.0.Beta1
It is not appropriate to link to a temporary github file. THis must be changed.
Possible solution: Bundling our own (yes thats dumb but it is equivilent to using extension points in terms of speed) or waiting on jdf.
--
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, 11 months