OFBiz › OFBiz - Dev

jquey

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

49 messages Options

123

Jacques Le Roux

Re: jquey

Administrator

IMO, there are 2 options for releasing branch(es).

* Only one which will be later the official release. The problem is then whether people want to have Dojo/Prototype or jQuery in
this new release branch.

* Two branches, one which which will be later the official release and one which will not be officially released. I would consider
it
as a fork since it would have Dojo/Prototype when the official will have later jQuery. Maybe fork is not really appropriate, but I
think you get my point.

We could also make 2 official releases. One with Dojo/Prototype and another with jQuery. I'm not quite sure switching from
Dojo/Prototype to jQuery requires a specific release...

Other opinions, ideas?

Thanks

Jacques

Bruno Busco wrote:

> Why you think that making a new release branch would create a fork?
> It will be managed as we manage R10.04 and R9.04 right now.
> Only bug fixes will be backported.
>
> -Bruno
>
>
> 2010/12/2 Jacques Le Roux <[hidden email]>
>
>> Ryan Foster wrote:
>>
>>> What about creating a tag or branch before the merge so that users who
>>> have custom projects or applications based on the trunk
>>> have a reference point in the event that they want to freeze their
>>> applications at a particular revision?
>>>
>>
>> Yes, that's what I have proposed. With another option: to have a branch.
>> But I think the later is more a fork and I prefer the 1st.
>>
>>
>> Oh and +1 on merging in JQuery. I am all for consolidating/simplifying
>>> our Javascript libraries. No reason to have 3 libraries
>>> that all essentially do the same thing. In the end, Javascript is
>>> Javascript. My heart says we should have chosen Prototype as
>>> that one (as anyone who knows me would agree, I'm a big Prototype JS
>>> evangelist). But, my head says that JQuery is the right
>>> choice for the long-term growth and success of the project, as it has
>>> definitely become the drug of choice for a majority of
>>> developers and has much more wide-spread community involvement as far as
>>> development of plugins is concerned.
>>>
>>
>> I think we now all agree on that
>>
>> Jacques
>>
>>
>> Ryan L. Foster
>>> 801.671.0769
>>> [hidden email]
>>>
>>> On Dec 2, 2010, at 11:18 AM, Jacques Le Roux wrote:
>>>
>>> I'm sorry for Bruno, but it seems everybody is looking forward for this
>>>> merging. So hopefully I will do it soon.
>>>> If you are interested you can already check
>>>> https://issues.apache.org/jira/browse/OFBIZ-3814
>>>>
>>>> Jacques
>>>>
>>>> Michael Xu (xudong) wrote:
>>>>
>>>>> +1
>>>>>
>>>>> Yeah, I would love such a great Xmas present :-)
>>>>>
>>>>>
>>>>> You're welcome
>>>>>> +1
>>>>>>
>>>>>> Would be a great Xmas present to merge all the stuff into the trunk :-)
>>>>>>
>>>>>> Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES <
>>>>>> [hidden email]>:
>>>>>>
>>>>>> Le 02/12/2010 10:35, Jacques Le Roux a écrit :
>>>>>>>
>>>>>>>> Looks like, apart Bruno, we are all on the same page so far
>>>>>>>>
>>>>>>>> Other opinions, ideas?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>> The sooner the better !
>>>>>>>
>>>>>>> Thanks for all your work, Jacques and Sascha
>>>>>>>
>>>>>>> --
>>>>>>> Erwan de FERRIERES
>>>>>>> www.nereide.biz

BJ Freeman

Re: jquey

In reply to this post by Adam Heath-2

I may be missing something, I don't see how to build a scenario of say
doing a orderentry, can be built the say you suggest.
in this scenario, it follows as if a user was inputting data and looking
for results at the UI level.

In simpliest, how would you redifine a element position?

=========================
BJ Freeman
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat Y! messenger: bjfr33man
Adam Heath sent the following on 12/2/2010 10:42 PM:

> BJ Freeman wrote:
>> Chuckle
>> that is what I thought, and I dread more workload to just keep up.
>> at this point I think you and I are the only ones that have invested in
>> Selenium
>
> The solution there is to stop maintaining it outside of the normal
> development pipeline. Get it into trunk, make running selenium tests
> automatic, with a simple call in build.xml.
>

BJ Freeman

Re:Calling selenium from the build XML was jquey

In reply to this post by Sascha Rodekamp-3

what what level were you working on?
I am working on scenarios for a user, like orderentry, adding products,
placing order through Ecommerce.

=========================
BJ Freeman
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat Y! messenger: bjfr33man

Sascha Rodekamp sent the following on 12/3/2010 12:11 AM:

