[JBoss JIRA] (JBIDE-19410) earlyaccess still not failing gracefully
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19410?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-19410:
---------------------------------------------
"Profile id SELF is not registered" is not anything anyone outside p2 masterminds would grok what is missing. Why not just report as is "p2 installation and update not enabled for this product." and then leave the meaningless for most other as details in the error log ?
Even better, dont log it. P2 does not log this either before its actually tried to be used.
> earlyaccess still not failing gracefully
> ----------------------------------------
>
> Key: JBIDE-19410
> URL: https://issues.jboss.org/browse/JBIDE-19410
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central
> Reporter: Max Rydahl Andersen
> Assignee: Mickael Istria
> Priority: Minor
> Fix For: 4.3.0.Alpha2
>
>
> start jboss tools in PDE and earlyaccess will pop up with error dialog that it had an error because it could not install things (which is expected when running in PDE)
> start jboss tools without network access and I sometime see it pop up - can't reprouce that consistently.
> but in short - seems like earlyaccess continues to want to tell users that something is wrong with early access even when it is not enabled but nor should it even if enabled. Show such error on the earlyaccess page rather than a blocking dialog.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBIDE-19507) Search and rename participants for Batch Artifacts
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19507?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-19507:
---------------------------------------------
very nice description and looks like a great feature /cc [~ArunGupta]
> Search and rename participants for Batch Artifacts
> --------------------------------------------------
>
> Key: JBIDE-19507
> URL: https://issues.jboss.org/browse/JBIDE-19507
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: batch
> Reporter: Daniel Azarov
> Assignee: Daniel Azarov
> Labels: new_and_noteworthy
> Fix For: 4.3.0.Alpha2
>
> Attachments: BatchArtifactRename.png, ExceptionRename.png, FieldReference.png, PropertyRename.png, SearchableBatchletReferences.png, SearchableExceptionReferences.png
>
>
> *Search Participant*
> 1. Should be able to find references in job.xml files for Batch Artifact Class IType
> Example:
> During the search for references for class "SearchableBatchlet" like:
> {code}
> package batch;
> import javax.batch.api.BatchProperty;
> import javax.batch.api.Batchlet;
> import javax.inject.Inject;
> import javax.inject.Named;
> @Named
> public class SearchableBatchlet implements Batchlet {
>
> @Inject @BatchProperty(name="secondName") String otherName;
> @Override
> public String process() throws Exception {
> return null;
> }
> @Override
> public void stop() throws Exception {
> }
> }
> {code}
> In the search result should be added references in jbob.xml files like this:
> !SearchableBatchletReferences.png!
> 2. Should be able to find references in job.xml files for Batch Artifact Property IField
> Example:
> During the search for references for field "otherName" of class "SearchableBatchlet" in the search result should be added references in jbob.xml files like this:
> !FieldReference.png!
> 3. Should be able to find references in job.xml files for Exception Class IType
> Example:
> During the search for references for class "SearchableException" like:
> {code}
> package batch;
> public class SearchableException extends Exception{
> private static final long serialVersionUID = 1L;
> }
> {code}
> In the search result should be added references in jbob.xml files like this:
> !SearchableExceptionReferences.png!
> *Rename Participant*
> 1. Should be able to add changes in Batch Artifact Class Rename for references in job.xml files.
> Note: Rename Participant does make sense only for Batch Artifacts which name comes from Java Class Name, not from annotation @Named
> Example:
> During rename of class "SearchableBatchlet" changes for job.xml references should be added in Refactoring:
> !BatchArtifactRename.png!
> 2. Should be able to add changes in Batch Property Rename for references in job.xml files.
> Note: Rename Participant does make sense only for Batch Properties which name comes from Java Field Name, not from annotation @BatchProperty
> Example:
> {code}
> package batch;
> import javax.batch.api.BatchProperty;
> import javax.batch.api.Batchlet;
> import javax.inject.Inject;
> import javax.inject.Named;
> @Named
> public class RenamablePropertyBatchlet implements Batchlet {
>
> @Inject @BatchProperty String otherName;
> @Override
> public String process() throws Exception {
> return null;
> }
> @Override
> public void stop() throws Exception {
> }
> }
> {code}
> During rename of field "otherName" changes for job.xml references should be added in Refactoring:
> !PropertyRename.png!
> 3. Should be able to add changes in Exception Class Rename for references in job.xml files.
> Example:
> During rename of class "SearchableException" changes for job.xml references should be added in Refactoring:
> !ExceptionRename.png!
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBDS-3394) Use cordova platform downloads from npm
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3394?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3394:
-------------------------------------------
for some reason this had empty release - now fixed so the CDW kicks in.
> Use cordova platform downloads from npm
> ---------------------------------------
>
> Key: JBDS-3394
> URL: https://issues.jboss.org/browse/JBDS-3394
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: aerogear-hybrid
> Reporter: Gorkem Ercan
> Assignee: Gorkem Ercan
> Fix For: 9.0.0.Alpha2
>
>
> Switch to downloading the cordova platforms from npm and as a consequence limit the downloadable platform versions to what is available on npm. The plan is to continue to support building applications for Cordova version>3.0.0 but when a developer wants to download a cordova platform using JBDS/JBT, only versions 3.5.0 and later will be available. Configuring a manually downloaded cordova platforms on JBDS will still be available.
> Around Cordova 3.5.0 time, Apache Cordova project switched to using npm for distributing cordova platforms. npm provides a much better infrastructure compared to the old way which is basically git archive mechanism. We already had cases where apache infrastructure was not available for maintenance. Also the lack of CDN does not help either. So I think JBDS should follow Apache Cordova and start using npm for downloading cordova platforms. Below are the list of relevant cordova platforms and version that are available today from npm.
> cordova-ios
> ['3.5.0', '3.6.0', '3.6.1', '3.6.3', '3.7.0', '3.8.0' ]
> cordova-android
> [ '3.5.0','3.5.1','3.6.0','3.6.1','3.6.3','3.6.4','3.7.0','3.7.1' ]
> cordova-wp8
> [ '3.5.0','3.6.0-dev','3.6.0','3.6.1','3.6.3','3.6.4','3.7.0-dev','3.7.0','3.7.1' ]
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBDS-3394) Use cordova platform downloads from npm
by CDW Engine (JIRA)
[ https://issues.jboss.org/browse/JBDS-3394?page=com.atlassian.jira.plugin.... ]
CDW Engine reassigned JBDS-3394:
--------------------------------
> Use cordova platform downloads from npm
> ---------------------------------------
>
> Key: JBDS-3394
> URL: https://issues.jboss.org/browse/JBDS-3394
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: aerogear-hybrid
> Reporter: Gorkem Ercan
> Assignee: Gorkem Ercan
> Fix For: 9.0.0.Alpha2
>
>
> Switch to downloading the cordova platforms from npm and as a consequence limit the downloadable platform versions to what is available on npm. The plan is to continue to support building applications for Cordova version>3.0.0 but when a developer wants to download a cordova platform using JBDS/JBT, only versions 3.5.0 and later will be available. Configuring a manually downloaded cordova platforms on JBDS will still be available.
> Around Cordova 3.5.0 time, Apache Cordova project switched to using npm for distributing cordova platforms. npm provides a much better infrastructure compared to the old way which is basically git archive mechanism. We already had cases where apache infrastructure was not available for maintenance. Also the lack of CDN does not help either. So I think JBDS should follow Apache Cordova and start using npm for downloading cordova platforms. Below are the list of relevant cordova platforms and version that are available today from npm.
> cordova-ios
> ['3.5.0', '3.6.0', '3.6.1', '3.6.3', '3.7.0', '3.8.0' ]
> cordova-android
> [ '3.5.0','3.5.1','3.6.0','3.6.1','3.6.3','3.6.4','3.7.0','3.7.1' ]
> cordova-wp8
> [ '3.5.0','3.6.0-dev','3.6.0','3.6.1','3.6.3','3.6.4','3.7.0-dev','3.7.0','3.7.1' ]
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBDS-3394) Use cordova platform downloads from npm
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3394?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen updated JBDS-3394:
--------------------------------------
Target Release: 9.0.0.GA
> Use cordova platform downloads from npm
> ---------------------------------------
>
> Key: JBDS-3394
> URL: https://issues.jboss.org/browse/JBDS-3394
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: aerogear-hybrid
> Reporter: Gorkem Ercan
> Assignee: Gorkem Ercan
> Fix For: 9.0.0.Alpha2
>
>
> Switch to downloading the cordova platforms from npm and as a consequence limit the downloadable platform versions to what is available on npm. The plan is to continue to support building applications for Cordova version>3.0.0 but when a developer wants to download a cordova platform using JBDS/JBT, only versions 3.5.0 and later will be available. Configuring a manually downloaded cordova platforms on JBDS will still be available.
> Around Cordova 3.5.0 time, Apache Cordova project switched to using npm for distributing cordova platforms. npm provides a much better infrastructure compared to the old way which is basically git archive mechanism. We already had cases where apache infrastructure was not available for maintenance. Also the lack of CDN does not help either. So I think JBDS should follow Apache Cordova and start using npm for downloading cordova platforms. Below are the list of relevant cordova platforms and version that are available today from npm.
> cordova-ios
> ['3.5.0', '3.6.0', '3.6.1', '3.6.3', '3.7.0', '3.8.0' ]
> cordova-android
> [ '3.5.0','3.5.1','3.6.0','3.6.1','3.6.3','3.6.4','3.7.0','3.7.1' ]
> cordova-wp8
> [ '3.5.0','3.6.0-dev','3.6.0','3.6.1','3.6.3','3.6.4','3.7.0-dev','3.7.0','3.7.1' ]
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBDS-3394) Use cordova platform downloads from npm
by CDW Engine (JIRA)
[ https://issues.jboss.org/browse/JBDS-3394?page=com.atlassian.jira.plugin.... ]
CDW Engine updated JBDS-3394:
-----------------------------
CDW pm_ack: ?
CDW release: ?
> Use cordova platform downloads from npm
> ---------------------------------------
>
> Key: JBDS-3394
> URL: https://issues.jboss.org/browse/JBDS-3394
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: aerogear-hybrid
> Reporter: Gorkem Ercan
> Assignee: Gorkem Ercan
> Fix For: 9.0.0.Alpha2
>
>
> Switch to downloading the cordova platforms from npm and as a consequence limit the downloadable platform versions to what is available on npm. The plan is to continue to support building applications for Cordova version>3.0.0 but when a developer wants to download a cordova platform using JBDS/JBT, only versions 3.5.0 and later will be available. Configuring a manually downloaded cordova platforms on JBDS will still be available.
> Around Cordova 3.5.0 time, Apache Cordova project switched to using npm for distributing cordova platforms. npm provides a much better infrastructure compared to the old way which is basically git archive mechanism. We already had cases where apache infrastructure was not available for maintenance. Also the lack of CDN does not help either. So I think JBDS should follow Apache Cordova and start using npm for downloading cordova platforms. Below are the list of relevant cordova platforms and version that are available today from npm.
> cordova-ios
> ['3.5.0', '3.6.0', '3.6.1', '3.6.3', '3.7.0', '3.8.0' ]
> cordova-android
> [ '3.5.0','3.5.1','3.6.0','3.6.1','3.6.3','3.6.4','3.7.0','3.7.1' ]
> cordova-wp8
> [ '3.5.0','3.6.0-dev','3.6.0','3.6.1','3.6.3','3.6.4','3.7.0-dev','3.7.0','3.7.1' ]
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (LOCUS-39) Consider using Eclipse Bundle Recipes (EBR)
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/LOCUS-39?page=com.atlassian.jira.plugin.s... ]
Mickael Istria updated LOCUS-39:
--------------------------------
Description:
I've had the opportunity to attend a presentation about EBR, a technology to turn plain jars from Maven as OSGi bunle (generating MANIFEST, source bundle, p2 metadata...). I have the impression that it fits quite nicely most of our Locus bundles, we should consider adopting it.
More background about EBR:
* http://www.eclipse.org/ebr
* http://de.slideshare.net/guw/tasty-recipes-for-osgi-bundles
was:I've had the opportunity to attend a presentation about EBR, a technology to turn plain jars from Maven as OSGi bunle (generating MANIFEST, source bundle, p2 metadata...). I habe the impression that it fits quite nicely most of our Locus bundles, we should consider adopting it.
> Consider using Eclipse Bundle Recipes (EBR)
> -------------------------------------------
>
> Key: LOCUS-39
> URL: https://issues.jboss.org/browse/LOCUS-39
> Project: JBoss Tools Locus
> Issue Type: Enhancement
> Reporter: Mickael Istria
>
> I've had the opportunity to attend a presentation about EBR, a technology to turn plain jars from Maven as OSGi bunle (generating MANIFEST, source bundle, p2 metadata...). I have the impression that it fits quite nicely most of our Locus bundles, we should consider adopting it.
> More background about EBR:
> * http://www.eclipse.org/ebr
> * http://de.slideshare.net/guw/tasty-recipes-for-osgi-bundles
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months