Trying to understand BOM's
by Julian Coleman
Hi,
I'm trying to understand how we should use BOM's and which ones we should
use. As far as I understand it, EAP has a "build" BOM:
org.jboss.component.management:jboss-dependency-management-all:6.1.0-redhat-2
a supported artifact BOM:
org.jboss.bom:eap6-supported-artifacts:6.2.1.GA
plus some "developer" BOM's:
org.jboss.bom/eap:jboss-javaee-6.0-with-tools:6.2.1.GA
org.jboss.bom/eap:jboss-javaee-6.0-with-osgi:6.2.1.GA
However, FSW/DV/BRMS/BPMS only has a single BOM:
org/jboss/ip/component/management/ip-dependency-management-all/1.1-redhat-5
which is used for both the build, and for developers.
So, my question is:
should FSW/DV/BRMS/BPMS also have the "developer" BOM's?
I see that the BRMS quickstarts have their own jboss-javaee-6.0-with-drools
BOM. I guess that this needs to be built with the product, so that it can
be uploaded to the hosted repository [#] (assuming that the answer to the
above is "yes").
Thanks,
J
[#] See "JBoss Developer Materials Repository Management and Releases".
--
Red Hat
Newcastle upon Tyne
10 years, 1 month
PicketLink Federation Quickstarts
by Pedro Igor Silva
Hi All,
After discussing with Sande about the best way to port the PicketLink Federation (SAML SSO) Quickstarts [1] to the PicketLink JDF Quickstarts [2], she asked me to open a thread to collect some more suggestions about the best way of doing it.
Basically, the 'issue' we have is that our federation quickstarts depend on each other. This is important because users won't get the whole functionality if they deploy just one of the quickstarts. Those quickstarts demonstrate SSO, so we need an authentication authority, which we call IdP (Identity Provider), and its relying parties, which we call SP (Service Provider).
Today we have 5 different IdP applications, and a bunch of SP ones. Each SP relies on a specific IdP, so in order to get functionality working we need them deployed together.
Those quickstarts from [1] are not new, users and also customers are very used to see them this way(as separated WARs which you deploy and test our functionality). Sande suggested us to think about having a EAR with all related applications, but this goes against PL real world use cases and gives a very wrong understanding about PL usage. For us and our users, the best thing is keep each quickstart as a single WAR.
So, given all that, I would like to collect some feedback about the best way to document those quickstarts in their README files. Can we have a section to reference other related quickstarts ?
Probably with links to other quickstarts so we can tell users what they need to do to get the environment properly set ?
Any other suggestion ?
[1] https://github.com/picketlink2/picketlink-quickstarts/tree/master/saml
[2] https://github.com/jboss-developer/jboss-picketlink-quickstarts
Best regards.
Pedro Igor
10 years, 1 month
Stacks Client Filter
by James R. Perkins
Hello All,
It's been a while since I looked at the stacks client, but I'm getting
ready to start using it in the wildfly-maven-plugin so I thought I would
have a look again.
My usage of this is to just get the latest WildFly version, which means
I don't really care about all the available runtimes. I thought about
adding a filter[1] to most of the getter methods. Just wanted to know if
this would be helpful to anyone else or not. I just did a quick proof of
concept on it. If no one else finds it useful it's something I could
easily implement in the maven plugin.
Also while looking at the code I see the model was all moved to
interfaces and a concrete implementation. The implementation seems to be
exposed to the public though. Are there any plans to make these package
private so the implementation doesn't leak out?
[1]: https://github.com/jamezp/jdf-stacks-client/compare/filter
--
James R. Perkins
Red Hat JBoss Middleware
10 years, 2 months
[neworg] - Clarification about project vs product BOMs
by Rafael Benevides
Hi all,
This email has the intention of clarifying some issues that are appearing as a result of the "new organization" changes, particularly around BOMs and their versions.
As we now focus on the_products_, we changed the version of the BOMs and Quickstarts to follow the target_product_ version: EAP 6.2.0, WFK 2.4.0, JDG 6.2.0, etc.
Since the j/boss-javaee-6.0-with-*/ BOMs are now target to its_products_ versions, we work with the_products_ teams to ensure the right dependency versions of components are used.
Until we get the Beta or GA versions of these BOMs, we host "developer releases" (using/-build-x/ suffix) onhttp://jboss-developer.github.io/temp-maven-repo/
We expect to move this repo in the newt few months, to a nexus managed instance
When the product is build, the version will be changed from/-build-x/ suffix to/-redhat-1/ suffix and when a beta or GA is released will be inhttp://maven.repository.redhat.com/techpreview/all/ orhttp://maven.repository.redhat.com/earlyaccess/all
We don't intend to sync thehttp://jboss-developer.github.io/temp-maven-repo/ to Maven Central.
Ok! But some_project_ teams are asking how they should treat their quickstarts given the fact that the_project_ delivers their quickstarts but the BOMs will not be available on Maven Central.
We're recommending the_project_ team that have their own_project_ BOMs using their_project_ GAV. Taking Richfaces and Arquillian as example:
- Richfaces provides their own BOM under the following GAV: org.richfaces:richfaces-bom:4.3.2.Final
- Arquillian provides their own BOM under the following GAV: org.jboss.arquillian:arquillian-bom: 1.1.0.Final
- Richfaces is used on WFK 2.4.0 so we wrap the Richfaces BOM under the following GAV:/org.jboss.bom.wfk: jboss-javaee-6.0-with-richfaces:2.4.0-/... ->https://github.com/jboss-developer/jboss-wfk-boms/blob/master/jboss-javae...
- Arquillian is also used on EAP 6.2.0 so we wrap the Arquillian BOM under the following GAV:/org.jboss.bom.eap: jboss-javaee-6.0-with-tools:6.2.0/-.... ->
https://github.com/jboss-developer/jboss-eap-boms/blob/master/jboss-javae...
As conclusion, we're suggesting that upstream_project_ create BOMs, and then the_product_ can wrap this BOM under the/org.jboss.bom.<_product_>: jboss-javaee-6.0-with-<_project_>:<_product_-version>/. This allows for easy identification of which BOM and version to use for both upstream and_product_."
If you have any further question on how it works, please let me know.
Please, forward to anyone you think that maybe interested in this email content.
Thanks
--
Rafael Benevides | Senior Software Engineer
Red Hat Brazil
+55-61-9269-6576
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 2 months