> Good morning chaps
> Calling selenium from the build XML is a great point. I tried that a few month ago in another project once selenium is set up right it's really helpful
> So in my opinion we should def think of it.
> Cheers Sascha
>
> Am 03.12.2010 um 07:42 schrieb Adam Heath<[hidden email]>:
>
>> BJ Freeman wrote:
>>> Chuckle
>>> that is what I thought, and I dread more workload to just keep up.
>>> at this point I think you and I are the only ones that have invested in
>>> Selenium
>>
>> The solution there is to stop maintaining it outside of the normal
>> development pipeline. Get it into trunk, make running selenium tests
>> automatic, with a simple call in build.xml.
>

Karl Pitrich

Re: jquey

In reply to this post by Jacques Le Roux

Hi Jacques et al,

there are no real options, IMHO, jQuery is the way to go.

jQuery, like it or not, is now a somewhat established 'standard', allowing corporations to hire consultants and coders for. Additionally, the existing Dojo/Prototype/Scriptalicious codebase is a _mess_ and a lot of work to clean up. Sascha did very good work, also the backend seems much faster with jQuery.

I think that a good fact/opinion collection already has happened on the mailing list, so that a decision can be made. Please prevent whatever happened that prohibited not actually releasing 10.04 until today.

I suggest that, based on the input so far, the three top committers come to a unanimous conclusion and decide where to go and all follow in line. I understand that a lot of people have a stake in OfBiz, but for the sake of advancement of the project I strongly believe that a clear and quick decision is necessary, even when it breaks functionality.

The outcome will outweigh the momentary pain.

Greetings & have a nice weekend,

- Karl

On 03.12.2010, at 11:47, Jacques Le Roux wrote:

> IMO, there are 2 options for releasing branch(es).
>
> * Only one which will be later the official release. The problem is then whether people want to have Dojo/Prototype or jQuery in
> this new release branch.
>
> * Two branches, one which which will be later the official release and one which will not be officially released. I would consider
> it
> as a fork since it would have Dojo/Prototype when the official will have later jQuery. Maybe fork is not really appropriate, but I
> think you get my point.
>
> We could also make 2 official releases. One with Dojo/Prototype and another with jQuery. I'm not quite sure switching from
> Dojo/Prototype to jQuery requires a specific release...
>
> Other opinions, ideas?
>
> Thanks
>
> Jacques
>
> Bruno Busco wrote:
>> Why you think that making a new release branch would create a fork?
>> It will be managed as we manage R10.04 and R9.04 right now.
>> Only bug fixes will be backported.
>>
>> -Bruno
>>
>>
>> 2010/12/2 Jacques Le Roux <[hidden email]>
>>
>>> Ryan Foster wrote:
>>>
>>>> What about creating a tag or branch before the merge so that users who
>>>> have custom projects or applications based on the trunk
>>>> have a reference point in the event that they want to freeze their
>>>> applications at a particular revision?
>>>>
>>>
>>> Yes, that's what I have proposed. With another option: to have a branch.
>>> But I think the later is more a fork and I prefer the 1st.
>>>
>>>
>>> Oh and +1 on merging in JQuery. I am all for consolidating/simplifying
>>>> our Javascript libraries. No reason to have 3 libraries
>>>> that all essentially do the same thing. In the end, Javascript is
>>>> Javascript. My heart says we should have chosen Prototype as
>>>> that one (as anyone who knows me would agree, I'm a big Prototype JS
>>>> evangelist). But, my head says that JQuery is the right
>>>> choice for the long-term growth and success of the project, as it has
>>>> definitely become the drug of choice for a majority of
>>>> developers and has much more wide-spread community involvement as far as
>>>> development of plugins is concerned.
>>>>
>>>
>>> I think we now all agree on that
>>>
>>> Jacques
>>>
>>>
>>> Ryan L. Foster
>>>> 801.671.0769
>>>> [hidden email]
>>>>
>>>> On Dec 2, 2010, at 11:18 AM, Jacques Le Roux wrote:
>>>>
>>>> I'm sorry for Bruno, but it seems everybody is looking forward for this
>>>>> merging. So hopefully I will do it soon.
>>>>> If you are interested you can already check
>>>>> https://issues.apache.org/jira/browse/OFBIZ-3814
>>>>>
>>>>> Jacques
>>>>>
>>>>> Michael Xu (xudong) wrote:
>>>>>
>>>>>> +1
>>>>>>
>>>>>> Yeah, I would love such a great Xmas present :-)
>>>>>>
>>>>>>
>>>>>> You're welcome
>>>>>>> +1
>>>>>>>
>>>>>>> Would be a great Xmas present to merge all the stuff into the trunk :-)
>>>>>>>
>>>>>>> Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES <
>>>>>>> [hidden email]>:
>>>>>>>
>>>>>>> Le 02/12/2010 10:35, Jacques Le Roux a écrit :
>>>>>>>>
>>>>>>>>> Looks like, apart Bruno, we are all on the same page so far
>>>>>>>>>
>>>>>>>>> Other opinions, ideas?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>
>>>>>>>> The sooner the better !
>>>>>>>>
>>>>>>>> Thanks for all your work, Jacques and Sascha
>>>>>>>>
>>>>>>>> --
>>>>>>>> Erwan de FERRIERES
>>>>>>>> www.nereide.biz
>
>

