[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
12 years, 7 months
[Neworg] report
by Rafael Benevides
Hi everybody,
There's two weeks that we frozen quickstarts repository and starting the
refactoring to the neworg.
Here is where we are at the moment:
1 - BOMs
1.1 - EAP Bom: *Lin Gao* provided the EAP 6.2 product version and it
is ready for now
1.2 - WFK Bom: There's a pull #2 that is under discussion with *Marek*
1.3 - JDG Bom: *Martin and Tristan* will provide the PR with the
versions updated to JDG 6.2
1.4 - BRMS Bom: No work on that
1.5 - Sandbox BOM: No work on that
2 - Quickstarts
2.1 - JDG Quickstarts is ready using 6.2.0-redhat-1. It will need to
update to JDG Bom when it gets updated (Thanks *Martin and Tristan*)
2.2 - Picketlink Quickstarts is ready using 6.2.0-redhat-1. It will
need to update to EAP ER is available (Thanks *Pedro Igor*)
2.3 - Richfaes Quickstarts . There is a PR with the modifications that
needs to be merged to upstream:
https://github.com/richfaces/jdf-quickstarts/pull/6 - RF-13194 is
assigned to *Brian Leathan *
2.4 - JPP Quickstarts was merged following the neworg definitions. It
needs to get its bom updated to JPP bom instead of Gatein BOM. I need to
check it with *Peter Palaga*
2.5 - JDF Quickstarts *Sande* is doing a hard work on it. Thanks
3 - Integration Quickstarts
3.1 - Fuse Quickstarts are following the neworg definitions:
https://github.com/jboss-fuse/quickstarts - But it uses the BOM that is
inside the Quickstarts repository. It should be refactored so it should
be possible to deliver the fuse quickstarts individually. *Antoine* is
working on that
3.2 - Switchyward Quickstart . *Hannelli* is contributing to the
migration but there are some quickstarts that are broken and need to be
fixed prior to the neworg changes.
4 - TicketMonster - It's a simple GAV change that *Vineet* can do it any
time.
5 - Definitions
5.1 - The plan is getting constantly update and it is available at:
https://docs.google.com/document/d/1HJQ61bYqlAehnpsO_vLZ5m0iC8FA4ob8Jqyvn...
5.2 - The version schema will follow <product-version>-SNAPSHOT -> E.R
Release: <product-version>-build-x --> G.A Release:
<product-version>-redhat-x
5.3 - The Engineering Release will be hosted on a nexus server. While
that isn't available, the ER artifacts will be hosted on
http://jboss-developer.github.io/ that points to
https://github.com/jboss-developer/temp-maven-repo (Thanks *Pete*)
6 - Archetypes -
6.1 - They will be refactored when the quickstarts are ready once the
archetypes are synched.
6.2 - There's a discussion with JBDS team (*Max* and *Fred Bricon*)
about the Enterprise Flag that won't be available on these archetypes.
7 - Satellite projects
7.1 - QSTools is ready on the neworg
7.2 - Stacks-Client is ready and will be moved together with stacks.yaml
7.3 - Stacks.yaml will be moved once that JBDS finished the tests and
the redirections worked perfectly (Thanks *Fred Bricon*)
If someone needs some help on any topic or have any comments, please,
feel free to ask me on #jboss-jdf or by email.
--
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
13 years
QSTools 1.2.3.Final released
by Rafael Benevides
This release fixes JDF-496 - NPE on SameVersionChecker
And it also includes a new feature/goal that permits to test the BOMs:
JDF-493
To test the boms you can run on the BOM project:
mvn -U org.jboss.maven.plugins:maven-qstools-plugin:*bom-check*
--
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
13 years
Fwd: JBoss Developer Version Schema
by Rafael Benevides
Hi folks,
As we talked earlier, the following definition should be used for JBoss
Developer Version Schema:
- For local Maven Artifacts, we'll keep using SNAPSHOT
- Example: 6.2.0-SNAPSHOT, 2.4.0-SNAPSHOT, etc
- For developers only Artifacts, we'll use -build-X
- This artifacts will not hit the Maven Central and should be only
delivered on a specific JBoss Nexus group
- Until we have this Nexus server available we will use
http://jboss-developer.github.io/temp-maven-repo/
- Example: 6.2.0-build-1, 6.2.0-build-2, 2.4.0-build-1
- For users, the product team will keep delivering it using -redhat-x
- Example: 6.2.0-redhat-1, 6.2.0-redhat-2, 2.4.0-redhat-1
A typical version evolution should follow:
6.2.0-build-1
6.2.0-build-2
6.2.0-build-3
6.2.0-build-...
6.2.0-redhat-1
....
6.2.0-build-4
6.2.0-build-...
6.2.0-redhat-2
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
13 years
Re: [jdf-dev] Picketlink version on EAP BOMs
by Pete Muir
IMO let's add the -with-security BOM only for EAP 6.2
On 9 Sep 2013, at 22:33, Pedro Igor Silva <psilva(a)redhat.com> wrote:
> As we discussed, 6.1 is shipped with PicketLink 2.1.
>
> The artifacts available with the Security BOM are for 2.5 (eg.: picketlink-api, picketlink-impl). So I'm not sure if makes sense to have those artifacts as they don't exist with 2.1.
>
> Users using 6.1 are PicketLink Federation users, which in most cases is just a matter of the PicketLink modules usage. But some times, users want to extend PicketLink Federation features and for that they need the 2.1 libraries on the classpath of their applications.
>
> Wondering if is better to change EAP 6.1 BOMs to match 2.1 artifacts.
>
>
> ----- Original Message -----
> From: "Rafael Benevides" <benevides(a)redhat.com>
> To: "Pedro Igor" <psilva(a)redhat.com>, "Anil Saldhana" <asaldhan(a)redhat.com>, "Peter Skopek" <pskopek(a)redhat.com>, "Marek Novotný" <mnovotny(a)redhat.com>, "Peter Muir" <pmuir(a)redhat.com>, "jdf-dev" <jdf-dev(a)lists.jboss.org>
> Sent: Monday, September 9, 2013 6:12:54 PM
> Subject: Re: Picketlink version on EAP BOMs
>
> Adding Pedro Igor...
>
> Em 09/09/13 17:36, Rafael Benevides escreveu:
>> Hi all,
>>
>> We released today the EAP BOMs version 6.2.0-redhat-1 with Picketlink
>> 2.5.1.
>>
>> Under EAP BOMs we will maintain for now two branches: 6.2.x and 6.1.x
>>
>> I was wondering that our branch 6.1.x should be fixed with the right
>> EAP 6.1.x version: Picketlink 2.1.6.
>>
>> Today I talked to Pedro Igor who told me that it seems a not easy job
>> to have the -with-security BOM for EAP 6.1.x/PL 2.16 for many reason
>> that he can explain better than me.
>>
>> Another approach that I'd like to query everyone is the possibility to
>> remove -with-security BOM from EAP 6.1.x if it is not possible to have
>> this BOM working fine for EAP 6.1.x
>>
>> I expected to hear your comments about the desired/right way to have
>> EAP 6.1.x BOM with -with-security/Picketlink BOM.
>>
>> Thanks
>>
>
13 years
QSTools 1.2.2.Final released
by Rafael Benevides
This version is recommended because it is much more "smart" dealing with
<dependencyManagement/>
Improvements:
- BomVersionChecker doesn't report violations for Managed Dependencies.
It considers just BOMs (scope=import/type=pom)
- DependencyChecker suggests using <dependencyManagement/> instead of
declaring versions under dependencies
- JDF-478 fix - ModuleDefinedChecker reports on quickstarts defined in
profiles other than default
With this released, we have now less false violations so it's easier to
focus on the real violations.
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
13 years
Picketlink version on EAP BOMs
by Rafael Benevides
Hi all,
We released today the EAP BOMs version 6.2.0-redhat-1 with Picketlink 2.5.1.
Under EAP BOMs we will maintain for now two branches: 6.2.x and 6.1.x
I was wondering that our branch 6.1.x should be fixed with the right EAP
6.1.x version: Picketlink 2.1.6.
Today I talked to Pedro Igor who told me that it seems a not easy job to
have the -with-security BOM for EAP 6.1.x/PL 2.16 for many reason that
he can explain better than me.
Another approach that I'd like to query everyone is the possibility to
remove -with-security BOM from EAP 6.1.x if it is not possible to have
this BOM working fine for EAP 6.1.x
I expected to hear your comments about the desired/right way to have EAP
6.1.x BOM with -with-security/Picketlink BOM.
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
13 years
JDF 2.1.7 released
by Rafael Benevides
This release includes:
- Latest quickstarts tag jdf-2.1.7.Final
- Latest JDF forge plugin
- Latest Stacks.yaml changes
- Ticket Monster 2.1.5.Final
- QSTools 1.2.1.Final
- Stacks-client 1.0.2.Final
From now, we are ready to freeze quickstarts repository and start the
new organization changes.
Thanks to everyone that helped this release, each contributor and all
the teams that supported it.
--
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
13 years
RFC on JDF-407 (Remove Errai and GWT from TicketMonster Tutorial)
by Vineet Reynolds Pereira
Hey all,
I've finished implementing a prototype (or maybe the final version depending on comments received) of a HTML5 based dashboard that replaces the Errai based dashboard. The HTML5 based version can be seen here: http://ticketmonster-vineetr.rhcloud.com/#monitor and the corresponding pull request is at : https://github.com/jboss-jdf/ticket-monster/pull/40/files
I request comments in two areas:
1. Supporting asynchronous HTTP request processing for JAX-RS resources
The current poller based approach is a bit expensive in that the client polls for changes at an interval of ~3 second and Two pollers operate, for two sub-views in the Backbone managed view and this is a bit expensive. I'd like to know if it would be demonstrate a long polling solution here. The server would then respond only when the state on the server changes; on timeout, the server would respond with the last state. Admittedly this would look better for the scenario where the bot is inactive, but it's better than aggressively polling an inactive app. We could demonstrate long polling, possibly via the support offered by RESTEasy <http://docs.jboss.org/resteasy/docs/2.3.0.GA/userguide/html_single/index....>.
Should I consider this?
NB - This may require adding a RESTEasy BOM in JDF; I havent implemented anything remotely close to a RESTEasy based prototype, so the GAVs in the BOM are unknown at this moment.
2. Using JAX-RS for non-RESTful resources
The earlier Bot operated using Errai Services that happened to be RPC endpoints. Transforming the bot service to use JAX-RS required throwing out the REST principles, and as such the JAX-RS resources behave like RPC endpoints instead of REST resources. To this extent, I had to use a mix of prototypical JavaScript classes and jQuery instead Backbone Models on the client. Likewise on the server-side, the Bot Log service responds with crude messages (see http://ticketmonster-vineetr.rhcloud.com/rest/bot/messages ) so that the textarea can be populated in the same manner as the Errai-based demo.
Should I attempt to conceive a RESTful Bot resource ?
Also, should I spend more time on a better Bot Log resource?
Thanks,
Vineet
13 years
