[JBoss JIRA] (JBDS-2719) Multiple Spring AOP problems when travel example is imported
by Joshua Wilson (JIRA)
[ https://issues.jboss.org/browse/JBDS-2719?page=com.atlassian.jira.plugin.... ]
Joshua Wilson commented on JBDS-2719:
-------------------------------------
[~nickboldt] I will need to test several different configurations to confirm my earlier guess. This is what I know so far.
First I would ask that you test with the [Kitchensink-Spring Quickstarts|https://github.com/jboss-developer/jboss-wfk-quickstarts] as I am working to keep them up to date and error free as much as possible. This specific error can be seen in the [kitchensink-spring-matrixvariable|https://github.com/jboss-developer/jbos...] quickstart. The Travel and PetClinic will be kept as close to the original as possible (and I haven't had a chance to update them yet).
With that in mind if I Build (with Eclipse/JBDS) [kitchensink-spring-matrixvariable|https://github.com/jboss-developer/jbos...] in JBDS 7.0.1 with Spring IDE 3.3 installed from JBoss Central, I get the aspectj error. However if I Build while in a standard Eclipse JEE install with JBDS and the stock Spring IDE/STS 3.4 installed, I do NOT get the aspectj error.
In order to truly confirm that adding both "AspectJ Compiler" and "AspectJ Development Tools" will fix the error, I would need to test that on my JBDS 7.0.1/SpringIDE 3.3 set up.
> 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, upstream
> 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: Nick Boldt
> Fix For: 7.1.0.Beta1
>
>
> 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
2 months, 1 week
[JBoss JIRA] (JBIDE-20402) Contribute "Deploy to Openshift" menu in Docker Tools' Image view
by Jeff Cantrill (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20402?page=com.atlassian.jira.plugi... ]
Jeff Cantrill updated JBIDE-20402:
----------------------------------
Attachment: deploy_image.webm
Inital impl
> Contribute "Deploy to Openshift" menu in Docker Tools' Image view
> -----------------------------------------------------------------
>
> Key: JBIDE-20402
> URL: https://issues.jboss.org/browse/JBIDE-20402
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.3.0.Beta2
> Reporter: Fred Bricon
> Assignee: Jeff Cantrill
> Labels: openshift_v3
> Fix For: 4.3.0.CR1
>
> Attachments: deploy image WF.bmml, deploy image WF.png, deployment_config.json, deploy_image.webm, run image - screen 1.png, run image 2.png
>
>
> To make this happen we will need docker tooling to provide:
> * ports
> * env variables
> * volumes
> A user will 'deploy to openshift'...I think they might see portions of the 'run image..' menus that are attached but not all. The workflow would be:
> * Ask user about ports, additional env besides those already provided in the image, volumes,
> * Ask about # of replicas, triggers
> * tag and push image to registry (tag=repo/project/stream)
> ** repo is either assumed to be Dockerhub, or the route to the OS registry
> * create a deploymentConfig for the selected image
> * create a service for the image
> * optionally create a route
> Consider running oc new-app on an image to see what it generates
> ==================================================================
> It's possible to contribute a new menu/handler to the Docker Tooling Images view.
> We'd like to be able to select a Docker image from the Docker tooling view, right-click on it and the "Deploy to Openshift"
> The following infos are required to actually be able to deploy the selected image onto OS:
> - the local docker registry. OS will need a route to be able to access it
> - the docker hub registry
> - environment variables
> - ports
> - volumes
> The docker tooling code is available at : http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git
> The IDockerImage is accessible from the image view : http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git/tree/conta...
> Example of menu contribution: http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git/tree/conta...
> Currently the search image wizard is not reusable (internal package), if needed, this will require exposing it in Docker tooling for Mars SR1
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years
[JBoss JIRA] (JBIDE-20386) Autocompleation uses very outdated data
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20386?page=com.atlassian.jira.plugi... ]
Denis Golovin updated JBIDE-20386:
----------------------------------
Fix Version/s: 4.3.x
> Autocompleation uses very outdated data
> ---------------------------------------
>
> Key: JBIDE-20386
> URL: https://issues.jboss.org/browse/JBIDE-20386
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: freemarker
> Reporter: Daniel Dekany
> Assignee: Denis Golovin
> Fix For: 4.3.x
>
>
> When you press Ctrl+Space after {{<#}} or in an expression after {{foo?}}, the list of directive names, and especially the list of built-in names shown is very outdated. Instead of maintaining these lists manually, the list of directive names could be get from {{freemarker.template.Configuration.getSupportedBuiltInDirectiveNames()}}, and the list of built-in names from {{Configuration.getSupportedBuiltInNames()}}.
> Some complication since 2.3.23 is that the list of names should be filtered based on {{Template.getActualNamingConvention()}} (which either returns {{Configuration.LEGACY_NAMING_CONVENTION}} or {{Configuration.CAMEL_CASE_NAMING_CONVENTION}}). Though the algorithm for that is simple: If a name contains upper case letter then it's camel case. Otherwise, if it contains {{_}} then it belongs to the legacy naming convention. Otherwise if it's a directive name that equals to a lower-cased camel case directive name, then it's legacy naming convention (consider {{elseIf}} VS {{elseif}}). Otherwise the name belongs to both naming conventions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years