Rafael, Jason and I did a brainstorm about this at JUDCon Brazil, and came up with the following proposal:
* jdf plugin for forge - longer term needs rolling into Forge core. This is issue https://issues.jboss.org/browse/FORGE-378. As this is proposed for Forge 2, we suggest not altering the version or group id of this plugin
* qstools - version scheme (starting 1.x) is good. Alter group id when we do the next major release only
- change group id to follow products:
- org.jboss.quickstart.eap, org.jboss.quickstart.jdg etc.
- add a sandbox group id which covers quickstarts not in products
- change versions to follow products major.minor.micro version, with a qualifier to allow bug fixes:
- e.g. 6.0.1-qs-1, 6.0.1-qs-2 etc
- use group id scheme same as quickstarts but use org.jboss.archetype.eap etc.
- follow same version scheme as quickstarts, but use -atype-1 etc.
- use group id scheme same as quickstarts but use org.jboss.bom.eap etc.
- follow same version scheme as quickstarts, but use -bom-1
- projects will be encouraged to create BOMs as well
Let me know what you think,
I updated the POM file in the root of the quickstart directory today ran
the "mvn clean install '-Pdefault,!complex-dependencies'" command to
test that they all still compile. I discovered the
/picklink-deltaspike-authorization/ quickstart no longer compiles due to
changes in the DeltaSpike security API.
Would it be possible to set up a daily job to run this command and send
an email when errors are found?
This is the first of what I hope will be a monthly report summarizing
the status of the open quickstart pull requests. It is constantly
changing, so the report below is just a snapshot at this point in time.
- If you have an outstanding pull request and we are waiting for your
updates, this will serve as a reminder. I'm not judging here. ;-)
- If you would like to volunteer to test any of them or do code
reviews, please help yourself and make your comments in the pull.
*Pull* *Quickstart Name* *Contributor* *Status* *Details*
350 ejb-multi-server Wolf Fink Needs code review Needs final code
435 deltaspike-partialbean-basic deltaspike-partialbean-advanced Jesse
Sightler Needs code review Needs final code review.
445 hornetq-clustering Jesse Sightler Needs code review Waiting for
review by Pete (or someone); This also needs CLI scripts
463 servlet-security-genericheader-auth Jesse Sightler Needs code
review Waiting for review by Darran Lofthouse
510 petclinic-spring Tejas Mehta Needs code review Needs final code
541 picketlink-authentication-form Anil Saldhana Needs code review
New pull, not yet reviewed
317 ejb-timer Ondra Zizka Waiting for developer Waiting for Ondra to
322 negotiation-toolkit Darran Lofthouse Waiting for developer
Waiting for Darran to finish
351 helloworld-mbean Jeremie LaGarde Waiting for developer Recently
updated to use jconsole; I sent a modifed README to Jeremie; QS Tools
also reports errors
363 kitchensink cheatsheet Snjezana Peco Waiting for developer Still
waiting for response from Max as to whether this cheatsheet is outdated.
427 cluster-singletonbean Radoslav Husar Waiting for developer The
password used for this quickstart no longer meets the rules. Waiting for
Radoslav code and README changes
439 cdi-portable-extension-drools Marco Battaglia Waiting for
developer Shrinkwrap resolver API has changed. Code doesn't compile.
Waiting for Marco to update the code.
485 travel-spring Tejas Mehta Waiting for developer Tejas reports
travel-spring still needs to be rebased to match the current version
539 picketlink-authentication-facebook Anil Saldhana Waiting for
developer Tested and works great. Waiting for developer to add CLI
scripts and update the README with instructions to use them.
540 picketlink-authentication-twitter Anil Saldhana Waiting for
developer Running into a few testing issues. Waiting for developer to
add CLI scripts and update the README with instructions to use them.
478 kitchen (functional tests) Stefan Miklosovic Waiting for
Graphene2 Waiting for Graphene2 to get into the WFK -- late July
We've got this issue https://issues.jboss.org/browse/JBDS-2557 and https://issues.jboss.org/browse/JDF-199 open for a while.
Main gist is to use eclipse cheatsheets where possible for quickstarts and archetypes since
they can be more interactive/guiding of the user.
From talking with Pete, he said he would prefer not to spend time on this before
a simple import of a quickstart from disk (not using JBoss Central) could open these
Thus in Beta1 and Beta2 of JBoss Tools we added a few things to make this happen + some documentation.
They are illustrated here: http://docs.jboss.org/tools/whatsnew/examples/examples-news-4.1.0.Beta1.html
A) There is now an option for showing cheatsheets if a project being opened has .cheatsheet.xml or cheatsheet.xml in the root of the project.
(Beta1 had it default off for testing, in Beta2 we've enabled it by default)
B) We've made it so you can right click on a cheatsheet.xml file or a project and use "Show In > Cheat sheets" for testing and for the case where
the user have *not* enabled the autoopen.
C) We've added two cheatsheets commands to make it easier to script for hightlighting things in the sourrouding project.
Together with this is a screenshot showing how this works: http://screencast.com/t/gK5JggVU
plus I created https://github.com/maxandersen/cheatsheet-helloworld which if you import it in jbosstools Beta2 will open it s cheatsheet.xml and show the basics.
I hope this is sufficient now to get started on this.
I don't think *all* quickstarts should have cheatsheets, but I think it would be interesting to add for those where it can be used to enhance the explanations found in the readme.md files.
Let me know if questions, and if we can help more in getting you started on writing these.
p.s. there is a cheetsheet.xml editor in eclipse, its great to get started with and browse for other good commands to use, but I suggest editing by hand since
the visual editor does seem to reformat/edit at bit too agressively.
The Hibernate Search enabled version of TicketMonster relies on
Hibernate Search 4.3 which itself has a dependency on Hibernate ORM
included in WildFly and JBoss EAP.
My first approach was to ask the user to add the Hibernate Search JBoss
Module manually into their EAP / WildFly distribution and have it
referenced in jboss-deployment-structure.xml.
I also had to put Hibernate Search in my POM as provided because the BOM
references an older version of Hibernate Search.
To avoid the manual step, I tried to list Hibernate Search explicitly in
the POM as regular scope and no longer use
jboss-deployment-structure.xml. But then I have to play with exclusions
which is not too nice either.
Which approach is better suited for TicketMonster? And is there a better
Here is the commit that moves from a module dependency to plain pom.xml
I did my marathon for my JUDCon presentation and integrated Hibernate
Search with TicketMonster. It is currently sitting in working form at
In short, there are:
- a search box
- a full-text search engine looking for event and venue names and
- an option to only search around you (50km) to demo geolocal searches
- faceting meaning the ability to filter results by category and by
While it is stable for my demo and while I am working on the tutorial
page, I would like to open the project up for contribution and list the
set of todos before we can integrate it into the main branch.
What's the best way to start contributing on a feature branch?
Does it make sense to push a hibernate-search branch to
http://github.com/jboss-jdf/ticket-monster while it matures?
Likewise, can I create my todos as JDF JIRAs? Maybe with a label?
For info the list of todos I have for the moment are
- Facets when selected have the wrong number for other sections
- search box is not centered
- implement search for the mobile version
- check that my code is sound (TiMo team) on backbone
- use backbone to represent the form publication of the search engine
- add admin console changes for the lat / long model change
- add pagination
- fix excludeLimit / type in faceting (HSEARCH-1338 / 1339)
- fix FacetGroupView and selection computation HSEARCH-1346
- consider using more regular POMs and not rely on JBoss Modules (it's a
pain for a user IMO as it required to play with the POM, update the
server modules and add the jboss-deployment file)
- finish tutorial :)
Of course the contribution will suffer from regular rebasing from master
but that's inevitable regardless of the scheme.
This is mostly to let you know where I am with the JDF issues that are assigned to me in JIRA.
Update TicketMonster for EAP 6.1:
* JDF-262 This was more or less complete, but for 6.1.0Alpha1. I need to go through once again through for EAP 6.1 GA related changes. Updates to the TiMo POM is most likely the only pending issue here.
* JDF-341 I need to make appropriate changes to the Forge script, and also verify that this would work on the community version (AS 7.1.1) we support. This is probably a different topic, but we may eventually have to drop AS 7.1.1 support (and/or introduce WildFly support at some time) since some of the JBoss modules would be outdated/not in sync compared to the EAP version.
* JDF-257 The JDF plugin needs to be enhanced to recognize community bits like RichFaces and replace them in the POM with the productized versions. I'm afraid I havent gotten around to this.
Corrections to Documentation:
* JDF-195 This is partially complete. I need to verify if the behavior of ADT installation from JBDS has been captured correctly; this seems to work differently when ADT and/or the Android SDK Tools is already installed on the machine.
* JDF-193 + JDF-196 This is more or less complete. I'll verify that it hasn't been impacted by the EAP 6.1 GA release, and merge the changes.
* JDF-259 This is partially complete, and needs syncing with the code changes made over the past couple of weeks.
* JDF-260 This is partially complete, and needs syncing with the code changes made over the past couple of weeks.
Issues pertaining to OpenShift deployments:
* JDF-339 This is a problem with the URL references in the image tags. Needs correction and some bit of testing for both desktop and mobile browsers.
* JDF-343 I haven't diagnosed this entirely, since I noticed this only when finishing off some work yesterday. Infinispan config related changes are expected. This did work previously with no changes to the app.
Forge generated scaffolding for TiMo:
* JDF-161 This has been triaged. All TiMo related issues have been sorted individually. Forge scaffolding related issues would be handled in Forge 1.3.1 and later (atleast one bug is fixed in 1.3.1 thus far, and maybe a few more if the release timeframe permits).
* JDF-118 This is dependent on JDF-161 is certain aspects. I'm undecided on whether to target Forge 1.3.0 or 1.3.1, since 1.3.1 is expected to require changes in the patches we have (or require newer patches) as well as changes to the checked-in scaffold. The patch approach would continue to be used since the documentation does not require checking out the sources from Git and building it.
Browser bugs in TiMo:
* JDF-325. I've found the root cause, but havent gotten around to applying and testing the fix even though it looks minor. It would require testing the fix on all browsers and mobile devices due to changes in the jQuery.ajax() configuration.
* JDF-329. This issue is a bit strange. I was unable to reproduce this on Safari 5.1.7 (Lion) and Safari 6.0.1? (Mountain Lion). I'll verify this further. A related issue going by Emmanuel's comments would be the browser versions we support for the Errai bits in TiMo. I've verified them to work on FF, Chrome, IE9 and 10, but not for Safari.
* JDF-328. Need to study this in a bit more detail to provide a fix.
* JDF-335. This is reliant on the Hybrid Mobile Project feature in JBT/JBDS. I intend to pick this up once it goes GA since this requires documentation + site updates.
* JDF-277. This would probably be closed as Wont-Fix, since we cannot fix this in our sources and requires a WebKit update in RHEL 6.x.
I'd like to know if anyone knows of related issues that I could fix in conjunction with these. Also, I'll be working on these in the order specified above (atleast in the categories presented), so if the priorities need to be sorted, do let me know.