_____________________________________________________

Lusini GmbH
Karl Pitrich, Chief Technology Officer
Adams-Lehmann-Straße 109, 80797 München

Telefon +49 89 416170 113
Telefax +49 89 416170 190
E-Mail [hidden email]

Sitz der Gesellschaft: München, HRB 188366
Amtsgericht München, Geschäftsführer: Markus Bohl
USt IdNr. DE 270565360, Steuernr. 152/131/90056
_____________________________________________________

smime.p7s (5K) Download Attachment

BJ Freeman

Re: jquey

ofbiz is to me is versatility with letting different implementation work
side by side.
the core is that the entities when modified will display at UI level
with no other changes to code. If you add a field at entity level that
field will display at the UI level with no more work.

So as long as any effort keeps that philosophy then I have no problem.
and as long as I can continued to work on my production servers without
major changes, then I am ok with it.

For those that want to change this, I suggest a different effort so they
can resolve their requirement but not effect the basic philosophy of
ofbiz design.

=========================
BJ Freeman
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat Y! messenger: bjfr33man

Karl Pitrich sent the following on 12/3/2010 7:49 AM:
> I understand that a lot of people have a stake in OfBiz, but for the sake of advancement of the project I strongly believe that a clear and quick decision is necessary, even when it breaks functionality.
>

Sascha Rodekamp-3

Re: jquey

Good evening,
BJ i'm on you're site. During the migration i tried to keep the old
behavior. So if you're using standard components from the UI you're
instances shouldn't be effected. And let me say that a few (UI) features,
after the migration, are more stable and faster than the old once (i.e. the
lookups).
Another side point to merge in the next days is, that i have this month free
time to fix bugs (which maybe occurs :-))

2010/12/3 BJ Freeman <[hidden email]>

> ofbiz is to me is versatility with letting different implementation work
> side by side.
> the core is that the entities when modified will display at UI level with
> no other changes to code. If you add a field at entity level that field will
> display at the UI level with no more work.
>
> So as long as any effort keeps that philosophy then I have no problem.
> and as long as I can continued to work on my production servers without
> major changes, then I am ok with it.
>
> For those that want to change this, I suggest a different effort so they
> can resolve their requirement but not effect the basic philosophy of ofbiz
> design.
>
>
>
> =========================
> BJ Freeman
> Strategic Power Office with Supplier Automation <
> http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com <http://www.specialtymarket.com/>
> Systems Integrator-- Glad to Assist
>
> Chat Y! messenger: bjfr33man
>
>
> Karl Pitrich sent the following on 12/3/2010 7:49 AM:
>
> I understand that a lot of people have a stake in OfBiz, but for the sake
>> of advancement of the project I strongly believe that a clear and quick
>> decision is necessary, even when it breaks functionality.
>>
>>
>

--
Sascha Rodekamp
Lynx-Consulting GmbH
Johanniskirchplatz 6
D-33615 Bielefeld
http://www.lynx.de

BJ Freeman

Re: jquey

so you have some selenium tests that work on the same pages between
trunk and jquery.

good to hear.

=========================
BJ Freeman
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat Y! messenger: bjfr33man
Sascha Rodekamp sent the following on 12/3/2010 11:32 AM:

> Good evening,
> BJ i'm on you're site. During the migration i tried to keep the old
> behavior. So if you're using standard components from the UI you're
> instances shouldn't be effected. And let me say that a few (UI) features,
> after the migration, are more stable and faster than the old once (i.e. the
> lookups).
> Another side point to merge in the next days is, that i have this month free
> time to fix bugs (which maybe occurs :-))
>
>
>
> 2010/12/3 BJ Freeman<[hidden email]>
>
>> ofbiz is to me is versatility with letting different implementation work
>> side by side.
>> the core is that the entities when modified will display at UI level with
>> no other changes to code. If you add a field at entity level that field will
>> display at the UI level with no more work.
>>
>> So as long as any effort keeps that philosophy then I have no problem.
>> and as long as I can continued to work on my production servers without
>> major changes, then I am ok with it.
>>
>> For those that want to change this, I suggest a different effort so they
>> can resolve their requirement but not effect the basic philosophy of ofbiz
>> design.
>>
>>
>>
>> =========================
>> BJ Freeman
>> Strategic Power Office with Supplier Automation<
>> http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>> Specialtymarket.com<http://www.specialtymarket.com/>
>> Systems Integrator-- Glad to Assist
>>
>> Chat Y! messenger: bjfr33man
>>
>>
>> Karl Pitrich sent the following on 12/3/2010 7:49 AM:
>>
>> I understand that a lot of people have a stake in OfBiz, but for the sake
>>> of advancement of the project I strongly believe that a clear and quick
>>> decision is necessary, even when it breaks functionality.
>>>
>>>
>>
>
>

