[JBoss JIRA] (FORGE-378) Add "environments" as a first class construct
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/FORGE-378?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on FORGE-378:
-------------------------------------------
I agree with [~agoncal] that it should be possible to control JAVAEE separately from CONTAINER.
I kinda see it as CONTAINER will specify the defaults for things like JAVAEE if user have not explicitly set it.
With respect to referencing JavaEE api's instead of Java EE BOM then that was at least with Java EE 6 problematic since the referenced jars were incomplete thus making test runs using these jars impossible.
This issue should be fixed in Java EE 7 (http://developinjava.com/2013/06/java-ee-7-fixes-java-ee-6s-absent-code/) but still, some of the spec jars require specific container content (i.e. JPA) thus something like using JBoss BOM still are necessary.
Also reason for using BOM's is so you don't have to update all your projects individual dependency versions and just use properties provided by the BOM.
> Add "environments" as a first class construct
> ---------------------------------------------
>
> Key: FORGE-378
> URL: https://issues.jboss.org/browse/FORGE-378
> Project: Forge
> Issue Type: Feature Request
> Components: UI - Shell, Usability
> Reporter: Pete Muir
>
> For example:
> {code}
> set environment JBOSS_AS7 --version 7.1.0.Final
> {code}
> Where JBOSS_AS7 is a built in profile that contains necessary info on various versions of JBoss AS 7.
> For example, the persistence plugin could read from this, changing
> {code}
> persistence setup --provider HIBERNATE --container JBOSS_AS7
> {code}
> to
> {code}
> persistence setup
> {code}
> Or, when setting up CDI, this would remove the need to ask ask which API to use (always use the Java EE BOM with JBoss AS), and as the metadata builds, remove the need to ask the version of the spec BOM to use.
> Lot's of other places where this could provide better defaulting, or remove the need to ask questions.
> This also seems fairly consistent with the Forge approach - good understanding of the project in question.
--
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
10 years, 10 months
[JBoss JIRA] (FORGE-1067) Adopt WebJars as encapsulation for Bootstrap and JQuery resources
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/FORGE-1067?page=com.atlassian.jira.plugin... ]
Vineet Reynolds commented on FORGE-1067:
----------------------------------------
I spoke just half of my mind there as always :)
As you may notice, any parameter for the scaffold command will have to be considered by all scaffold providers, and it may not make sense for some of them. One of the things I intend to do in Forge 2 is to investigate whether scaffold providers can acquire more control over the parameters they are supplied via multi-step wizards that are tailored towards the providers. A Faces scaffold provider could therefore have an option to use WebJars to manage dependencies, while a HTML5 scaffold provider could have an option to use Bower.
Given that I'm shortly beginning work on Forge 2, I'd prefer investigating the feasibility of doing this at the earliest and may it ready if possible in Sept, instead of bringing this in Forge 1 and then porting or rewriting it for Forge 2.
> Adopt WebJars as encapsulation for Bootstrap and JQuery resources
> -----------------------------------------------------------------
>
> Key: FORGE-1067
> URL: https://issues.jboss.org/browse/FORGE-1067
> Project: Forge
> Issue Type: Enhancement
> Components: Scaffold
> Affects Versions: 1.3.3.Final
> Reporter: Antonio Goncalves
> Fix For: 1.x Future
>
>
> At the moment JBoss Forge copies the {{bootstrap.css}} into the resources directory. It would be nice to use WebJar [1] to package Bootstrap (and JQuery) into the war file.
> For this to happen you just need to add the following Maven dependencies to the {{pom.xml}} :
> {code}
> <dependency>
> <groupId>org.webjars</groupId>
> <artifactId>bootstrap</artifactId>
> <version>2.3.2</version>
> </dependency>
> <dependency>
> <groupId>org.webjars</groupId>
> <artifactId>jquery</artifactId>
> <version>2.0.3</version>
> </dependency>
> {code}
> Then, change the {{pageTemplate.xhtml}} so it looks like this :
> {code}
> <!DOCTYPE html>
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:ui="http://java.sun.com/jsf/facelets">
> <h:head>
> <title>#{empty pageTitle ? '{#pageTitle}' : pageTitle}</title>
> <link rel="icon" href="#{resource['favicon.ico']}"/>
> <h:outputStylesheet library="webjars/bootstrap/2.3.2/css" name="bootstrap.min.css"/>
> <h:outputStylesheet name="forge-style.css"/>
> </h:head>
> <h:body>
> ...
> ...
> ...
> <!-- Bootstrap core JavaScript
> ================================================== -->
> <!-- Placed at the end of the document so the pages load faster -->
> <h:outputScript name="webjars/jquery/2.0.3/jquery.min.js"/>
> <h:outputScript library="webjars/bootstrap/2.3.2/js" name="bootstrap.min.js"/>
> </h:body>
> </html>
> {code}
> And of course, get rid of the {{bootstrap.css}} file ;o)
> [1] http://www.webjars.org/
> [1] http://www.jamesward.com/2012/10/31/webjars-officially-launched
> See also : https://issues.jboss.org/browse/RF-12584
--
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
10 years, 10 months
[JBoss JIRA] (FORGE-1067) Adopt WebJars as encapsulation for Bootstrap and JQuery resources
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/FORGE-1067?page=com.atlassian.jira.plugin... ]
Vineet Reynolds commented on FORGE-1067:
----------------------------------------
Introducing a parameter shouldn't be a problem. We'll however need to implement this uniformly across all scaffold providers. Also, we'll need to ensure that this shouldn't conflict with any future need to support a different package manager like Bower.
> Adopt WebJars as encapsulation for Bootstrap and JQuery resources
> -----------------------------------------------------------------
>
> Key: FORGE-1067
> URL: https://issues.jboss.org/browse/FORGE-1067
> Project: Forge
> Issue Type: Enhancement
> Components: Scaffold
> Affects Versions: 1.3.3.Final
> Reporter: Antonio Goncalves
> Fix For: 1.x Future
>
>
> At the moment JBoss Forge copies the {{bootstrap.css}} into the resources directory. It would be nice to use WebJar [1] to package Bootstrap (and JQuery) into the war file.
> For this to happen you just need to add the following Maven dependencies to the {{pom.xml}} :
> {code}
> <dependency>
> <groupId>org.webjars</groupId>
> <artifactId>bootstrap</artifactId>
> <version>2.3.2</version>
> </dependency>
> <dependency>
> <groupId>org.webjars</groupId>
> <artifactId>jquery</artifactId>
> <version>2.0.3</version>
> </dependency>
> {code}
> Then, change the {{pageTemplate.xhtml}} so it looks like this :
> {code}
> <!DOCTYPE html>
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:ui="http://java.sun.com/jsf/facelets">
> <h:head>
> <title>#{empty pageTitle ? '{#pageTitle}' : pageTitle}</title>
> <link rel="icon" href="#{resource['favicon.ico']}"/>
> <h:outputStylesheet library="webjars/bootstrap/2.3.2/css" name="bootstrap.min.css"/>
> <h:outputStylesheet name="forge-style.css"/>
> </h:head>
> <h:body>
> ...
> ...
> ...
> <!-- Bootstrap core JavaScript
> ================================================== -->
> <!-- Placed at the end of the document so the pages load faster -->
> <h:outputScript name="webjars/jquery/2.0.3/jquery.min.js"/>
> <h:outputScript library="webjars/bootstrap/2.3.2/js" name="bootstrap.min.js"/>
> </h:body>
> </html>
> {code}
> And of course, get rid of the {{bootstrap.css}} file ;o)
> [1] http://www.webjars.org/
> [1] http://www.jamesward.com/2012/10/31/webjars-officially-launched
> See also : https://issues.jboss.org/browse/RF-12584
--
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
10 years, 10 months
[JBoss JIRA] (FORGE-1067) Adopt WebJars as encapsulation for Bootstrap and JQuery resources
by Burr Sutter (JIRA)
[ https://issues.jboss.org/browse/FORGE-1067?page=com.atlassian.jira.plugin... ]
Burr Sutter commented on FORGE-1067:
------------------------------------
Could this be handled a parameter? By default, we do not use it, however, there could be an additional parameter like
scaffold from-entity model.* --overwrite --webjars
> Adopt WebJars as encapsulation for Bootstrap and JQuery resources
> -----------------------------------------------------------------
>
> Key: FORGE-1067
> URL: https://issues.jboss.org/browse/FORGE-1067
> Project: Forge
> Issue Type: Enhancement
> Components: Scaffold
> Affects Versions: 1.3.3.Final
> Reporter: Antonio Goncalves
> Fix For: 1.x Future
>
>
> At the moment JBoss Forge copies the {{bootstrap.css}} into the resources directory. It would be nice to use WebJar [1] to package Bootstrap (and JQuery) into the war file.
> For this to happen you just need to add the following Maven dependencies to the {{pom.xml}} :
> {code}
> <dependency>
> <groupId>org.webjars</groupId>
> <artifactId>bootstrap</artifactId>
> <version>2.3.2</version>
> </dependency>
> <dependency>
> <groupId>org.webjars</groupId>
> <artifactId>jquery</artifactId>
> <version>2.0.3</version>
> </dependency>
> {code}
> Then, change the {{pageTemplate.xhtml}} so it looks like this :
> {code}
> <!DOCTYPE html>
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:ui="http://java.sun.com/jsf/facelets">
> <h:head>
> <title>#{empty pageTitle ? '{#pageTitle}' : pageTitle}</title>
> <link rel="icon" href="#{resource['favicon.ico']}"/>
> <h:outputStylesheet library="webjars/bootstrap/2.3.2/css" name="bootstrap.min.css"/>
> <h:outputStylesheet name="forge-style.css"/>
> </h:head>
> <h:body>
> ...
> ...
> ...
> <!-- Bootstrap core JavaScript
> ================================================== -->
> <!-- Placed at the end of the document so the pages load faster -->
> <h:outputScript name="webjars/jquery/2.0.3/jquery.min.js"/>
> <h:outputScript library="webjars/bootstrap/2.3.2/js" name="bootstrap.min.js"/>
> </h:body>
> </html>
> {code}
> And of course, get rid of the {{bootstrap.css}} file ;o)
> [1] http://www.webjars.org/
> [1] http://www.jamesward.com/2012/10/31/webjars-officially-launched
> See also : https://issues.jboss.org/browse/RF-12584
--
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
10 years, 10 months
[JBoss JIRA] (FORGE-1064) ProjectListener should be an @Exported service
by Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/FORGE-1064?page=com.atlassian.jira.plugin... ]
Lincoln Baxter III closed FORGE-1064.
-------------------------------------
Fix Version/s: 2.0.0.Alpha12
(was: 2.x Future)
Resolution: Done
Merged. Use of this functionality in anonymous classes is blocked due to WELD-1487, and should work when it is resolved, but the primary use case for top-level classes is still working, so I'm closing this issue.
> ProjectListener should be an @Exported service
> ----------------------------------------------
>
> Key: FORGE-1064
> URL: https://issues.jboss.org/browse/FORGE-1064
> Project: Forge
> Issue Type: Enhancement
> Components: Builtin Plugins, Usability
> Affects Versions: 2.0.0.Alpha9
> Reporter: Lincoln Baxter III
> Assignee: George Gastaldi
> Fix For: 2.0.0.Alpha12
>
>
> The ProjectFactory should query the AddonRegistry for available ProjectListener services in addition to supporting the existing manual listener registration.
> {code}
> @Inject Imported<ProjectListener> listeners;
> {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
10 years, 10 months
[JBoss JIRA] (FORGE-1137) Refactor ServletFacet
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-1137?page=com.atlassian.jira.plugin... ]
George Gastaldi updated FORGE-1137:
-----------------------------------
Description:
{quote}
<gastaldi> in Forge 2.x, should the ServletFacetImpl.isInstalled() check for web.xml existence to assert that it is installed ?
<gastaldi> I think it should only check if the required deps are met
<gastaldi> and @RequireFacet(WebResourcesFacet.class) perhaps
<lincolnthree> gastaldi: why this change? (leading question)
<gastaldi> FORGE-1135
<jbossbot> jira [FORGE-1135] ServletFacetImpl overrides isInstalled of BaseJavaEEFacet but doesnt call super.isInstalled [Closed (Done) Bug, Major, Thomas Frühbeck] https://issues.jboss.org/browse/FORGE-1135
<gastaldi> if we think about it, checking for the web.xml presence doesn't make much sense in it
<lincolnthree> why is that?
<gastaldi> suppose you're writing a java library that depends on Servlet API
<vineetreynolds> Servlet 3.0
<gastaldi> yes
<gastaldi> Why would you need web.xml in it?
<lincolnthree> im playing devil's advocate here
<vineetreynolds> Even web-framgment.xml changes the equation
<lincolnthree> i'd say that we should have 2 facets then, or 3 facets
<vineetreynolds> It could be a jar with a web-fragment.xml
<lincolnthree> ServletFacet25
<lincolnthree> ServletFacet30
<vineetreynolds> Yes, like SW
<vineetreynolds> Activate based on version value in the XML
<vineetreynolds> version="2.5", version="3.0"
<lincolnthree> ServletFragmentFacet30
<gastaldi> I think we should move the org.jboss.forge.addon.javaee.facets.ServletFacet.getConfig() to another facet
<gastaldi> WebResourcesFacet perhaps
<lincolnthree> gastaldi: WebResourceFacet is even less tied to servlet than servlet it
<lincolnthree> is
<lincolnthree> that just adds src/web/resources
<lincolnthree> err
<lincolnthree> src/main/webapp
<vineetreynolds> Right
<gastaldi> sure, just saying that maybe it doesn't make much sense to be in ServletFacet
<vineetreynolds> Do we even need a ServletFacet ?
<lincolnthree> gastaldi: I don't see why not
<vineetreynolds> nvm
<vineetreynolds> We need a facet for the dependency
<lincolnthree> vineetreynolds: yes
<vineetreynolds> ServletAPIFacet
<gastaldi> yeah, something like that
<lincolnthree> ServletApiFacet30
<gastaldi> like Faces does
<vineetreynolds> I dont think we should tie to the web.xml file
<vineetreynolds> unless we need to
<lincolnthree> vineetreynolds: if there is a web.xml file, it should be respected
<lincolnthree> if there is not, it should not be required for 3.0
<lincolnthree> but for 2.5 it should be
<vineetreynolds> Well, the dependency is more important imho
<gastaldi> lincolnthree, unless the PackagingType != WAR
<gastaldi> if it's a library, web.xml is never required in the current project
<lincolnthree> gastaldi: sure
<gastaldi> hence, should use named web-fragment
<gastaldi> s/use/be
<lincolnthree> gastaldi: again… only in 3.0
<gastaldi> yea
<gastaldi> in 2.5 should not rely on any descriptor if PackagingType is not WAR
<lincolnthree> correct
{quote}
was:
{quote}
<gastaldi> in Forge 2.x, should the ServletFacetImpl.isInstalled() check for web.xml existence to assert that it is installed ?
<gastaldi> I think it should only check if the required deps are met
<gastaldi> and @RequireFacet(WebResourcesFacet.class) perhaps
<lincolnthree> gastaldi: why this change? (leading question)
<gastaldi> FORGE-1135
<jbossbot> jira [FORGE-1135] ServletFacetImpl overrides isInstalled of BaseJavaEEFacet but doesnt call super.isInstalled [Closed (Done) Bug, Major, Thomas Frühbeck] https://issues.jboss.org/browse/FORGE-1135
<gastaldi> if we think about it, checking for the web.xml presence doesn't make much sense in it
<lincolnthree> why is that?
<gastaldi> suppose you're writing a java library that depends on Servlet API
<vineetreynolds> Servlet 3.0
<gastaldi> yes
<gastaldi> Why would you need web.xml in it?
<lincolnthree> im playing devil's advocate here
<vineetreynolds> Even web-framgment.xml changes the equation
<lincolnthree> i'd say that we should have 2 facets then, or 3 facets
<vineetreynolds> It could be a jar with a web-fragment.xml
<lincolnthree> ServletFacet25
<lincolnthree> ServletFacet30
* sgilda is now known as sgilda_brb
<vineetreynolds> Yes, like SW
<vineetreynolds> Activate based on version value in the XML
<vineetreynolds> version="2.5", version="3.0"
<lincolnthree> ServletFragmentFacet30
<gastaldi> I think we should move the org.jboss.forge.addon.javaee.facets.ServletFacet.getConfig() to another facet
<gastaldi> WebResourcesFacet perhaps
<lincolnthree> gastaldi: WebResourceFacet is even less tied to servlet than servlet it
<lincolnthree> is
<lincolnthree> that just adds src/web/resources
<lincolnthree> err
<lincolnthree> src/main/webapp
<vineetreynolds> Right
<gastaldi> sure, just saying that maybe it doesn't make much sense to be in ServletFacet
<vineetreynolds> Do we even need a ServletFacet ?
<lincolnthree> gastaldi: I don't see why not
<vineetreynolds> nvm
<vineetreynolds> We need a facet for the dependency
<lincolnthree> vineetreynolds: yes
<vineetreynolds> ServletAPIFacet
<gastaldi> yeah, something like that
<lincolnthree> ServletApiFacet30
<gastaldi> like Faces does
<vineetreynolds> I dont think we should tie to the web.xml file
<vineetreynolds> unless we need to
<lincolnthree> vineetreynolds: if there is a web.xml file, it should be respected
<lincolnthree> if there is not, it should not be required for 3.0
<lincolnthree> but for 2.5 it should be
<vineetreynolds> Well, the dependency is more important imho
<gastaldi> lincolnthree, unless the PackagingType != WAR
<gastaldi> if it's a library, web.xml is never required in the current project
<lincolnthree> gastaldi: sure
<gastaldi> hence, should use named web-fragment
<gastaldi> s/use/be
<lincolnthree> gastaldi: again… only in 3.0
<gastaldi> yea
<gastaldi> in 2.5 should not rely on any descriptor if PackagingType is not WAR
<lincolnthree> correct
{quote}
> Refactor ServletFacet
> ---------------------
>
> Key: FORGE-1137
> URL: https://issues.jboss.org/browse/FORGE-1137
> Project: Forge
> Issue Type: Enhancement
> Components: Java EE APIs
> Affects Versions: 2.0.0.Alpha11
> Reporter: George Gastaldi
> Fix For: 2.x Future
>
>
> {quote}
> <gastaldi> in Forge 2.x, should the ServletFacetImpl.isInstalled() check for web.xml existence to assert that it is installed ?
> <gastaldi> I think it should only check if the required deps are met
> <gastaldi> and @RequireFacet(WebResourcesFacet.class) perhaps
> <lincolnthree> gastaldi: why this change? (leading question)
> <gastaldi> FORGE-1135
> <jbossbot> jira [FORGE-1135] ServletFacetImpl overrides isInstalled of BaseJavaEEFacet but doesnt call super.isInstalled [Closed (Done) Bug, Major, Thomas Frühbeck] https://issues.jboss.org/browse/FORGE-1135
> <gastaldi> if we think about it, checking for the web.xml presence doesn't make much sense in it
> <lincolnthree> why is that?
> <gastaldi> suppose you're writing a java library that depends on Servlet API
> <vineetreynolds> Servlet 3.0
> <gastaldi> yes
> <gastaldi> Why would you need web.xml in it?
> <lincolnthree> im playing devil's advocate here
> <vineetreynolds> Even web-framgment.xml changes the equation
> <lincolnthree> i'd say that we should have 2 facets then, or 3 facets
> <vineetreynolds> It could be a jar with a web-fragment.xml
> <lincolnthree> ServletFacet25
> <lincolnthree> ServletFacet30
> <vineetreynolds> Yes, like SW
> <vineetreynolds> Activate based on version value in the XML
> <vineetreynolds> version="2.5", version="3.0"
> <lincolnthree> ServletFragmentFacet30
> <gastaldi> I think we should move the org.jboss.forge.addon.javaee.facets.ServletFacet.getConfig() to another facet
> <gastaldi> WebResourcesFacet perhaps
> <lincolnthree> gastaldi: WebResourceFacet is even less tied to servlet than servlet it
> <lincolnthree> is
> <lincolnthree> that just adds src/web/resources
> <lincolnthree> err
> <lincolnthree> src/main/webapp
> <vineetreynolds> Right
> <gastaldi> sure, just saying that maybe it doesn't make much sense to be in ServletFacet
> <vineetreynolds> Do we even need a ServletFacet ?
> <lincolnthree> gastaldi: I don't see why not
> <vineetreynolds> nvm
> <vineetreynolds> We need a facet for the dependency
> <lincolnthree> vineetreynolds: yes
> <vineetreynolds> ServletAPIFacet
> <gastaldi> yeah, something like that
> <lincolnthree> ServletApiFacet30
> <gastaldi> like Faces does
> <vineetreynolds> I dont think we should tie to the web.xml file
> <vineetreynolds> unless we need to
> <lincolnthree> vineetreynolds: if there is a web.xml file, it should be respected
> <lincolnthree> if there is not, it should not be required for 3.0
> <lincolnthree> but for 2.5 it should be
> <vineetreynolds> Well, the dependency is more important imho
> <gastaldi> lincolnthree, unless the PackagingType != WAR
> <gastaldi> if it's a library, web.xml is never required in the current project
> <lincolnthree> gastaldi: sure
> <gastaldi> hence, should use named web-fragment
> <gastaldi> s/use/be
> <lincolnthree> gastaldi: again… only in 3.0
> <gastaldi> yea
> <gastaldi> in 2.5 should not rely on any descriptor if PackagingType is not WAR
> <lincolnthree> correct
> {quote}
--
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
10 years, 10 months
[JBoss JIRA] (FORGE-1067) Adopt WebJars as encapsulation for Bootstrap and JQuery resources
by Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/FORGE-1067?page=com.atlassian.jira.plugin... ]
Lincoln Baxter III commented on FORGE-1067:
-------------------------------------------
Hmmm... I'll need to see how some other people/projects feel about this. The difference is that this adds a new external dependency, whereas the original direct inclusion of bootstrap keeps the dependency local, so that any changes required do not require a release of an artifact that we do not control :/
I wish I could just say "yes" but the fact is that we have to consider these things when stuff goes into a supported product :(
However, this doesn't stop us from doing an unsupported "Much better and easier to use scaffold." Hopefully the popularity of that would increase to the point where we can justify supporting it by default.
> Adopt WebJars as encapsulation for Bootstrap and JQuery resources
> -----------------------------------------------------------------
>
> Key: FORGE-1067
> URL: https://issues.jboss.org/browse/FORGE-1067
> Project: Forge
> Issue Type: Enhancement
> Components: Scaffold
> Affects Versions: 1.3.3.Final
> Reporter: Antonio Goncalves
> Fix For: 1.x Future
>
>
> At the moment JBoss Forge copies the {{bootstrap.css}} into the resources directory. It would be nice to use WebJar [1] to package Bootstrap (and JQuery) into the war file.
> For this to happen you just need to add the following Maven dependencies to the {{pom.xml}} :
> {code}
> <dependency>
> <groupId>org.webjars</groupId>
> <artifactId>bootstrap</artifactId>
> <version>2.3.2</version>
> </dependency>
> <dependency>
> <groupId>org.webjars</groupId>
> <artifactId>jquery</artifactId>
> <version>2.0.3</version>
> </dependency>
> {code}
> Then, change the {{pageTemplate.xhtml}} so it looks like this :
> {code}
> <!DOCTYPE html>
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:ui="http://java.sun.com/jsf/facelets">
> <h:head>
> <title>#{empty pageTitle ? '{#pageTitle}' : pageTitle}</title>
> <link rel="icon" href="#{resource['favicon.ico']}"/>
> <h:outputStylesheet library="webjars/bootstrap/2.3.2/css" name="bootstrap.min.css"/>
> <h:outputStylesheet name="forge-style.css"/>
> </h:head>
> <h:body>
> ...
> ...
> ...
> <!-- Bootstrap core JavaScript
> ================================================== -->
> <!-- Placed at the end of the document so the pages load faster -->
> <h:outputScript name="webjars/jquery/2.0.3/jquery.min.js"/>
> <h:outputScript library="webjars/bootstrap/2.3.2/js" name="bootstrap.min.js"/>
> </h:body>
> </html>
> {code}
> And of course, get rid of the {{bootstrap.css}} file ;o)
> [1] http://www.webjars.org/
> [1] http://www.jamesward.com/2012/10/31/webjars-officially-launched
> See also : https://issues.jboss.org/browse/RF-12584
--
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
10 years, 10 months
[JBoss JIRA] (FORGE-1137) Refactor ServletFacet
by George Gastaldi (JIRA)
George Gastaldi created FORGE-1137:
--------------------------------------
Summary: Refactor ServletFacet
Key: FORGE-1137
URL: https://issues.jboss.org/browse/FORGE-1137
Project: Forge
Issue Type: Enhancement
Components: Java EE APIs
Affects Versions: 2.0.0.Alpha11
Reporter: George Gastaldi
Fix For: 2.x Future
{quote}
<gastaldi> in Forge 2.x, should the ServletFacetImpl.isInstalled() check for web.xml existence to assert that it is installed ?
<gastaldi> I think it should only check if the required deps are met
<gastaldi> and @RequireFacet(WebResourcesFacet.class) perhaps
<lincolnthree> gastaldi: why this change? (leading question)
<gastaldi> FORGE-1135
<jbossbot> jira [FORGE-1135] ServletFacetImpl overrides isInstalled of BaseJavaEEFacet but doesnt call super.isInstalled [Closed (Done) Bug, Major, Thomas Frühbeck] https://issues.jboss.org/browse/FORGE-1135
<gastaldi> if we think about it, checking for the web.xml presence doesn't make much sense in it
<lincolnthree> why is that?
<gastaldi> suppose you're writing a java library that depends on Servlet API
<vineetreynolds> Servlet 3.0
<gastaldi> yes
<gastaldi> Why would you need web.xml in it?
<lincolnthree> im playing devil's advocate here
<vineetreynolds> Even web-framgment.xml changes the equation
<lincolnthree> i'd say that we should have 2 facets then, or 3 facets
<vineetreynolds> It could be a jar with a web-fragment.xml
<lincolnthree> ServletFacet25
<lincolnthree> ServletFacet30
* sgilda is now known as sgilda_brb
<vineetreynolds> Yes, like SW
<vineetreynolds> Activate based on version value in the XML
<vineetreynolds> version="2.5", version="3.0"
<lincolnthree> ServletFragmentFacet30
<gastaldi> I think we should move the org.jboss.forge.addon.javaee.facets.ServletFacet.getConfig() to another facet
<gastaldi> WebResourcesFacet perhaps
<lincolnthree> gastaldi: WebResourceFacet is even less tied to servlet than servlet it
<lincolnthree> is
<lincolnthree> that just adds src/web/resources
<lincolnthree> err
<lincolnthree> src/main/webapp
<vineetreynolds> Right
<gastaldi> sure, just saying that maybe it doesn't make much sense to be in ServletFacet
<vineetreynolds> Do we even need a ServletFacet ?
<lincolnthree> gastaldi: I don't see why not
<vineetreynolds> nvm
<vineetreynolds> We need a facet for the dependency
<lincolnthree> vineetreynolds: yes
<vineetreynolds> ServletAPIFacet
<gastaldi> yeah, something like that
<lincolnthree> ServletApiFacet30
<gastaldi> like Faces does
<vineetreynolds> I dont think we should tie to the web.xml file
<vineetreynolds> unless we need to
<lincolnthree> vineetreynolds: if there is a web.xml file, it should be respected
<lincolnthree> if there is not, it should not be required for 3.0
<lincolnthree> but for 2.5 it should be
<vineetreynolds> Well, the dependency is more important imho
<gastaldi> lincolnthree, unless the PackagingType != WAR
<gastaldi> if it's a library, web.xml is never required in the current project
<lincolnthree> gastaldi: sure
<gastaldi> hence, should use named web-fragment
<gastaldi> s/use/be
<lincolnthree> gastaldi: again… only in 3.0
<gastaldi> yea
<gastaldi> in 2.5 should not rely on any descriptor if PackagingType is not WAR
<lincolnthree> correct
{quote}
--
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
10 years, 10 months
[JBoss JIRA] (FORGE-1064) ProjectListener should be an @Exported service
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-1064?page=com.atlassian.jira.plugin... ]
George Gastaldi commented on FORGE-1064:
----------------------------------------
Actually IMHO, I don't think this is a good idea, since it may occur that the same listener is registered more than once (one from the Imported and the other manually). I think we should just allow manual listener registration.
> ProjectListener should be an @Exported service
> ----------------------------------------------
>
> Key: FORGE-1064
> URL: https://issues.jboss.org/browse/FORGE-1064
> Project: Forge
> Issue Type: Enhancement
> Components: Builtin Plugins, Usability
> Affects Versions: 2.0.0.Alpha9
> Reporter: Lincoln Baxter III
> Assignee: George Gastaldi
> Fix For: 2.x Future
>
>
> The ProjectFactory should query the AddonRegistry for available ProjectListener services in addition to supporting the existing manual listener registration.
> {code}
> @Inject Imported<ProjectListener> listeners;
> {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
10 years, 10 months