BOMs reorganization
by Rafael Benevides
Hi everybody.
Today we started the new organization procedures.
As part of the plan, the BOMs were moved to their new repositories and
branches were removed.
The next step is to release the BOMs and update the Stacks.yaml (them I
can start format update task on its new repository).
The new BOMs will be released using the following GAVs:
- org.jboss.bom.eap:jboss-javaee-6.0-with-xxxx:6.1.0-redhat-1
- org.jboss.bom.wfk:jboss-javaee-6.0-with-xxxx:2.4.0-redhat-1
- org.jboss.bom.brms:jboss-javaee-6.0-with-drools:5.3.1-redhat-1
- org.jboss.bom.jdg:jboss-javaee-6.0-with-infinispan:6.1.0-redhat-1
- org.jboss.bom.sandbox:jboss-javaee-6.0-with-all:1.0.7.Final
We will need to wait for Picketlink to release it's final version so we
can release the BOMs above. This is planned to happen on 08/28.
Please, help me check if the versions above is right for its first
version and please let me know if you have any questions.
--
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, 8 months
Re: [jdf-dev] [wfk] (WFK2-49 / JDF-424) Add Arquillian Showcase to Quickstarts
by Karel Piwko
On Fri, 16 Aug 2013 05:14:06 -0400 (EDT)
Mustafa Musaji <mmusaji(a)redhat.com> wrote:
> >> To me it makes more sense to Add Arquillian to the JDF Quickstarts then to
> >> Add Arquillian Quickstarts to JDF.
>
> +1
+1
>
> ----- Original Message -----
> > From: "Aslak Knutsen" <aknutsen(a)redhat.com>
> > To: "Andrew Lee Rubinger" <arubinge(a)redhat.com>
> > Cc: "Sande Gilda" <sgilda(a)redhat.com>, "jdf-dev" <jdf-dev(a)lists.jboss.org>,
> > wfk-pm-list(a)redhat.com Sent: Thursday, 15 August, 2013 5:04:07 PM
> > Subject: Re: [wfk] (WFK2-49 / JDF-424) Add Arquillian Showcase to
> > Quickstarts
> >
> > To me it makes more sense to Add Arquillian to the JDF Quickstarts then to
> > Add Arquillian Quickstarts to JDF.
> >
> > JDF already has Quickstarts for cdi, ejb, events, decorators etc etc etc etc
> > etc.. Why duplicate the tech based Quickstarts just to show how to test it.
> >
> > If we make the JDF Qucikstarts Testable, Arquillian is just along for the
> > ride. It's just there, just like junit/maven/jenkins. Infrastructure shit.
> > (Added bonus is you can automatically verify the Quickstart as well)
> >
> > It's 2013; testing is not something some test people do on the side when
> > they have time. Testing is Development. If you want to learn how to use
> > CDI, you need to learn how to test it as well.
> >
> > (Even if it's not for a lot of people; that should not be our message to the
> > world.)
> >
> > Add a section to all Quickstarts that describe the use of Arquillian in the
> > given example.
> >
> >
> > We might find some special cases that only can be described via an
> > 'Arquillian only Quickstart', but that would target Arquillian/Setup not EE
> > tech.
> >
> >
> > -aslak-
> >
> > ps: I know some of the JDF Quickstarts has Arquillian in them already, but
> > github is down atm so I didn't have a chance to see how many / in what state
> > / if it explained.
> >
> > ----- Original Message -----
> > > BTW, when I mentioned "fork" in the last message, this is equivalent to
> > > "porting" into JDF as Raf is ably doing.
> > >
> > > S,
> > > ALR
> > >
> > > ----- Original Message -----
> > > From: "Rafael Benevides" <benevides(a)redhat.com>
> > > To: "Karel Piwko" <kpiwko(a)redhat.com>
> > > Cc: "jdf-dev" <jdf-dev(a)lists.jboss.org>, wfk-pm-list(a)redhat.com, "Sande
> > > Gilda" <sgilda(a)redhat.com>, "Peter Muir" <pmuir(a)redhat.com>, "Aslak
> > > Knutsen"
> > > <aknutsen(a)redhat.com>, "Lukas Fryc" <lfryc(a)redhat.com>, "Andrew Lee
> > > Rubinger" <arubinge(a)redhat.com>
> > > Sent: Wednesday, August 14, 2013 8:58:32 AM
> > > Subject: Re: [wfk] (WFK2-49 / JDF-424) Add Arquillian Showcase to
> > > Quickstarts
> > >
> > > In this case, shouldn't we want to merge this PR in a 'jdf-quickstart'
> > > branch ?
> > >
> > > As the Jira issue title says "Add Arquillian Showcase to Quickstart",
> > > your previous opinion made total sense to me in this context:
> > > /"Historically, we've been removing all other container Maven profiles
> > > from code as we did community -> product conversion(take RichFaces for
> > > example). If Arquillian Showcase is going from Arquillian org
> > > (community) into JDF (product), we should follow the same path."/
> > >
> > >
> > > Em 14/08/13 05:09, Karel Piwko escreveu:
> > > > This might be a stupid question, but I though that removing of other
> > > > containers/build tools should happen on JDF level, not as a part of
> > > > arquillian.org. While most of the changes makes sense to have upstream
> > > > as well
> > > > to make fork closer to upstream, I can't agree with removal of profiles
> > > > and
> > > > build tools in upstream. Shouldn't JDF rather fork and Arquillian update
> > > > Showcase based on a part of JDF work?
> > > >
> > > > For Arquillian Showcase in upstream it is definitely reasonable to show
> > > > other
> > > > possibilities, like GlassFish or Ivy. Arquillian is not tied to JBoss.
> > > >
> > > > Karel
> > > >
> > > > On Tue, 13 Aug 2013 13:11:57 -0300
> > > > Rafael Benevides <benevides(a)redhat.com> wrote:
> > > >
> > > >> Hi all,
> > > >>
> > > >> I sent the following PR
> > > >> https://github.com/arquillian/arquillian-showcase/pull/17 for an
> > > >> earlier review. SO PLEASE DON'T MERGE IT YET.
> > > >>
> > > >> I made most changes under the cdi/ folder and that's were you should
> > > >> focus.
> > > >>
> > > >> Some changes:
> > > >>
> > > >> - Removed BOMs project/folder
> > > >> - Removed parent project/folder - Quickstarts should be treated as
> > > >> standalone
> > > >> - Removed gradlew, ant + ivy
> > > >> - Removed other containers profile and keep only arq-jbossas-managed
> > > >> and arq-jbossas-remote (removed -7 on the profile name)
> > > >> - Added license headers and Readme.md
> > > >> - Make cdi/pom.xml follow JDF guidelines.
> > > >> - Update GAV to
> > > >> org.jboss.quickstarts.wfk:jboss-arquillian-showcase-cdi:2.4.0-redhat-SNAPSHOT
> > > >> - Minor other changes
> > > >>
> > > >> I'll appreciate any feedbacks on this since I'll apply the same changes
> > > >> to all other folders/quickstarts
> > > >>
> > >
> > >
> >
> >
>
10 years, 8 months
Re: [jdf-dev] [wfk] (WFK2-49 / JDF-424) Add Arquillian Showcase to Quickstarts
by Rafael Benevides
Makes sense for me!
Anyway, the Friday meeting with everyone should help align the
expectations around https://issues.jboss.org/browse/WFK2-49
Em 15/08/13 13:04, Aslak Knutsen escreveu:
> To me it makes more sense to Add Arquillian to the JDF Quickstarts then to Add Arquillian Quickstarts to JDF.
>
> JDF already has Quickstarts for cdi, ejb, events, decorators etc etc etc etc etc.. Why duplicate the tech based Quickstarts just to show how to test it.
>
> If we make the JDF Qucikstarts Testable, Arquillian is just along for the ride. It's just there, just like junit/maven/jenkins. Infrastructure shit. (Added bonus is you can automatically verify the Quickstart as well)
>
> It's 2013; testing is not something some test people do on the side when they have time. Testing is Development. If you want to learn how to use CDI, you need to learn how to test it as well.
>
> (Even if it's not for a lot of people; that should not be our message to the world.)
>
> Add a section to all Quickstarts that describe the use of Arquillian in the given example.
>
>
> We might find some special cases that only can be described via an 'Arquillian only Quickstart', but that would target Arquillian/Setup not EE tech.
>
>
> -aslak-
>
> ps: I know some of the JDF Quickstarts has Arquillian in them already, but github is down atm so I didn't have a chance to see how many / in what state / if it explained.
>
> ----- Original Message -----
>> BTW, when I mentioned "fork" in the last message, this is equivalent to
>> "porting" into JDF as Raf is ably doing.
>>
>> S,
>> ALR
>>
>> ----- Original Message -----
>> From: "Rafael Benevides" <benevides(a)redhat.com>
>> To: "Karel Piwko" <kpiwko(a)redhat.com>
>> Cc: "jdf-dev" <jdf-dev(a)lists.jboss.org>, wfk-pm-list(a)redhat.com, "Sande
>> Gilda" <sgilda(a)redhat.com>, "Peter Muir" <pmuir(a)redhat.com>, "Aslak Knutsen"
>> <aknutsen(a)redhat.com>, "Lukas Fryc" <lfryc(a)redhat.com>, "Andrew Lee
>> Rubinger" <arubinge(a)redhat.com>
>> Sent: Wednesday, August 14, 2013 8:58:32 AM
>> Subject: Re: [wfk] (WFK2-49 / JDF-424) Add Arquillian Showcase to Quickstarts
>>
>> In this case, shouldn't we want to merge this PR in a 'jdf-quickstart'
>> branch ?
>>
>> As the Jira issue title says "Add Arquillian Showcase to Quickstart",
>> your previous opinion made total sense to me in this context:
>> /"Historically, we've been removing all other container Maven profiles
>> from code as we did community -> product conversion(take RichFaces for
>> example). If Arquillian Showcase is going from Arquillian org
>> (community) into JDF (product), we should follow the same path."/
>>
>>
>> Em 14/08/13 05:09, Karel Piwko escreveu:
>>> This might be a stupid question, but I though that removing of other
>>> containers/build tools should happen on JDF level, not as a part of
>>> arquillian.org. While most of the changes makes sense to have upstream as
>>> well
>>> to make fork closer to upstream, I can't agree with removal of profiles and
>>> build tools in upstream. Shouldn't JDF rather fork and Arquillian update
>>> Showcase based on a part of JDF work?
>>>
>>> For Arquillian Showcase in upstream it is definitely reasonable to show
>>> other
>>> possibilities, like GlassFish or Ivy. Arquillian is not tied to JBoss.
>>>
>>> Karel
>>>
>>> On Tue, 13 Aug 2013 13:11:57 -0300
>>> Rafael Benevides <benevides(a)redhat.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I sent the following PR
>>>> https://github.com/arquillian/arquillian-showcase/pull/17 for an earlier
>>>> review. SO PLEASE DON'T MERGE IT YET.
>>>>
>>>> I made most changes under the cdi/ folder and that's were you should
>>>> focus.
>>>>
>>>> Some changes:
>>>>
>>>> - Removed BOMs project/folder
>>>> - Removed parent project/folder - Quickstarts should be treated as
>>>> standalone
>>>> - Removed gradlew, ant + ivy
>>>> - Removed other containers profile and keep only arq-jbossas-managed and
>>>> arq-jbossas-remote (removed -7 on the profile name)
>>>> - Added license headers and Readme.md
>>>> - Make cdi/pom.xml follow JDF guidelines.
>>>> - Update GAV to
>>>> org.jboss.quickstarts.wfk:jboss-arquillian-showcase-cdi:2.4.0-redhat-SNAPSHOT
>>>> - Minor other changes
>>>>
>>>> I'll appreciate any feedbacks on this since I'll apply the same changes
>>>> to all other folders/quickstarts
>>>>
>>
10 years, 8 months
Re: [jdf-dev] [Fuse Quickstart] JDF Fuse quick start ready for review
by Antoine Sabot-Durand
Gert,
The main idea is to demonstrate Unit Test to user. It is very unlikely that we break our example code but if these can provide security on that it would be perfect.
If you take the rest test class as an example : https://github.com/jboss-fuse/quickstarts/blob/master/rest/src/test/java/...
The only need is to be able to launch fuse (cxf part at least) and deploy the quick start bundle before launching the test. If we can perform that with Camel test it's great as they seem to be the simplest solution.
Could you point me to test example for the 2 solutions?
Thanks,
Antoine
Le 13 août 2013 à 22:19, Gert Vanthienen <gvanthie(a)redhat.com> a écrit :
> Antoine,
>
>
> What kind of tests are we talking about here? Is the goal to show users how to unit test their code or are these tests more like integration tests to make sure we don't break the example code while we're developing the product?
>
> If it's the former we're looking for, we can just use Camel's test support for most of these tests. It probably makes sense to include a few of these tests anyway, it's a very commonly used feature of Camel.
>
> For the latter, we do use Pax Exam for that ourselves (and we probably should build those tests for these quickstarts, either as part of Fuse ESB or as part of the quickstarts repo), but it's a bit harder for our users to do the same. Pax Exam Karaf requires access to the container distribution zip file - the most convenient way to get this, is by downloading those from a Maven repository, but since these distributions are no longer available that way, it would require them to download them from the portal and then configure the tests to pick it up. How does Arquillian do that?
>
>
> Regards,
>
> Gert
>
>
> ----- Original Message -----
> From: "Antoine Sabot-Durand" <asd(a)redhat.com>
> To: "Gert Vanthienen" <gvanthie(a)redhat.com>
> Cc: "jdf-dev" <jdf-dev(a)lists.jboss.org>, "Aileen Cunningham" <aileenc(a)redhat.com>, "Muir Pete" <pmuir(a)redhat.com>, "Rafael Benevides" <benevides(a)redhat.com>, "Hanneli Tavante" <hannelita(a)gmail.com>
> Sent: Tuesday, August 13, 2013 3:47:47 PM
> Subject: Re: [Fuse Quickstart] JDF Fuse quick start ready for review
>
> Thanks Gert,
>
> The only thing that bothers me in these quick start are tests. I transformed some client test code to real integration test but do it well I should have added a way to bundle and launch the sample in Fuse before launching the test.
> We don't have Arquillian solution for fuse but perhaps could we use Pax-Exam which looks like to be the standard integration test engine for fuse? What do you think?
>
> Antoine
>
> Le 13 août 2013 à 14:22, Gert Vanthienen <gvanthie(a)redhat.com> a écrit :
>
>> Hanneli and Antoine,
>>
>>
>> I had a quick look at them and pushed a few minor fixes to suppress build warnings and get the README.md files looking a bit better on GitHub's rendering of Markdown, but other that than the code and README's look very clear and consistent now. Thanks a lot for all your efforts! The examples look better than ever!
>>
>> Next step on our end will be to get these examples integrated into the product again. Just noticed we had one more outstanding issue with the *-secure examples to better describe what exactly we mean with "secure" (cfr. http://fusesource.com/issues/browse/ENTESB-228) - perhaps we should fix up the docs on the new quickstarts instead?
>>
>>
>> Regards,
>>
>> Gert
>>
>> ----- Original Message -----
>> From: "Antoine Sabot-Durand" <asd(a)redhat.com>
>> To: "jdf-dev" <jdf-dev(a)lists.jboss.org>
>> Cc: "Gert Vanthienen" <gvanthie(a)redhat.com>, "Aileen Cunningham" <aileenc(a)redhat.com>, "Muir Pete" <pmuir(a)redhat.com>, "Rafael Benevides" <benevides(a)redhat.com>, "Hanneli Tavante" <hannelita(a)gmail.com>
>> Sent: Tuesday, August 13, 2013 11:12:47 AM
>> Subject: [Fuse Quickstart] JDF Fuse quick start ready for review
>>
>> Hi all,
>>
>> Hanneli and I have just finished to refactor Fuse example in JDF quick start format. You'll find them here : https://github.com/jboss-fuse/quickstarts
>>
>> Your feedback is most welcome.
>>
>> Antoine
>
10 years, 8 months
(WFK2-49 / JDF-424) Add Arquillian Showcase to Quickstarts
by Rafael Benevides
Hi all,
I sent the following PR
https://github.com/arquillian/arquillian-showcase/pull/17 for an earlier
review. SO PLEASE DON'T MERGE IT YET.
I made most changes under the cdi/ folder and that's were you should focus.
Some changes:
- Removed BOMs project/folder
- Removed parent project/folder - Quickstarts should be treated as
standalone
- Removed gradlew, ant + ivy
- Removed other containers profile and keep only arq-jbossas-managed and
arq-jbossas-remote (removed -7 on the profile name)
- Added license headers and Readme.md
- Make cdi/pom.xml follow JDF guidelines.
- Update GAV to
org.jboss.quickstarts.wfk:jboss-arquillian-showcase-cdi:2.4.0-redhat-SNAPSHOT
- Minor other changes
I'll appreciate any feedbacks on this since I'll apply the same changes
to all other folders/quickstarts
--
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, 8 months
Re: [jdf-dev] [Fuse Quickstart] JDF Fuse quick start ready for review
by Antoine Sabot-Durand
Thanks Gert,
The only thing that bothers me in these quick start are tests. I transformed some client test code to real integration test but do it well I should have added a way to bundle and launch the sample in Fuse before launching the test.
We don't have Arquillian solution for fuse but perhaps could we use Pax-Exam which looks like to be the standard integration test engine for fuse? What do you think?
Antoine
Le 13 août 2013 à 14:22, Gert Vanthienen <gvanthie(a)redhat.com> a écrit :
> Hanneli and Antoine,
>
>
> I had a quick look at them and pushed a few minor fixes to suppress build warnings and get the README.md files looking a bit better on GitHub's rendering of Markdown, but other that than the code and README's look very clear and consistent now. Thanks a lot for all your efforts! The examples look better than ever!
>
> Next step on our end will be to get these examples integrated into the product again. Just noticed we had one more outstanding issue with the *-secure examples to better describe what exactly we mean with "secure" (cfr. http://fusesource.com/issues/browse/ENTESB-228) - perhaps we should fix up the docs on the new quickstarts instead?
>
>
> Regards,
>
> Gert
>
> ----- Original Message -----
> From: "Antoine Sabot-Durand" <asd(a)redhat.com>
> To: "jdf-dev" <jdf-dev(a)lists.jboss.org>
> Cc: "Gert Vanthienen" <gvanthie(a)redhat.com>, "Aileen Cunningham" <aileenc(a)redhat.com>, "Muir Pete" <pmuir(a)redhat.com>, "Rafael Benevides" <benevides(a)redhat.com>, "Hanneli Tavante" <hannelita(a)gmail.com>
> Sent: Tuesday, August 13, 2013 11:12:47 AM
> Subject: [Fuse Quickstart] JDF Fuse quick start ready for review
>
> Hi all,
>
> Hanneli and I have just finished to refactor Fuse example in JDF quick start format. You'll find them here : https://github.com/jboss-fuse/quickstarts
>
> Your feedback is most welcome.
>
> Antoine
10 years, 8 months
Re: [jdf-dev] [BRMS Quickstart] - Sandbox
by Rafael Benevides
Hi all.
After some discussions we decided to move the BRMS quickstarts to the
sandbox repository for a while.
https://github.com/jboss-jdf/jboss-quickstarts-sandbox/pull/1
This will allow us to get more time to work on items like, BRMS server
setup, Maven dependencies setup, Folder structure, JBDS (items pointed
from Max), and use case scope (since these BRMS demos are more complete
-and complex- than our usual quickstarts).
After we move again on this, I'll send another email to communicate
Em 08/08/13 08:32, Eric D. Schabell escreveu:
> On Aug 8, 2013, at 11:57 , Max Rydahl Andersen <manderse(a)redhat.com> wrote:
>
>> On Tue, Aug 06, 2013 at 02:31:44PM +0200, Eric D. Schabell wrote:
>>> https://github.com/eschabell/brms-customer-evaluation-demo/blob/master/Qu...
>>> https://github.com/eschabell/brms-rewards-demo/blob/master/Quick%20Start%...
>>> https://github.com/eschabell/brms-coolstore-demo/blob/master/Quick%20Star...
>> Thanks, and now github stopped showing angry unicorns so I can actually see the examples.
>>
>> First of, i'm all for getting more examples in, but I'm also really not a fan of handing out instructions/urls that is known to be bad/too temporary.
>>
>> But lets see what we can do about them - if this just stays in the sandbox and are clearly marked experimental I don't have a problem, having it available is better than to hide it completely.
>>
>> Non-stable plugin updatesite url
>> ================================
>>
>> First issue is the use of http://download.jboss.org/jbosstools/updates/integration/kepler/integration-
>> stack/aggregate/4.1.0/ as the updatesite url to add. This url is *not* a stable url and will not be guaranteed to exist nor contain what will work with your examples. I've asked SOA tooling guys to provide a stable url for community usage but that have not happened yet and thus i'm stuck waiting for them to release a JBDS 7 update url.
>>
> This is what is available and what we have to use.
>
>
>> Besides the url being non-stable it definitely should not be used together with JBDS 5 and 6 since if you add this updatesite to JBDS 5 and 6 and you run Help > Update it will pick up newer versions of eclipse/jbds which probably is *not* what the user wanted/expected. (note, the instructions just seem to talk about JBDS 7so thats fine, just referring to you saying it works on JBDS 5 and 6 too).
>>
> The demo project is around so long that we have moved (see releases) through JBDS 5 to 7 now.
>
>> Finally, that url contains *more* than what is supported - i.e. savara tooling is not a supported tech yet. It's the community version as opposed to the supported version.
>>
> Nothing I can do about that.
>
>> Non-clean pom versioning
>> ========================
>>
>> Second issue is that the GAV's seem to be using the BRMS version for the jars instead of the actual base community version of the jars.
>> i.e. 5.3.1.BRMS seem to be the base for all in here but org.drools and org.jbpm wasn't released under a 5.3.1.* version afaics.
>>
> I am only interested in providing products, this is JBoss BRMS. The upcoming versions are supposed to start supplying maven artifacts into the central jboss repos, but until then, this is the pragmatic solution we have chosen after discussions with jBPM / Drools teams.
>
>> Can't these be updated to actually use the proper versions following the Project Wolf guidelines ?
>>
> Nope.
>
>> Note: if jbpm and drools actually released 5.3.1 and that is what BRMS 5.3.1 is based on then we are all good - but that is just not
>> my understanding on how BRMS was built, i.e. jbpm was 5.2.x and drools 5.3.x (according to Julien from productization)
>>
> The primary goal is to use these in the field, allowing them to demo products which we are trying to sell.
>
> The idea of GoldenGate, as preached to me, is to propogate early access to products and not projects. If this is not the case, then you will not want to be reviewing my demos for usage.
>
> Having worked with drools and jbpm in an enterprise, I don't even want to try and keep Integration & BPM projects aligned and working with the diverse components that are merged into the JBoss BRMS / BPM Suite products.
>
> These demos are specific examples of how to get things done, in JBDS with BRMS plugins as available, on EAP versions. You can't sell what you are describing here above, so no point in my moving from products over to project components.
>
> -- erics
10 years, 9 months