rohit

Re: jquey

In reply to this post by Jacques Le Roux

hi Jacques,

Though i am not sure which is the best choice, but i strongly think that the jQuery branch should be merged with the trunk, without any further delay, primarily for these reasons:

1) that the code is reasonably complete,
2) most of the people in this thread have supported the merger of the code with the trunk, and most importantly
2) that the primary contributor of this work, ie. Sascha, has indicated that she has both the time and the willingness to address any issue/bugs that may arise after merging with the trunk.

I think its not too ofter that someone has both the willingness and also the time to devote to such important transition in code. Hence we should not risk wasting such valuable man-hours, which otherwise may be available.

Thanks

Rohit

saanjhi.com

Scott Gray-2

Re: jquey

In reply to this post by Bruno Busco

Hi Bruno,

I guess I missed your original email but what was the reason for creating a new release branch outside of our normal schedule?

Personally I don't see any reason why we can't just merge the jquery branch and carry on as normal. If people choose to develop custom projects against the trunk then good for them but I don't think we need to consider that when making decisions on moving the trunk forward.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 3/12/2010, at 6:59 PM, Bruno Busco wrote:

smime.p7s (3K) Download Attachment

Bruno Busco

Re: jquey

Hi All,
I am sorry if my suggestion to create a release branch has delayed somehow
the merging of the great work that Jacques and Sasha have done. This was not
my intention at all.

The idea was just to create a release branch; this, IMO, should not have
delayed the merging.
The reason of the branch was to offer a place where to live to people that
are now using the trunk if any issue with the jQuery should arise, until,
thanks to the massive test that will start only now that we will have it in
the trunk, will fix everythink.

Apart of that I do not see any other issue.
So please, go ahead with the merge, do not delay any further. We will handle
any issue as they come (if any).

Thank you,
Bruno

2010/12/5 Scott Gray <[hidden email]>

> Hi Bruno,
>
> I guess I missed your original email but what was the reason for creating a
> new release branch outside of our normal schedule?
>
> Personally I don't see any reason why we can't just merge the jquery branch
> and carry on as normal. If people choose to develop custom projects against
> the trunk then good for them but I don't think we need to consider that when
> making decisions on moving the trunk forward.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 3/12/2010, at 6:59 PM, Bruno Busco wrote:
>
> > Why you think that making a new release branch would create a fork?
> > It will be managed as we manage R10.04 and R9.04 right now.
> > Only bug fixes will be backported.
> >
> > -Bruno
> >
> >
> > 2010/12/2 Jacques Le Roux <[hidden email]>
> >
> >> Ryan Foster wrote:
> >>
> >>> What about creating a tag or branch before the merge so that users who
> >>> have custom projects or applications based on the trunk
> >>> have a reference point in the event that they want to freeze their
> >>> applications at a particular revision?
> >>>
> >>
> >> Yes, that's what I have proposed. With another option: to have a branch.
> >> But I think the later is more a fork and I prefer the 1st.
> >>
> >>
> >> Oh and +1 on merging in JQuery. I am all for consolidating/simplifying
> >>> our Javascript libraries. No reason to have 3 libraries
> >>> that all essentially do the same thing. In the end, Javascript is
> >>> Javascript. My heart says we should have chosen Prototype as
> >>> that one (as anyone who knows me would agree, I'm a big Prototype JS
> >>> evangelist). But, my head says that JQuery is the right
> >>> choice for the long-term growth and success of the project, as it has
> >>> definitely become the drug of choice for a majority of
> >>> developers and has much more wide-spread community involvement as far
> as
> >>> development of plugins is concerned.
> >>>
> >>
> >> I think we now all agree on that
> >>
> >> Jacques
> >>
> >>
> >> Ryan L. Foster
> >>> 801.671.0769
> >>> [hidden email]
> >>>
> >>> On Dec 2, 2010, at 11:18 AM, Jacques Le Roux wrote:
> >>>
> >>> I'm sorry for Bruno, but it seems everybody is looking forward for this
> >>>> merging. So hopefully I will do it soon.
> >>>> If you are interested you can already check
> >>>> https://issues.apache.org/jira/browse/OFBIZ-3814
> >>>>
> >>>> Jacques
> >>>>
> >>>> Michael Xu (xudong) wrote:
> >>>>
> >>>>> +1
> >>>>>
> >>>>> Yeah, I would love such a great Xmas present :-)
> >>>>>
> >>>>>
> >>>>> You're welcome
> >>>>>> +1
> >>>>>>
> >>>>>> Would be a great Xmas present to merge all the stuff into the trunk
> :-)
> >>>>>>
> >>>>>> Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES <
> >>>>>> [hidden email]>:
> >>>>>>
> >>>>>> Le 02/12/2010 10:35, Jacques Le Roux a écrit :
> >>>>>>>
> >>>>>>>> Looks like, apart Bruno, we are all on the same page so far
> >>>>>>>>
> >>>>>>>> Other opinions, ideas?
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>>
> >>>>>>>> Jacques
> >>>>>>>>
> >>>>>>>>
> >>>>>>> The sooner the better !
> >>>>>>>
> >>>>>>> Thanks for all your work, Jacques and Sascha
> >>>>>>>
> >>>>>>> --
> >>>>>>> Erwan de FERRIERES
> >>>>>>> www.nereide.biz
> >>>>>>>
> >>>>>>
> >>
> >>
>
>

