[JBoss JIRA] (JBDS-2733) Make Cordova tooling and CordovaSim available from software/update tab
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-2733?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-2733:
-------------------------------------------
Why do you want them to be separate ? Why not just one "Cordova Tooling" and then you can unselect either cordovasim or the cordova project tooling ?
These two are interdependent. I don't see how this maps to unique/separate runtime/platforms ?
> Make Cordova tooling and CordovaSim available from software/update tab
> -----------------------------------------------------------------------
>
> Key: JBDS-2733
> URL: https://issues.jboss.org/browse/JBDS-2733
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: aerogear-hybrid, requirements
> Reporter: Burr Sutter
> Assignee: Nick Boldt
>
> Cordova should be available from JBDS, but it is not fully supported tech yet thus should be included/marked as a Technology Preview
--
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, 8 months
[JBoss JIRA] (JBIDE-15388) Compute whether to publish or not based on output signature rather than commits
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15388?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-15388:
---------------------------------------------
since the zip has date/timestamps in some of its files you can't do that kind of comparison can you ?
> Compute whether to publish or not based on output signature rather than commits
> -------------------------------------------------------------------------------
>
> Key: JBIDE-15388
> URL: https://issues.jboss.org/browse/JBIDE-15388
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: LATER
>
>
> [Assuming we already have reproducible qualifiers...]
> Currently, the CI jobs publish the output of a build if a change was detected in the Git repo since last publication.
> However there are some case not correctly supported:
> * Job configuration changed and caused changes in build output. In that case, we would like build output to be re-published, but it won't happen
> * Job source changed but not build output (eg a change in a pom.xml or any non-included file), then we don't need to republish output whereas current mechanism would republish it.
> instead, it would make sense to compare what's already published and what is to publish in order to decide or not whether this has to be published. Looking at signatures of update site zip would probably be enough.
--
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, 8 months
[JBoss JIRA] (JBIDE-15467) should JBT have a category for "stuff not in Abridged" ?
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15467?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-15467:
---------------------------------------------
+1
> should JBT have a category for "stuff not in Abridged" ?
> --------------------------------------------------------
>
> Key: JBIDE-15467
> URL: https://issues.jboss.org/browse/JBIDE-15467
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, updatesite
> Affects Versions: 4.1.1.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.1.1.Alpha2
>
> Attachments: 15467.png
>
>
> The Marketplace entry for JBT includes all the features in the "Abridged JBoss Tools" category, but there are a number of features not included therein.
> So for those users installing from the update site itself, not the Marketplace, should these be grouped into a single category, perhaps called "Additional JBoss Tools"?
> {code}
> org.jboss.tools.arquillian.feature
> org.jboss.tools.common.mylyn.feature
> org.jboss.tools.gwt.feature
> org.jboss.tools.maven.gwt.feature
> org.jboss.tools.aerogear.hybrid.feature
> org.jboss.tools.vpe.cordovasim.feature
> org.jboss.tools.central.themes.feature
> org.jboss.tools.birt.feature
> org.jboss.tools.forge.ext.feature
> {code}
> Added bonus (from a releng P.O.V., not an end user one) is that having such a category would make it easier to maintain the full list of features to be included in these job configs, to ensure we're properly doing full JBT co-installation testing:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite...
> [~burrsutter] [~maxandersen] [~koen.aers] [~gercan] WDYT?
--
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, 8 months
[JBoss JIRA] (JBIDE-15457) CordovaSim and Hybrid tools interaction/source code sharing
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15457?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-15457:
---------------------------------------------
[~burrsutter] not following what engineering promotion have to do with it. in past we wanted to promote standalone browsersim but it was shutdown as "not important" :)
The question here is if there is a need/usecase for running browsersim externally that outweighs the cost of doing so - and right now I and as far as I can see [~gercan] don't see such a need.
Thus I would vote for launching the server side parts inside eclipse, but keeping the dependencies and API clean so it is clear where this running. If it is kept clean a user can run his own http server to provide the cordova parts which cordovasim could run against.
> CordovaSim and Hybrid tools interaction/source code sharing
> -----------------------------------------------------------
>
> Key: JBIDE-15457
> URL: https://issues.jboss.org/browse/JBIDE-15457
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: aerogear-hybrid, browsersim
> Reporter: Yahor Radtsevich
> Assignee: Yahor Radtsevich
> Fix For: 4.2.x
>
>
> Currently CordovaSim application consists of two parts: a Jetty-based server, and a BrowserSim-based client. The server part generates some content on the fly. For instance, the server may response with generated {{cordova_plugins.js}} content when it is requested by the client. Both parts of CordovaSim are executed in their own JVM, which means they do not have access to the Eclipse API.
> Hybrid tools do very similar things, but in static way. For instance, while creating Android executables, they create {{cordova_plugins.js}} file on disk. Hybrid tools is a set of Eclipse plugins, so they have access to the Eclipse API.
> Obviously CordovaSim and Hybrid tools have some code in their sources that could be shared. For the example above, both of them need a method to generate content of {{cordova_plugins.js}}. There are several approaches to implement it:
> 1. Create two different implementations for CordovaSim and Hybrid tools and synchronize them when needed (currently we do this). This approach creates code duplication problems.
> 2. Create an Eclipse API-independent plugin, so both CordovaSim and Hybrid tools could set it as a dependency. This approach imposes some restriction on the independent plugin (useful Eclipse API and libs cannot be used).
> 3. Move the server part of CordovaSim to the Eclipse JVM, so it could use Eclipse API and any Hybrid tools API. With this approach we loose the ability to create standalone CordovaSim in the future.
--
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, 8 months
[JBoss JIRA] (JBDS-2745) Support installation of Early Access / Experimental / Incubating plugins
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-2745?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-2745:
-------------------------------------------
Yes they can have a version's but which can be mixed in without breaking setup....and if something is broken how does users revert/uninstall again.
hopefully p2 remediation will help here but I'm sure that there will be installation cases we cannot support well (i.e. installing newer version of Central would be tricky :)
> Support installation of Early Access / Experimental / Incubating plugins
> ------------------------------------------------------------------------
>
> Key: JBDS-2745
> URL: https://issues.jboss.org/browse/JBDS-2745
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: central, requirements
> Affects Versions: 7.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Burr Sutter
>
> It's been suggested that it would be nice to have Central available to install non-GA content. How might this appear?
> [~burrsutter], [~maxandersen], are we talking about:
> * an additional dialog warning users about untested content? (that might be ignored / blindclicked)
> * an additional tab in Central for this type of content (what label would you use?)
> * relabelling the content's feature descriptions / titles / copyright / license terms to be clear it's unstable content? (might be ignored)
> * some other workflow?
> See also JBDS-2068.
--
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, 8 months
[JBoss JIRA] (JBIDE-15203) Error publishing html files to WildFly on Windows (WildFly locks deployed files)
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15203?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen resolved JBIDE-15203.
-----------------------------------------
Resolution: Rejected
marking as rejected since it was an upstream bug and fix not related to any specific version of JBIDE.
> Error publishing html files to WildFly on Windows (WildFly locks deployed files)
> --------------------------------------------------------------------------------
>
> Key: JBIDE-15203
> URL: https://issues.jboss.org/browse/JBIDE-15203
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server, upstream
> Affects Versions: 4.1.0.CR1
> Environment: Win 7
> Reporter: Fred Bricon
> Assignee: Fred Bricon
> Priority: Blocker
> Fix For: 4.0.0.Final
>
>
> Created a simple maven web app, deployed onto a WildFly 8.0.0.Alpha2. The edited an index.html file and got
> {noformat}
> Error renaming D:\Dev\servers\wildfly-8.0.0.Alpha2\standalone\tmp\tmp8284536747609996823.html to D:\Dev\servers\wildfly-8.0.0.Alpha2\standalone\deployments\w.war\index.html.
> This may be caused by your server's temporary deploy directory being on a different filesystem than the final destination.
> You may adjust these settings in the server editor.
> {noformat}
> Obviously the filesystem is identical.
--
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, 8 months
[JBoss JIRA] (JBDS-2719) Multiple Spring AOP problems when travel example is imported
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBDS-2719?page=com.atlassian.jira.plugin.... ]
Fred Bricon commented on JBDS-2719:
-----------------------------------
I can't reproduce using a simpler project, so it must be something really tricky in our spring projects setup (same issue with the petclinic example). Gonna need to debug Spring IDE
> Multiple Spring AOP problems when travel example is imported
> ------------------------------------------------------------
>
> Key: JBDS-2719
> URL: https://issues.jboss.org/browse/JBDS-2719
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: 3rd-party-certification
> Affects Versions: 7.0.0.GA
> Environment: JBDS 7.0.0.GA, L64, Spring IDE 3.3 installed from JBoss Central
> Reporter: Jiri Peterka
> Assignee: Rodney Russ
> Fix For: 7.1.0.Alpha2
>
>
> There are Multiple Spring AOP Errors after travel example is imported:
> {code}
> Build path is incomplete. Cannot find class file for org/aspectj/weaver/reflect/ReflectionWorld$ReflectionWorldException
> {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, 8 months
[JBoss JIRA] (JBDS-2763) REBRANDING: should JBDS 7.1 installer window be labelled "Red Hat JBoss Developer Studio" instead of "JBoss Developer Studio" ? Should jar file & feature names change too?
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-2763?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-2763:
-------------------------------------------
to be clear - What I want to avoid is that users of 1024x resolution need to resize our windows to read the product name ;)
> REBRANDING: should JBDS 7.1 installer window be labelled "Red Hat JBoss Developer Studio" instead of "JBoss Developer Studio" ? Should jar file & feature names change too?
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBDS-2763
> URL: https://issues.jboss.org/browse/JBDS-2763
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: build, installer
> Affects Versions: 7.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Max Rydahl Andersen
> Attachments: 2763_3_places.png, 2763_cmdline.png
>
>
> Wondering if it's time to rebrand JBDS 7.1 so that its installer window is labelled "Red Hat JBoss Developer Studio" instead of "JBoss Developer Studio" ?
> !https://issues.jboss.org/secure/attachment/12364502/12364502_ins-step-5.png!
> Should we also rename the jbdevstudio-**.jar files to rhjbdevstudio-**.jar?
> What about features like com.jboss.jbds.product.feature, which currently appear as "JBoss Developer Studio (Core Features)" when installed. Should that too move to "Red Hat JBoss Developer Studio (Core Features)" ?
--
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, 8 months