[JBoss JIRA] Created: (JBIDE-4727) Support distribution defining "New Project" dependencies
by Pete Muir (JIRA)
Support distribution defining "New Project" dependencies
--------------------------------------------------------
Key: JBIDE-4727
URL: https://jira.jboss.org/jira/browse/JBIDE-4727
Project: JBoss Tools
Issue Type: Feature Request
Components: Seam
Reporter: Pete Muir
Summary:
Move the responsibility for defining a "New Seam Project"'s dependencies (libraries) from JBoss Tools to the Seam distribution. Use the Maven 2 POM format to define the dependencies. Use Maven POM profiles to support different use cases for Seam projects.
Reason:
Currently JBoss Tools defines the project dependencies which causes issues very time Seam changes either the dependency set of a new seam project, or the layout of libraries in the distribution. Use Maven 2 POM format as it is already a well defined and understood model. Use of Maven POM profiles can further increase the flexibility and support various use cases for Seam (for example, Seam with jBPM or Seam with ICEFaces).
Details:
JBoss Tools should be able to read these files from the seam-gen/ directory: war.pom.xml, ear.pom.xml, ejb-jar.ear.pom.xml, war.ear.pom.xml. The war.pom.xml defines the dependencies for a WAR project; the *ear.pom.xml define dependencies for the composite modules of an EAR project. The standard Maven scopes are used: compile to indicate compile/runtime dependencies of the project, test to indicate extra dependencies required in the test project.
Maven profiles are used to define additional dependency sets for new seam projects, allowing the user to optionally add extra dependencies to his project. To make this extensible, and not require JBossTools to use a well-known list of profile ids, an xml namespace will be used to add additional metadata to the profile. This allows JBossTools to identify the possible profiles:
<profile>
<id>drools5</id>
<jbt:profile>
<jbt:description>Drools 5 support (Tech Preview)</jbt:description>
</jbt:profile>
<!--Standard Maven elements -->
</profile>
<profile>
<id>ICEFaces</id>
<jbt:profile>
<jbt:description>ICEFaces</jbt:description>
</jbt:profile>
<!--Standard Maven elements -->
</profile>
JBossTools can recognize the jbt:profile element, and use the jbt:description element to as a descriptive element to present to the user:
[x] ICEFaces
[x] Drools 5 support (Tech Preview)
displayed in the New Seam Project Wizard.
We should allow for additional information to be placed in the POM and in the future beyond dependency information. For example, additional configuration files to include in the generated project, however this is not a critical feature.
We should also consider allowing JBoss Tools to retrieve the POMs from a Maven repository. This would require a user to simply specify the version of Seam they require, and have JBoss Tools download the seam-gen artifact containing all templates and resources.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JBIDE-12308) VPE throws StackOverflowError and visual part is blank
by Yahor Radtsevich (JIRA)
Yahor Radtsevich created JBIDE-12308:
----------------------------------------
Summary: VPE throws StackOverflowError and visual part is blank
Key: JBIDE-12308
URL: https://issues.jboss.org/browse/JBIDE-12308
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: Visual Page Editor core
Reporter: Yahor Radtsevich
Assignee: Yahor Radtsevich
Fix For: 3.3.x, 3.4.0.M1
# Create new RichFaces project from JBoss Central View
# Open richfaces-webapp/src/main/webapp/WEB-INF/templates/mobile.xhtml in VPE
*Result:*
VPE is blank:
!screenshot.png|thumbnail!
{code}
java.lang.StackOverflowError
at java.util.regex.Pattern$GroupHead.match(Pattern.java:4556)
at java.util.regex.Pattern$Loop.match(Pattern.java:4683)
at java.util.regex.Pattern$GroupTail.match(Pattern.java:4615)
at java.util.regex.Pattern$BranchConn.match(Pattern.java:4466)
at java.util.regex.Pattern$CharProperty.match(Pattern.java:3694)
at java.util.regex.Pattern$Branch.match(Pattern.java:4502)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JBIDE-12336) org.jboss.ide.eclipse.archives.core bundles some old/obselete jars
by Gerard Ryan (JIRA)
Gerard Ryan created JBIDE-12336:
-----------------------------------
Summary: org.jboss.ide.eclipse.archives.core bundles some old/obselete jars
Key: JBIDE-12336
URL: https://issues.jboss.org/browse/JBIDE-12336
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: Archives
Environment: Fedora
Reporter: Gerard Ryan
Assignee: Rob Stryker
As detailed on the jbosstools-dev mailing list[1], I'm packaging JBoss Tools for Fedora, and the bundled jars in the lib/ directory of the org.jboss.ide.eclipse.archives.core plugin are causing me some trouble.
The root of the issue is that Fedora packages disallow bundled dependencies; and when new packages are being created, only the latest version of the software must be packaged. This was not too much of a problem for the truezip dependency, even though some things did need to be changed for it, as detailed in the truezip migration from v6 to v7 guide[2].
It didn't work so well for the jbossxb dependency, however. jbossxb hasn't seen any activity in quite a while, and it depends on the seemingly obselete (this may not be the best description) jboss-reflect. jboss-reflect, in its current state, cannot be included in Fedora for reasons listed in the review for the package that I proposed for it[3].
I'm trying to find the optimal solution to this problem. What I would really like to know from the JBoss Tools perspective is: How crucial to this plugin is jbossxb? Is there anything else that would work as a dropin replacement, or any other workaround possible? Since development of jbossxb seems dormant, not having to package it for Fedora would be the best solution for me. I realise that it may be necessary though, but I thought I would bring it up here, before I go looking for the jbossxb developers, in case my best case scenario is a possibility!
Thanks in advance for any insight/help you can provide! :)
[1] http://lists.jboss.org/pipermail/jbosstools-dev/2012-July/005548.html
[2] http://truezip.java.net/migration.html
[3] https://bugzilla.redhat.com/show_bug.cgi?id=836404
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months