Jacques Le Roux

Re: jquey

Administrator

Hi Bruno,

OK, then a tag should be sufficient. What about beforejQuery?

Jacques

From: "Bruno Busco" <[hidden email]>
Hi All,
I am sorry if my suggestion to create a release branch has delayed somehow
the merging of the great work that Jacques and Sasha have done. This was not
my intention at all.

The idea was just to create a release branch; this, IMO, should not have
delayed the merging.
The reason of the branch was to offer a place where to live to people that
are now using the trunk if any issue with the jQuery should arise, until,
thanks to the massive test that will start only now that we will have it in
the trunk, will fix everythink.

Apart of that I do not see any other issue.
So please, go ahead with the merge, do not delay any further. We will handle
any issue as they come (if any).

Thank you,
Bruno

2010/12/5 Scott Gray <[hidden email]>

Bruno Busco

Re: jquey

+1 ;-)

2010/12/5 Jacques Le Roux <[hidden email]>

> Hi Bruno,
>
> OK, then a tag should be sufficient. What about beforejQuery?
>
> Jacques
>
> From: "Bruno Busco" <[hidden email]>
>
> Hi All,
> I am sorry if my suggestion to create a release branch has delayed somehow
> the merging of the great work that Jacques and Sasha have done. This was
> not
> my intention at all.
>
> The idea was just to create a release branch; this, IMO, should not have
> delayed the merging.
> The reason of the branch was to offer a place where to live to people that
> are now using the trunk if any issue with the jQuery should arise, until,
> thanks to the massive test that will start only now that we will have it in
> the trunk, will fix everythink.
>
> Apart of that I do not see any other issue.
> So please, go ahead with the merge, do not delay any further. We will
> handle
> any issue as they come (if any).
>
> Thank you,
> Bruno
>
> 2010/12/5 Scott Gray <[hidden email]>
>
> Hi Bruno,
>>
>> I guess I missed your original email but what was the reason for creating
>> a
>> new release branch outside of our normal schedule?
>>
>> Personally I don't see any reason why we can't just merge the jquery
>> branch
>> and carry on as normal. If people choose to develop custom projects
>> against
>> the trunk then good for them but I don't think we need to consider that
>> when
>> making decisions on moving the trunk forward.
>>
>> Regards
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> On 3/12/2010, at 6:59 PM, Bruno Busco wrote:
>>
>> > Why you think that making a new release branch would create a fork?
>> > It will be managed as we manage R10.04 and R9.04 right now.
>> > Only bug fixes will be backported.
>> >
>> > -Bruno
>> >
>> >
>> > 2010/12/2 Jacques Le Roux <[hidden email]>
>> >
>> >> Ryan Foster wrote:
>> >>
>> >>> What about creating a tag or branch before the merge so that users who
>> >>> have custom projects or applications based on the trunk
>> >>> have a reference point in the event that they want to freeze their
>> >>> applications at a particular revision?
>> >>>
>> >>
>> >> Yes, that's what I have proposed. With another option: to have a
>> branch.
>> >> But I think the later is more a fork and I prefer the 1st.
>> >>
>> >>
>> >> Oh and +1 on merging in JQuery. I am all for consolidating/simplifying
>> >>> our Javascript libraries. No reason to have 3 libraries
>> >>> that all essentially do the same thing. In the end, Javascript is
>> >>> Javascript. My heart says we should have chosen Prototype as
>> >>> that one (as anyone who knows me would agree, I'm a big Prototype JS
>> >>> evangelist). But, my head says that JQuery is the right
>> >>> choice for the long-term growth and success of the project, as it has
>> >>> definitely become the drug of choice for a majority of
>> >>> developers and has much more wide-spread community involvement as far
>> as
>> >>> development of plugins is concerned.
>> >>>
>> >>
>> >> I think we now all agree on that
>> >>
>> >> Jacques
>> >>
>> >>
>> >> Ryan L. Foster
>> >>> 801.671.0769
>> >>> [hidden email]
>> >>>
>> >>> On Dec 2, 2010, at 11:18 AM, Jacques Le Roux wrote:
>> >>>
>> >>> I'm sorry for Bruno, but it seems everybody is looking forward for
>> this
>> >>>> merging. So hopefully I will do it soon.
>> >>>> If you are interested you can already check
>> >>>> https://issues.apache.org/jira/browse/OFBIZ-3814
>> >>>>
>> >>>> Jacques
>> >>>>
>> >>>> Michael Xu (xudong) wrote:
>> >>>>
>> >>>>> +1
>> >>>>>
>> >>>>> Yeah, I would love such a great Xmas present :-)
>> >>>>>
>> >>>>>
>> >>>>> You're welcome
>> >>>>>> +1
>> >>>>>>
>> >>>>>> Would be a great Xmas present to merge all the stuff into the trunk
>> :-)
>> >>>>>>
>> >>>>>> Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES <
>> >>>>>> [hidden email]>:
>> >>>>>>
>> >>>>>> Le 02/12/2010 10:35, Jacques Le Roux a écrit :
>> >>>>>>>
>> >>>>>>>> Looks like, apart Bruno, we are all on the same page so far
>> >>>>>>>>
>> >>>>>>>> Other opinions, ideas?
>> >>>>>>>>
>> >>>>>>>> Thanks
>> >>>>>>>>
>> >>>>>>>> Jacques
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> The sooner the better !
>> >>>>>>>
>> >>>>>>> Thanks for all your work, Jacques and Sascha
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Erwan de FERRIERES
>> >>>>>>> www.nereide.biz
>> >>>>>>>
>> >>>>>>
>> >>
>> >>
>>
>>
>>
>
>

