[JBoss JIRA] (JBDS-3441) Installer should prevent user from installing JBDS 9.0 with Java other than Java 8
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBDS-3441?page=com.atlassian.jira.plugin.... ]
Martin Malina commented on JBDS-3441:
-------------------------------------
I would vote -1.
This is what Max said:
{quote}
Guys, we've supported running the installer with lower/non-JDK versions for years.
The page where you choose the JDK already limits/warns you about this if we can't find a matching JVM.
This is nothing new.
The installer should run on as low a version as possible IMO to increase likelihood of it being even
installable for users with less optimal java versions.
{quote}
And this is what I added:
{quote}
+1
Just to make sure I just tried installing JBDS 8.1.0.GA running the installer with Java 6 (on Mac) and choosing Java 8 and it works just fine. I think there is no reason to limit this.
And as Max says, we already have checks in place on the installer page where you choose java - if you select too low of a java version, it will complain. So we can easily update this to require java 8.
And it helps with the use case Mus mentioned as well: Imagine a RHEL 6.6 user has both OpenJDK 1.7 and 1.8 installed, but 1.7 is the default (using alternatives). So it's desirable that such user can install JBDS without switching his default java version and he will just choose the right java in the installer.
Another use case is OS X: If you just double-click the installer jar, then you have no control over which java is used to run the installer - typically it will be the highest java installed, but it's somewhat unpredictable. So it's good that we don't restrict the installer, just the JBDS runtime.
{quote}
> Installer should prevent user from installing JBDS 9.0 with Java other than Java 8
> ----------------------------------------------------------------------------------
>
> Key: JBDS-3441
> URL: https://issues.jboss.org/browse/JBDS-3441
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: installer
> Affects Versions: 9.0.0.Beta1
> Reporter: Len DiMaggio
> Assignee: Denis Golovin
>
> If we only support running the JBDS 9.0 IDE with Java 8, then the installer should prevent the user from installing with older versions of Java. Thx!
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBDS-3439) Unable to add a new Forge Runtime
by Koen Aers (JIRA)
[ https://issues.jboss.org/browse/JBDS-3439?page=com.atlassian.jira.plugin.... ]
Koen Aers commented on JBDS-3439:
---------------------------------
Supporting multiple Forge 2 runtimes simultaneously in JBoss Tools/ JBDS is currently impossible. With the removal of Forge 1 support the 'Add Runtime' functionality was also removed as it pertained only to Forge 1.
I agree that supporting multiple Forge 2 runtimes could be a valuable addition. It is however a difficult feature to implement because of the different architecture of Forge 2 compared to Forge 1. So I am inclined to reject this issue unless there is a real compelling (business?) reason to implement it. It most certainly needs more discussion.
> Unable to add a new Forge Runtime
> ---------------------------------
>
> Key: JBDS-3439
> URL: https://issues.jboss.org/browse/JBDS-3439
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Quality Risk
> Components: forge
> Affects Versions: 8.0.0.GA, 8.1.0.GA
> Environment: Fedora 20, jdk1.7.0_67, JBoss Developer Studio 8+
> Reporter: Miguel Angel Morales Pedraza
> Assignee: Max Rydahl Andersen
> Priority: Optional
> Labels: forge, runtime
> Fix For: 8.x
>
>
> Unable to add a new Forge runtime on JBDS 8.0.0 and 8.1.0. The button "Add" it doesn't shown anymore.
> On the JBDS v7.1.1 this button appears.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-19792) antlr packages and lib not exported in Hibernate Tools 4.0.1
by Koen Aers (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19792?page=com.atlassian.jira.plugi... ]
Koen Aers commented on JBIDE-19792:
-----------------------------------
Hi Bastian,
Not exposing the Hibernate runtime and its dependencies is something we had to do to properly support the simultaneous use of multiple Hibernate versions in JBoss Tools. I don't know if you noticed this, but the 'org.hibernate.eclipse.libs' plugin contained Hibernate version 3.5.x and its dependencies only. The entire runtime provision system was redesigned and reimplemented starting with Luna and even further in Mars. It will probably need more significant changes to support Hibernate 5 which is now in Beta. As a matter of fact the entire 'org.hibernate.eclipse.libs' plugin is removed in the Mars development stream and was only used for testing purposes in the Luna release.
To solve your problem, I it should probably be enough to depend on the 'org.jboss.tools.hibernate.antlr' plugin. Be aware however that in the Mars development stream this plugin was renamed to 'org.jboss.tools.hibernate.libs.antlr.v_2_7_7'. Let us know how it goes and if we can resolve this issue.
Cheers,
Koen
> antlr packages and lib not exported in Hibernate Tools 4.0.1
> ------------------------------------------------------------
>
> Key: JBIDE-19792
> URL: https://issues.jboss.org/browse/JBIDE-19792
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: hibernate
> Affects Versions: 4.2.3.Final
> Environment: Eclipse Luna SR2
> Reporter: Bastian Ulke
> Assignee: Koen Aers
> Attachments: B82_MANIFEST.MF, B95_MANIFEST.MF
>
>
> I am currently working on an Eclipse-Plugin that is built on top of the
> Hibernate Tools project. For example, I am using the following statements
> to get the AST of a named query:
> {code}
> try {
> HqlParser parser = HqlParser.getInstance(statementString);
> parser.statement();
> } catch (RecognitionException | TokenStreamException e) {
> e.printStackTrace();
> }
> AST statementAst = parser.getAST();
> {code}
> For this to work well with Hibernate Tools Version 4.0.0, I added bundle
> org.hibernate.eclipse.libs as required bundle to my plug-in configuration
> (which resolved to
> org.hibernate.eclipse.libs_4.0.0.Final-v20141016-1911-B82 so far).
> However, I now updated to Hiberate Tools 4.0.1
> (org.hibernate.eclipse.libs_4.0.1.Final-v20150324-2307-B95). The problem I
> have now is that the following imports cannot be resolved:
> import antlr.RecognitionException;
> import antlr.TokenStreamException;
> import antlr.collections.AST;
> The problem seems to arise from the fact, that in the new version's
> MANIFEST.MF, the antlr... packages are not exported and
> lib/hibernate/antlr-2.7.6.jar is not listed in the Bundle-ClassPath any
> more (I reformatted both MANIFEST.MFs, that you can find attached, to allow
> a convenient comparison). After manually adding the antlr-related entries
> to the new version's MANIFEST.MF, my code works pretty well again.
> I agree, that internal libraries should generally not be exported. However,
> org.hibernate.hql.ast.HqlParser is exported -- so why not its prerequesites?
> (By the way, I'd be fine with integrating another library into my project.
> However, I tried to manally add antlr-2.7.6.jar as library to
> my project, which solved the compilation error, but yields a
> java.lang.ClassNotFoundException: antlr.LLkParser cannot be found by
> org.hibernate.eclipse.libs_4.0.1.Final-v20150324-2307-B95.)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-19792) antlr packages and lib not exported in Hibernate Tools 4.0.1
by Koen Aers (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19792?page=com.atlassian.jira.plugi... ]
Koen Aers reassigned JBIDE-19792:
---------------------------------
Assignee: Koen Aers
> antlr packages and lib not exported in Hibernate Tools 4.0.1
> ------------------------------------------------------------
>
> Key: JBIDE-19792
> URL: https://issues.jboss.org/browse/JBIDE-19792
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: hibernate
> Affects Versions: 4.2.3.Final
> Environment: Eclipse Luna SR2
> Reporter: Bastian Ulke
> Assignee: Koen Aers
> Attachments: B82_MANIFEST.MF, B95_MANIFEST.MF
>
>
> I am currently working on an Eclipse-Plugin that is built on top of the
> Hibernate Tools project. For example, I am using the following statements
> to get the AST of a named query:
> {code}
> try {
> HqlParser parser = HqlParser.getInstance(statementString);
> parser.statement();
> } catch (RecognitionException | TokenStreamException e) {
> e.printStackTrace();
> }
> AST statementAst = parser.getAST();
> {code}
> For this to work well with Hibernate Tools Version 4.0.0, I added bundle
> org.hibernate.eclipse.libs as required bundle to my plug-in configuration
> (which resolved to
> org.hibernate.eclipse.libs_4.0.0.Final-v20141016-1911-B82 so far).
> However, I now updated to Hiberate Tools 4.0.1
> (org.hibernate.eclipse.libs_4.0.1.Final-v20150324-2307-B95). The problem I
> have now is that the following imports cannot be resolved:
> import antlr.RecognitionException;
> import antlr.TokenStreamException;
> import antlr.collections.AST;
> The problem seems to arise from the fact, that in the new version's
> MANIFEST.MF, the antlr... packages are not exported and
> lib/hibernate/antlr-2.7.6.jar is not listed in the Bundle-ClassPath any
> more (I reformatted both MANIFEST.MFs, that you can find attached, to allow
> a convenient comparison). After manually adding the antlr-related entries
> to the new version's MANIFEST.MF, my code works pretty well again.
> I agree, that internal libraries should generally not be exported. However,
> org.hibernate.hql.ast.HqlParser is exported -- so why not its prerequesites?
> (By the way, I'd be fine with integrating another library into my project.
> However, I tried to manally add antlr-2.7.6.jar as library to
> my project, which solved the compilation error, but yields a
> java.lang.ClassNotFoundException: antlr.LLkParser cannot be found by
> org.hibernate.eclipse.libs_4.0.1.Final-v20150324-2307-B95.)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBDS-3419) Arquillian Cruiser view is in default JBDS installation
by Rastislav Wagner (JIRA)
[ https://issues.jboss.org/browse/JBDS-3419?page=com.atlassian.jira.plugin.... ]
Rastislav Wagner commented on JBDS-3419:
----------------------------------------
Ok, so this is due to pointing jbds to old workspace. However I still think this is a bug - but its an upstream issue. I will create bugzilla.
> Arquillian Cruiser view is in default JBDS installation
> -------------------------------------------------------
>
> Key: JBDS-3419
> URL: https://issues.jboss.org/browse/JBDS-3419
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: arquillian, upstream
> Affects Versions: 9.0.0.Alpha2
> Reporter: Rastislav Wagner
> Assignee: Snjezana Peco
> Fix For: 9.0.0.Beta1
>
> Attachments: JBoss - JBoss Central - JBoss Developer Studio _001.png
>
>
> Default JBDS installation contains "Arquillia Cruiser" (missing n) view. Arquillian from central isn't installed. View is missing icon and does not work at all - if you try to open it you will get view with "Could not create the view: org.jboss.tools.arquillian.ui.views.arquillianView" text.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-19795) Bower support
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19795?page=com.atlassian.jira.plugi... ]
Ilya Buziuk commented on JBIDE-19795:
-------------------------------------
< it will make that JSDT will have 2 Bower supports
[~mickael_istria], AFAIK for now there is no decent bower support in JSDT due to dozens of performance issues, like:
- Installing the dependencies takes too long
- Install/Update command block the UI, no way to cancel the operation
- Update command doesn't follow the real bower's one
etc...
I don't really think that it's utterly important to the end user whether he gets bower from tools or jsdt.
Proof me wrong, but as far as I'm concerned our initial aim is to get working bower support *fast* (JBDS 9 release) in our tools, and not to be coupled with JSDT releases schedule and other overheads.
> Bower support
> -------------
>
> Key: JBIDE-19795
> URL: https://issues.jboss.org/browse/JBIDE-19795
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Affects Versions: 4.3.0.Alpha2
> Reporter: Ilya Buziuk
> Assignee: Ilya Buziuk
> Labels: new_and_noteworthy
> Fix For: 4.3.0.Final
>
>
> Need to have initial [Bower|http://bower.io/] tools support:
> *The gist*
> Bower tooling should initially support several bower API commands :
> |Command||Description|
> | *bower init* |creates a *bower.json* file|
> |*bower install <package>*|installs packages to *bower_components* folder|
> |*bower uninstall <package>*|uninstalls a package locally from *bower_components* directory|
> |*bower update* |updates installed packages to their newest version according to *bower.json*|
> Basically, the main idea of the implementation is the following:
> Eclipse plugin that will execute *external* bower commands - implementation will fall back on *native* bower installation via *ILaunchConfiguration*
> Native bower tools must be preinstalled
> *The main questions & proposals:*
> 1. https://github.com/jbosstools/jbosstools-playground is probably the best place for initial implementation of bower stuff (infrastructure / build etc.)
> 2. UI. should it be ILaunchShortcuts ("bower init" / "bower update" etc.) + launch configuration enabled for projects with js nature?
> 3. Implementation details:
> - the way of detecting bower? Should user point to it's installation dir and this location will be used for IExternalToolConstants.ATTR_LOCATION (windows case: *\user\AppData\Roaming\npm\node_modules\bower* )
> - if bower was not detected / installed - "Error message with a link to the bower website with installation details depending on the platform"
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-13904) Minor UI issues in "Configure Repositories" wizard
by Rastislav Wagner (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13904?page=com.atlassian.jira.plugi... ]
Rastislav Wagner closed JBIDE-13904.
------------------------------------
verified in JBDS 9.0.0.Alpha2-v20150420-1747-B24
> Minor UI issues in "Configure Repositories" wizard
> --------------------------------------------------
>
> Key: JBIDE-13904
> URL: https://issues.jboss.org/browse/JBIDE-13904
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: maven
> Affects Versions: 4.1.0.Alpha2
> Reporter: Fred Bricon
> Assignee: Snjezana Peco
> Priority: Minor
> Labels: uxp
> Fix For: 4.3.0.Alpha2
>
>
> In the Window > Preferences > JBoss Tools > JBoss Maven Integration > Configure Maven Repositories...
> * The repo viewer should have a horizontal scroller, since adding the (inactive) suffix can make a pretty long label and you have to resize the whole dialog to be able to read the labels
> * Edit a repo, switching the profile activation status : it reorders the repositories/profiles in settings.xml.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-19358) Singleton bean is discovered by cdi validator
by Rastislav Wagner (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19358?page=com.atlassian.jira.plugi... ]
Rastislav Wagner closed JBIDE-19358.
------------------------------------
verified in JBDS 9.0.0.Alpha2-v20150420-1747-B24
> Singleton bean is discovered by cdi validator
> ---------------------------------------------
>
> Key: JBIDE-19358
> URL: https://issues.jboss.org/browse/JBIDE-19358
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi
> Affects Versions: 4.3.0.Alpha1
> Reporter: Rastislav Wagner
> Assignee: Viacheslav Kabanovich
> Fix For: 4.3.0.Alpha2
>
>
> @Singleton is pseudo-scope which means its not bean defining annotation and the bean annotated with this pseudo-scope shouldn't be considered when discovery mode is set to annotated. However CDI tooling is considering it.
> Im not sure if this applies only for CDI 1.2 or also for 1.1 ?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months