Sascha Rodekamp-3

Re: Calling selenium from the build XML was jquey

In reply to this post by BJ Freeman

Hi BJ, sorry for the late response, but i was not at home yesterday.
:-).

That was more or less a POC. I tried to create a showcase to test standard
Application Screens (i.e. a standard ecommerce module). Therefore i created
the unit tests with the selenium firefox plugin, modifyed the tests for my
purposes and used them in a little selfmade testing framework. That was very
simple. It reads test data (i.e user data, orders which should be placed
...) from an excel file (Apache POI), creates a list with the neded data and
called the tests class with the unit tests, from this point selenium did all
the work, run the test and give me a result.
That's it. Maybe a little bit uncommon but as i said it was a POC for a
certain use case :-)

But at the end of the day a think there is a lot of stuff / test cases which
can be handled by selenium, but i also noticed that it is a lot of work
creating all the tests...

Hope you get an idea what i was trying to do.
Have a good day
Sascha

2010/12/3 BJ Freeman <[hidden email]>

> what what level were you working on?
> I am working on scenarios for a user, like orderentry, adding products,
> placing order through Ecommerce.
>
>
> =========================
> BJ Freeman
> Strategic Power Office with Supplier Automation <
> http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com <http://www.specialtymarket.com/>
> Systems Integrator-- Glad to Assist
>
> Chat Y! messenger: bjfr33man
>
>
> Sascha Rodekamp sent the following on 12/3/2010 12:11 AM:
>
>> Good morning chaps
>> Calling selenium from the build XML is a great point. I tried that a few
>> month ago in another project once selenium is set up right it's really
>> helpful
>> So in my opinion we should def think of it.
>> Cheers Sascha
>>
>> Am 03.12.2010 um 07:42 schrieb Adam Heath<[hidden email]>:
>>
>> BJ Freeman wrote:
>>>
>>>> Chuckle
>>>> that is what I thought, and I dread more workload to just keep up.
>>>> at this point I think you and I are the only ones that have invested in
>>>> Selenium
>>>>
>>>
>>> The solution there is to stop maintaining it outside of the normal
>>> development pipeline. Get it into trunk, make running selenium tests
>>> automatic, with a simple call in build.xml.
>>>
>>
>>
>

--
Sascha Rodekamp
Lynx-Consulting GmbH
Johanniskirchplatz 6
D-33615 Bielefeld
http://www.lynx.de

Erwan de FERRIERES

Re: Calling selenium from the build XML was jquey

Le 05/12/2010 13:02, Sascha Rodekamp a écrit :

Hi Sascha,

would it be possible to put all of this in a JIRA issue ? I may need
some of this, and I may also need it to clarify what I want from
Selenium in OFBiz (and work on it later...).

Cheers,

--
Erwan de FERRIERES
www.nereide.biz

Erwan de FERRIERES

Re: Calling selenium from the build XML was jquey

In reply to this post by Sascha Rodekamp-3

Le 05/12/2010 13:02, Sascha Rodekamp a écrit :

BJ Freeman

Re: Calling selenium from the build XML was jquey

In reply to this post by Sascha Rodekamp-3

I am headed the same way with tests that span components. The Tests are
like a user would do, like adding prodcts, entering an order, and making
changes to data. Also Selenium gives you page layout changes Errors.

though the individual pages are stored on each component, the test are
in the framework that span components.

The problem that Adam addressed was how to build these tests from the
build.xml, not run them.
That to me, is attainable, in the future but requires a lot more coding
work.

the one gotcha I see in self generated tests is you don't get legacy
type of errors for what has been changed, like when an entity has a new
field or one is removed or changed. This is crucial to production
servers and supporting a client.

As I originally said, if a layout(page) is effected by the addition of
Jquey, that will negate tests for those layouts. It would be even harder
to programmatic generate tests using selenium.

=========================
BJ Freeman
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat Y! messenger: bjfr33man

Sascha Rodekamp sent the following on 12/5/2010 4:02 AM:

> Hi BJ, sorry for the late response, but i was not at home yesterday.
> :-).
>
> That was more or less a POC. I tried to create a showcase to test standard
> Application Screens (i.e. a standard ecommerce module). Therefore i created
> the unit tests with the selenium firefox plugin, modifyed the tests for my
> purposes and used them in a little selfmade testing framework. That was very
> simple. It reads test data (i.e user data, orders which should be placed
> ...) from an excel file (Apache POI), creates a list with the neded data and
> called the tests class with the unit tests, from this point selenium did all
> the work, run the test and give me a result.
> That's it. Maybe a little bit uncommon but as i said it was a POC for a
> certain use case :-)
>
> But at the end of the day a think there is a lot of stuff / test cases which
> can be handled by selenium, but i also noticed that it is a lot of work
> creating all the tests...
>
> Hope you get an idea what i was trying to do.
> Have a good day
> Sascha
>
>
> 2010/12/3 BJ Freeman<[hidden email]>
>
>> what what level were you working on?
>> I am working on scenarios for a user, like orderentry, adding products,
>> placing order through Ecommerce.
>>
>>
>> =========================
>> BJ Freeman
>> Strategic Power Office with Supplier Automation<
>> http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>> Specialtymarket.com<http://www.specialtymarket.com/>
>> Systems Integrator-- Glad to Assist
>>
>> Chat Y! messenger: bjfr33man
>>
>>
>> Sascha Rodekamp sent the following on 12/3/2010 12:11 AM:
>>
>>> Good morning chaps
>>> Calling selenium from the build XML is a great point. I tried that a few
>>> month ago in another project once selenium is set up right it's really
>>> helpful
>>> So in my opinion we should def think of it.
>>> Cheers Sascha
>>>
>>> Am 03.12.2010 um 07:42 schrieb Adam Heath<[hidden email]>:
>>>
>>> BJ Freeman wrote:
>>>>
>>>>> Chuckle
>>>>> that is what I thought, and I dread more workload to just keep up.
>>>>> at this point I think you and I are the only ones that have invested in
>>>>> Selenium
>>>>>
>>>>
>>>> The solution there is to stop maintaining it outside of the normal
>>>> development pipeline. Get it into trunk, make running selenium tests
>>>> automatic, with a simple call in build.xml.
>>>>
>>>
>>>
>>
>
>

Adam Heath-2

Re: Calling selenium from the build XML was jquey

On 12/06/2010 12:30 PM, BJ Freeman wrote:
> The problem that Adam addressed was how to build these tests from the
> build.xml, not run them.
> That to me, is attainable, in the future but requires a lot more coding
> work.

That wasn't what I said. I want to be able to run a selenium test
from build.xml. I don't care how the test was created. But if the
test has been added to trunk, I want a very simple command to run,
that then tells me if it passes or not.

If it requires setting up an external process, then the 'simple' tag
doesn't apply. If it isn't simple, then it won't be run, and then
errors would creep in.

BJ Freeman

Re: Calling selenium from the build XML was jquey

thanks for the the clarification.
No problem running tests from build.
the problem is the errors at this time, can not be reported in the logs,
only visually
to log errors will take some work in selenium.

=========================
BJ Freeman
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat Y! messenger: bjfr33man

Adam Heath sent the following on 12/6/2010 11:48 AM:

> On 12/06/2010 12:30 PM, BJ Freeman wrote:
>> The problem that Adam addressed was how to build these tests from the
>> build.xml, not run them.
>> That to me, is attainable, in the future but requires a lot more coding
>> work.
>
> That wasn't what I said. I want to be able to run a selenium test from
> build.xml. I don't care how the test was created. But if the test has
> been added to trunk, I want a very simple command to run, that then
> tells me if it passes or not.
>
> If it requires setting up an external process, then the 'simple' tag
> doesn't apply. If it isn't simple, then it won't be run, and then errors
> would creep in.
>

Brett

Re: Calling selenium from the build XML was jquey

Sorry, I'm a little late on this thread. Is the logging problem related to
SeleniumXml or another Selenium sub-probject?

I believe the problem with SeleniumXml is that it run outside of the ofbiz
container and doesn't have access to the log4j settings, etc that are
available in the ofbiz container. A patch could be added to configure
Seleniumxml to use the same log4j settings setup in the framework. Then the
errors could be found in the same logs files as the other tests.

is this what developers are asking for?

Brett

On Mon, Dec 6, 2010 at 3:15 PM, BJ Freeman <[hidden email]> wrote:

> thanks for the the clarification.
> No problem running tests from build.
> the problem is the errors at this time, can not be reported in the logs,
> only visually
> to log errors will take some work in selenium.
>
>
> =========================
> BJ Freeman
> Strategic Power Office with Supplier Automation <
> http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com <http://www.specialtymarket.com/>
> Systems Integrator-- Glad to Assist
>
> Chat Y! messenger: bjfr33man
>
>
> Adam Heath sent the following on 12/6/2010 11:48 AM:
>
> On 12/06/2010 12:30 PM, BJ Freeman wrote:
>>
>>> The problem that Adam addressed was how to build these tests from the
>>> build.xml, not run them.
>>> That to me, is attainable, in the future but requires a lot more coding
>>> work.
>>>
>>
>> That wasn't what I said. I want to be able to run a selenium test from
>> build.xml. I don't care how the test was created. But if the test has
>> been added to trunk, I want a very simple command to run, that then
>> tells me if it passes or not.
>>
>> If it requires setting up an external process, then the 'simple' tag
>> doesn't apply. If it isn't simple, then it won't be run, and then errors
>> would creep in.
>>
>>
>

BJ Freeman

Re: Calling selenium from the build XML was jquey

http://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML#N231EE
OFBiz SeleniumXml
You will get an assertion (or other exception) if the test fails.
this is to run from build.xml
like
ant selelium_orders (not yes in build)_
do you will get a build sucessful if test compelets.

=========================
BJ Freeman
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat Y! messenger: bjfr33man

Brett Palmer sent the following on 12/6/2010 4:30 PM:

> Sorry, I'm a little late on this thread. Is the logging problem related to
> SeleniumXml or another Selenium sub-probject?
>
> I believe the problem with SeleniumXml is that it run outside of the ofbiz
> container and doesn't have access to the log4j settings, etc that are
> available in the ofbiz container. A patch could be added to configure
> Seleniumxml to use the same log4j settings setup in the framework. Then the
> errors could be found in the same logs files as the other tests.
>
> is this what developers are asking for?
>
>
> Brett
>
> On Mon, Dec 6, 2010 at 3:15 PM, BJ Freeman<[hidden email]> wrote:
>
>> thanks for the the clarification.
>> No problem running tests from build.
>> the problem is the errors at this time, can not be reported in the logs,
>> only visually
>> to log errors will take some work in selenium.
>>
>>
>> =========================
>> BJ Freeman
>> Strategic Power Office with Supplier Automation<
>> http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>> Specialtymarket.com<http://www.specialtymarket.com/>
>> Systems Integrator-- Glad to Assist
>>
>> Chat Y! messenger: bjfr33man
>>
>>
>> Adam Heath sent the following on 12/6/2010 11:48 AM:
>>
>> On 12/06/2010 12:30 PM, BJ Freeman wrote:
>>>
>>>> The problem that Adam addressed was how to build these tests from the
>>>> build.xml, not run them.
>>>> That to me, is attainable, in the future but requires a lot more coding
>>>> work.
>>>>
>>>
>>> That wasn't what I said. I want to be able to run a selenium test from
>>> build.xml. I don't care how the test was created. But if the test has
>>> been added to trunk, I want a very simple command to run, that then
>>> tells me if it passes or not.
>>>
>>> If it requires setting up an external process, then the 'simple' tag
>>> doesn't apply. If it isn't simple, then it won't be run, and then errors
>>> would creep in.
>>>
>>>
>>
>

123