You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Peter Courcoux <pe...@courcoux.biz> on 2005/08/25 20:57:05 UTC
Re: Current State of Migrating Turbine Services To Fulcrum ....
Siegfried,
I've put an issue in jira regarding the fortress service and assigned it
to me. I have a service working locally now and am just trying to build
fulcrum with the fortress meta tags so I can use them within fortress
for testing. I've also updated the maven-fortress-plugin so that it
works for me with my build system.
I'm away from tomorrow until Monday evening and will not be making any
further progress until then.
While I've been playing with fortress I have got no further switching
services. One question for you, are you aware of any reason that might
prevent us switching to the latest Avalon/excalibur dependencies for all
the fulcrum components. They are at RC3 now and a vote has been called
to release without change?
In answer to your question :
The follwoing services are still listed in the
TurbineResources.properties file from cvs head
IIRC the intention was to convert all of the services listed below to
fulcrum services and then use them in turbine 2.4. We will need to keep
the old service framework in place with no changes to functionality
while switching to the new services so that the old stuff can be
deprecated and only removed from cvs head after release of 2.4.
services.FactoryService.classname=org.apache.turbine.services.factory.TurbineFactoryService
services.PoolService.classname=org.apache.turbine.services.pool.TurbinePoolService
services.RunDataService.classname=org.apache.turbine.services.rundata.TurbineRunDataService
services.ServletService.classname=org.apache.turbine.services.servlet.TurbineServletService
services.AssemblerBrokerService.classname=org.apache.turbine.services.assemblerbroker.TurbineAssemblerBrokerService
services.SchedulerService.classname=org.apache.turbine.services.schedule.TurbineSchedulerService
services.XmlRpcService.classname=org.apache.turbine.services.xmlrpc.TurbineXmlRpcService
services.UniqueIdService.classname=org.apache.turbine.services.uniqueid.TurbineUniqueIdService
services.UploadService.classname=org.apache.turbine.services.upload.TurbineUploadService
services.SecurityService.classname=org.apache.turbine.services.security.db.DBSecurityService
services.PullService.classname=org.apache.turbine.services.pull.TurbinePullService
services.TemplateService.classname=org.apache.turbine.services.template.TurbineTemplateService
services.XSLTService.classname=org.apache.turbine.services.xslt.TurbineXSLTService
services.VelocityService.classname=org.apache.turbine.services.velocity.TurbineVelocityService
Could I suggest that we use jira to keep track of what is being done. It
looks like we could both be working on the fulcrum tree at the same
time. (unless you finish all the conversion over the next four days,
that is ;-) )
Regards,
Peter
Siegfried Goeschl wrote:
> Hi folks,
>
> are there any plans which existing Turbine services need to be migrated
> for the next Turbine milestone release? Currently the following
> Avalon-based services are currently used within Turbine CVS HEAD
>
> * org.apache.torque.avalon.Torque
> * org.apache.fulcrum.cache.GlobalCacheService
> * org.apache.fulcrum.mimetype.MimeTypeService
> * org.apache.fulcrum.crypto.CryptoService
> * org.apache.fulcrum.localization.LocalizationService
> * org.apache.fulcrum.intake.IntakeService
> * org.apache.fulcrum.factory.FactoryService
>
> This is rather a proof of concept than anything else ... :-( .... as
> good condidates (where I can help) are XML-RPC and XSLT service
>
> Cheers,
>
> Siegfried Goeschl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
--
------------------------------
Peter Courcoux
Telephone : +44 (0)1923 661488
Mobile : 07880 605626
email : peter@courcoux.biz
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Current State of Migrating Turbine Services To Fulcrum ....
Posted by Thomas Vandahl <th...@tewisoft.de>.
Peter Courcoux wrote:
> services.SecurityService.classname=org.apache.turbine.services.security.db.DBSecurityService
Could someone with insight please comment on this one? There is a lot of
stuff on the Fulcrum Security site. From what I see, it it not
compatible with the existing security services to a large extent, though
I could be wrong. At least the support of Torque and LDAP is missing.
I had a look into the Hibernate implementation and from that I guess it
is not only a simple port or is it?
I would like to offer my (rather limited, I admit) resources to help, If
someone could give me a few initial hints.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Current State of Migrating Turbine Services To Fulcrum ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Peter,
I woulod prefer 3) since I have plenty to do anyway ...
Cheers,
Siegfried Goeschl
Peter Courcoux wrote:
> Hi Siegfried,
>
> I've had a deadline brought forward and sadly have to push forward
> using ECM until I can get some breathing space to continue with the
> switch to fortress.
>
> I have a working service, with a dummy service in one of my
> applications, but no tests yet and no fulcrum services fully converted.
>
> As there is going to be a delay, I could either :-
>
> 1. commit what is there into turbine tree, including configuration
> files with the fortress entries commented out.
>
> 2. Send same to you off-list for you to play with.
>
> 3. Leave things as they are until I have time to finish it.
>
> Let me know which is preferable.
>
> Regards,
>
> Peter
>
> Siegfried Goeschl wrote:
>
>> Hi Peter,
>>
>> before you happily return to the computer after the long weekend ...
>>
>> +) I fixed a SVN related problem with the
>> fulcrum-resourcemanager-service
>> +) I updated the dependencies of the fulcrum-groovy-service in SVN as
>> well
>> +) the Fulcrum build works with the avalon-framework-api/impl-4.3-dev
>> but I did not commit this change
>> +) within the next few days I commit a YAAFI version providing
>> service interceptors whereas the interceptors are plain Avalon services
>> +) I can also help with migrating to Fortress if you provide a
>> Fortress adapter (well, at least at night)
>>
>> Cheers,
>>
>> Siegfried Goeschl
>>
>>
>> Peter Courcoux wrote:
>>
>>> Hi Siegfried,
>>>
>>> Comments below:-
>>>
>>> Siegfried Goeschl wrote:
>>>
>>>> Hi Peter,
>>>>
>>>> see my comments below ...
>>>>
>>>> Siegfried Goeschl
>>>>
>>>> Peter Courcoux wrote:
>>>>
>>>>> Siegfried,
>>>>>
>>>>> I've put an issue in jira regarding the fortress service and
>>>>> assigned it to me. I have a service working locally now and am
>>>>> just trying to build fulcrum with the fortress meta tags so I can
>>>>> use them within fortress for testing. I've also updated the
>>>>> maven-fortress-plugin so that it works for me with my build system.
>>>>>
>>>> Correct me if I'm wrong - is the usage of maven-fortress-plugin
>>>> mandatory? I have problems with Maven builds requiring custom
>>>> plugins since the tend to be broken when being used on multiple
>>>> Maven versions and platforms.
>>>>
>>>
>>> There is an Ant task which does what is needed and which is simply
>>> called by the maven plugin. I'm not a maven expert. Maybe Eric could
>>> help on this.
>>>
>>>>> I'm away from tomorrow until Monday evening and will not be making
>>>>> any further progress until then.
>>>>>
>>>>> While I've been playing with fortress I have got no further
>>>>> switching services. One question for you, are you aware of any
>>>>> reason that might prevent us switching to the latest
>>>>> Avalon/excalibur dependencies for all the fulcrum components. They
>>>>> are at RC3 now and a vote has been called to release without change?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I give the new avalon-framework a try until Monday evening and
>>>> commit the changes by then. When using Fortress container instead
>>>> of YAAFI there is a liittle problem - each Avalon container comes
>>>> with a different set of variables for the Avalon context. The
>>>> Fulcrum services currently follow the Merlin conventionn but this
>>>> is easy to change. And YAAFI supports Fortress context naming
>>>> anyway using the <component-flavour> tag.
>>>>
>>> That helps.
>>>
>>>> Do you have an Turbine AvalonComponentService for Fortress up and
>>>> running with the latest Fortress release?
>>>>
>>>
>>> Yes I'm using RC3 builds.
>>>
>>>>>
>>>>> In answer to your question :
>>>>>
>>>>> The follwoing services are still listed in the
>>>>> TurbineResources.properties file from cvs head
>>>>>
>>>>> IIRC the intention was to convert all of the services listed below
>>>>> to fulcrum services and then use them in turbine 2.4. We will need
>>>>> to keep the old service framework in place with no changes to
>>>>> functionality while switching to the new services so that the old
>>>>> stuff can be deprecated and only removed from cvs head after
>>>>> release of 2.4.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I can leand a hand for services I know of since I never used
>>>> Turbine for a web-application .... :-)
>>>>
>>>> +)
>>>> services.XmlRpcService.classname=org.apache.turbine.services.xmlrpc.TurbineXmlRpcService
>>>>
>>>> +)
>>>> services.XSLTService.classname=org.apache.turbine.services.xslt.TurbineXSLTService
>>>>
>>>> +)
>>>> services.UniqueIdService.classname=org.apache.turbine.services.uniqueid.TurbineUniqueIdService
>>>>
>>>>
>>> Great.
>>>
>>> Any volunteers for any of the others?
>>>
>>>>>
>>>>> services.FactoryService.classname=org.apache.turbine.services.factory.TurbineFactoryService
>>>>>
>>>>> services.PoolService.classname=org.apache.turbine.services.pool.TurbinePoolService
>>>>>
>>>>> services.RunDataService.classname=org.apache.turbine.services.rundata.TurbineRunDataService
>>>>>
>>>>> services.ServletService.classname=org.apache.turbine.services.servlet.TurbineServletService
>>>>>
>>>>> services.AssemblerBrokerService.classname=org.apache.turbine.services.assemblerbroker.TurbineAssemblerBrokerService
>>>>>
>>>>> services.SchedulerService.classname=org.apache.turbine.services.schedule.TurbineSchedulerService
>>>>>
>>>>> services.XmlRpcService.classname=org.apache.turbine.services.xmlrpc.TurbineXmlRpcService
>>>>>
>>>>> services.UniqueIdService.classname=org.apache.turbine.services.uniqueid.TurbineUniqueIdService
>>>>>
>>>>> services.UploadService.classname=org.apache.turbine.services.upload.TurbineUploadService
>>>>>
>>>>> services.SecurityService.classname=org.apache.turbine.services.security.db.DBSecurityService
>>>>>
>>>>> services.PullService.classname=org.apache.turbine.services.pull.TurbinePullService
>>>>>
>>>>> services.TemplateService.classname=org.apache.turbine.services.template.TurbineTemplateService
>>>>>
>>>>> services.XSLTService.classname=org.apache.turbine.services.xslt.TurbineXSLTService
>>>>>
>>>>> services.VelocityService.classname=org.apache.turbine.services.velocity.TurbineVelocityService
>>>>>
>>>>>
>>>>> Could I suggest that we use jira to keep track of what is being
>>>>> done. It looks like we could both be working on the fulcrum tree
>>>>> at the same time. (unless you finish all the conversion over the
>>>>> next four days, that is ;-) )
>>>>>
>>>> Agreed
>>>
>>>
>>>
>>>
>>> I'll catch up with you next week. I'm off for a long weekend now.
>>>
>>> Regards,
>>>
>>> Peter
>>>
>>>>
>>>>> Regards,
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>>> Siegfried Goeschl wrote:
>>>>>
>>>>>> Hi folks,
>>>>>>
>>>>>> are there any plans which existing Turbine services need to be
>>>>>> migrated for the next Turbine milestone release? Currently the
>>>>>> following Avalon-based services are currently used within Turbine
>>>>>> CVS HEAD
>>>>>>
>>>>>> * org.apache.torque.avalon.Torque
>>>>>> * org.apache.fulcrum.cache.GlobalCacheService
>>>>>> * org.apache.fulcrum.mimetype.MimeTypeService
>>>>>> * org.apache.fulcrum.crypto.CryptoService
>>>>>> * org.apache.fulcrum.localization.LocalizationService
>>>>>> * org.apache.fulcrum.intake.IntakeService
>>>>>> * org.apache.fulcrum.factory.FactoryService
>>>>>>
>>>>>> This is rather a proof of concept than anything else ... :-( ....
>>>>>> as good condidates (where I can help) are XML-RPC and XSLT service
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Siegfried Goeschl
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>>>>>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Current State of Migrating Turbine Services To Fulcrum ....
Posted by Peter Courcoux <pe...@courcoux.biz>.
Hi Siegfried,
I've had a deadline brought forward and sadly have to push forward using
ECM until I can get some breathing space to continue with the switch
to fortress.
I have a working service, with a dummy service in one of my
applications, but no tests yet and no fulcrum services fully converted.
As there is going to be a delay, I could either :-
1. commit what is there into turbine tree, including configuration files
with the fortress entries commented out.
2. Send same to you off-list for you to play with.
3. Leave things as they are until I have time to finish it.
Let me know which is preferable.
Regards,
Peter
Siegfried Goeschl wrote:
> Hi Peter,
>
> before you happily return to the computer after the long weekend ...
>
> +) I fixed a SVN related problem with the fulcrum-resourcemanager-service
> +) I updated the dependencies of the fulcrum-groovy-service in SVN as well
> +) the Fulcrum build works with the avalon-framework-api/impl-4.3-dev
> but I did not commit this change
> +) within the next few days I commit a YAAFI version providing service
> interceptors whereas the interceptors are plain Avalon services
> +) I can also help with migrating to Fortress if you provide a Fortress
> adapter (well, at least at night)
>
> Cheers,
>
> Siegfried Goeschl
>
>
> Peter Courcoux wrote:
>
>> Hi Siegfried,
>>
>> Comments below:-
>>
>> Siegfried Goeschl wrote:
>>
>>> Hi Peter,
>>>
>>> see my comments below ...
>>>
>>> Siegfried Goeschl
>>>
>>> Peter Courcoux wrote:
>>>
>>>> Siegfried,
>>>>
>>>> I've put an issue in jira regarding the fortress service and
>>>> assigned it to me. I have a service working locally now and am just
>>>> trying to build fulcrum with the fortress meta tags so I can use
>>>> them within fortress for testing. I've also updated the
>>>> maven-fortress-plugin so that it works for me with my build system.
>>>>
>>> Correct me if I'm wrong - is the usage of maven-fortress-plugin
>>> mandatory? I have problems with Maven builds requiring custom
>>> plugins since the tend to be broken when being used on multiple Maven
>>> versions and platforms.
>>>
>>
>> There is an Ant task which does what is needed and which is simply
>> called by the maven plugin. I'm not a maven expert. Maybe Eric could
>> help on this.
>>
>>>> I'm away from tomorrow until Monday evening and will not be making
>>>> any further progress until then.
>>>>
>>>> While I've been playing with fortress I have got no further
>>>> switching services. One question for you, are you aware of any
>>>> reason that might prevent us switching to the latest
>>>> Avalon/excalibur dependencies for all the fulcrum components. They
>>>> are at RC3 now and a vote has been called to release without change?
>>>
>>>
>>>
>>>
>>> I give the new avalon-framework a try until Monday evening and commit
>>> the changes by then. When using Fortress container instead of YAAFI
>>> there is a liittle problem - each Avalon container comes with a
>>> different set of variables for the Avalon context. The Fulcrum
>>> services currently follow the Merlin conventionn but this is easy to
>>> change. And YAAFI supports Fortress context naming anyway using the
>>> <component-flavour> tag.
>>>
>> That helps.
>>
>>> Do you have an Turbine AvalonComponentService for Fortress up and
>>> running with the latest Fortress release?
>>>
>>
>> Yes I'm using RC3 builds.
>>
>>>>
>>>> In answer to your question :
>>>>
>>>> The follwoing services are still listed in the
>>>> TurbineResources.properties file from cvs head
>>>>
>>>> IIRC the intention was to convert all of the services listed below
>>>> to fulcrum services and then use them in turbine 2.4. We will need
>>>> to keep the old service framework in place with no changes to
>>>> functionality while switching to the new services so that the old
>>>> stuff can be deprecated and only removed from cvs head after release
>>>> of 2.4.
>>>
>>>
>>>
>>>
>>> I can leand a hand for services I know of since I never used Turbine
>>> for a web-application .... :-)
>>>
>>> +)
>>> services.XmlRpcService.classname=org.apache.turbine.services.xmlrpc.TurbineXmlRpcService
>>>
>>> +)
>>> services.XSLTService.classname=org.apache.turbine.services.xslt.TurbineXSLTService
>>>
>>> +)
>>> services.UniqueIdService.classname=org.apache.turbine.services.uniqueid.TurbineUniqueIdService
>>>
>>>
>> Great.
>>
>> Any volunteers for any of the others?
>>
>>>>
>>>> services.FactoryService.classname=org.apache.turbine.services.factory.TurbineFactoryService
>>>>
>>>> services.PoolService.classname=org.apache.turbine.services.pool.TurbinePoolService
>>>>
>>>> services.RunDataService.classname=org.apache.turbine.services.rundata.TurbineRunDataService
>>>>
>>>> services.ServletService.classname=org.apache.turbine.services.servlet.TurbineServletService
>>>>
>>>> services.AssemblerBrokerService.classname=org.apache.turbine.services.assemblerbroker.TurbineAssemblerBrokerService
>>>>
>>>> services.SchedulerService.classname=org.apache.turbine.services.schedule.TurbineSchedulerService
>>>>
>>>> services.XmlRpcService.classname=org.apache.turbine.services.xmlrpc.TurbineXmlRpcService
>>>>
>>>> services.UniqueIdService.classname=org.apache.turbine.services.uniqueid.TurbineUniqueIdService
>>>>
>>>> services.UploadService.classname=org.apache.turbine.services.upload.TurbineUploadService
>>>>
>>>> services.SecurityService.classname=org.apache.turbine.services.security.db.DBSecurityService
>>>>
>>>> services.PullService.classname=org.apache.turbine.services.pull.TurbinePullService
>>>>
>>>> services.TemplateService.classname=org.apache.turbine.services.template.TurbineTemplateService
>>>>
>>>> services.XSLTService.classname=org.apache.turbine.services.xslt.TurbineXSLTService
>>>>
>>>> services.VelocityService.classname=org.apache.turbine.services.velocity.TurbineVelocityService
>>>>
>>>>
>>>> Could I suggest that we use jira to keep track of what is being
>>>> done. It looks like we could both be working on the fulcrum tree at
>>>> the same time. (unless you finish all the conversion over the next
>>>> four days, that is ;-) )
>>>>
>>> Agreed
>>
>>
>>
>> I'll catch up with you next week. I'm off for a long weekend now.
>>
>> Regards,
>>
>> Peter
>>
>>>
>>>> Regards,
>>>>
>>>> Peter
>>>>
>>>>
>>>> Siegfried Goeschl wrote:
>>>>
>>>>> Hi folks,
>>>>>
>>>>> are there any plans which existing Turbine services need to be
>>>>> migrated for the next Turbine milestone release? Currently the
>>>>> following Avalon-based services are currently used within Turbine
>>>>> CVS HEAD
>>>>>
>>>>> * org.apache.torque.avalon.Torque
>>>>> * org.apache.fulcrum.cache.GlobalCacheService
>>>>> * org.apache.fulcrum.mimetype.MimeTypeService
>>>>> * org.apache.fulcrum.crypto.CryptoService
>>>>> * org.apache.fulcrum.localization.LocalizationService
>>>>> * org.apache.fulcrum.intake.IntakeService
>>>>> * org.apache.fulcrum.factory.FactoryService
>>>>>
>>>>> This is rather a proof of concept than anything else ... :-( ....
>>>>> as good condidates (where I can help) are XML-RPC and XSLT service
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Siegfried Goeschl
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
--
------------------------------
Peter Courcoux
Telephone : +44 (0)1923 661488
Mobile : 07880 605626
email : peter@courcoux.biz
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Current State of Migrating Turbine Services To Fulcrum ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Peter,
before you happily return to the computer after the long weekend ...
+) I fixed a SVN related problem with the fulcrum-resourcemanager-service
+) I updated the dependencies of the fulcrum-groovy-service in SVN as well
+) the Fulcrum build works with the avalon-framework-api/impl-4.3-dev
but I did not commit this change
+) within the next few days I commit a YAAFI version providing service
interceptors whereas the interceptors are plain Avalon services
+) I can also help with migrating to Fortress if you provide a Fortress
adapter (well, at least at night)
Cheers,
Siegfried Goeschl
Peter Courcoux wrote:
> Hi Siegfried,
>
> Comments below:-
>
> Siegfried Goeschl wrote:
>
>> Hi Peter,
>>
>> see my comments below ...
>>
>> Siegfried Goeschl
>>
>> Peter Courcoux wrote:
>>
>>> Siegfried,
>>>
>>> I've put an issue in jira regarding the fortress service and
>>> assigned it to me. I have a service working locally now and am just
>>> trying to build fulcrum with the fortress meta tags so I can use
>>> them within fortress for testing. I've also updated the
>>> maven-fortress-plugin so that it works for me with my build system.
>>>
>> Correct me if I'm wrong - is the usage of maven-fortress-plugin
>> mandatory? I have problems with Maven builds requiring custom
>> plugins since the tend to be broken when being used on multiple Maven
>> versions and platforms.
>>
>
> There is an Ant task which does what is needed and which is simply
> called by the maven plugin. I'm not a maven expert. Maybe Eric could
> help on this.
>
>>> I'm away from tomorrow until Monday evening and will not be making
>>> any further progress until then.
>>>
>>> While I've been playing with fortress I have got no further
>>> switching services. One question for you, are you aware of any
>>> reason that might prevent us switching to the latest
>>> Avalon/excalibur dependencies for all the fulcrum components. They
>>> are at RC3 now and a vote has been called to release without change?
>>
>>
>>
>> I give the new avalon-framework a try until Monday evening and commit
>> the changes by then. When using Fortress container instead of YAAFI
>> there is a liittle problem - each Avalon container comes with a
>> different set of variables for the Avalon context. The Fulcrum
>> services currently follow the Merlin conventionn but this is easy to
>> change. And YAAFI supports Fortress context naming anyway using the
>> <component-flavour> tag.
>>
> That helps.
>
>> Do you have an Turbine AvalonComponentService for Fortress up and
>> running with the latest Fortress release?
>>
>
> Yes I'm using RC3 builds.
>
>>>
>>> In answer to your question :
>>>
>>> The follwoing services are still listed in the
>>> TurbineResources.properties file from cvs head
>>>
>>> IIRC the intention was to convert all of the services listed below
>>> to fulcrum services and then use them in turbine 2.4. We will need
>>> to keep the old service framework in place with no changes to
>>> functionality while switching to the new services so that the old
>>> stuff can be deprecated and only removed from cvs head after release
>>> of 2.4.
>>
>>
>>
>> I can leand a hand for services I know of since I never used Turbine
>> for a web-application .... :-)
>>
>> +)
>> services.XmlRpcService.classname=org.apache.turbine.services.xmlrpc.TurbineXmlRpcService
>>
>> +)
>> services.XSLTService.classname=org.apache.turbine.services.xslt.TurbineXSLTService
>>
>> +)
>> services.UniqueIdService.classname=org.apache.turbine.services.uniqueid.TurbineUniqueIdService
>>
>>
> Great.
>
> Any volunteers for any of the others?
>
>>>
>>> services.FactoryService.classname=org.apache.turbine.services.factory.TurbineFactoryService
>>>
>>> services.PoolService.classname=org.apache.turbine.services.pool.TurbinePoolService
>>>
>>> services.RunDataService.classname=org.apache.turbine.services.rundata.TurbineRunDataService
>>>
>>> services.ServletService.classname=org.apache.turbine.services.servlet.TurbineServletService
>>>
>>> services.AssemblerBrokerService.classname=org.apache.turbine.services.assemblerbroker.TurbineAssemblerBrokerService
>>>
>>> services.SchedulerService.classname=org.apache.turbine.services.schedule.TurbineSchedulerService
>>>
>>> services.XmlRpcService.classname=org.apache.turbine.services.xmlrpc.TurbineXmlRpcService
>>>
>>> services.UniqueIdService.classname=org.apache.turbine.services.uniqueid.TurbineUniqueIdService
>>>
>>> services.UploadService.classname=org.apache.turbine.services.upload.TurbineUploadService
>>>
>>> services.SecurityService.classname=org.apache.turbine.services.security.db.DBSecurityService
>>>
>>> services.PullService.classname=org.apache.turbine.services.pull.TurbinePullService
>>>
>>> services.TemplateService.classname=org.apache.turbine.services.template.TurbineTemplateService
>>>
>>> services.XSLTService.classname=org.apache.turbine.services.xslt.TurbineXSLTService
>>>
>>> services.VelocityService.classname=org.apache.turbine.services.velocity.TurbineVelocityService
>>>
>>>
>>> Could I suggest that we use jira to keep track of what is being
>>> done. It looks like we could both be working on the fulcrum tree at
>>> the same time. (unless you finish all the conversion over the next
>>> four days, that is ;-) )
>>>
>> Agreed
>
>
> I'll catch up with you next week. I'm off for a long weekend now.
>
> Regards,
>
> Peter
>
>>
>>> Regards,
>>>
>>> Peter
>>>
>>>
>>> Siegfried Goeschl wrote:
>>>
>>>> Hi folks,
>>>>
>>>> are there any plans which existing Turbine services need to be
>>>> migrated for the next Turbine milestone release? Currently the
>>>> following Avalon-based services are currently used within Turbine
>>>> CVS HEAD
>>>>
>>>> * org.apache.torque.avalon.Torque
>>>> * org.apache.fulcrum.cache.GlobalCacheService
>>>> * org.apache.fulcrum.mimetype.MimeTypeService
>>>> * org.apache.fulcrum.crypto.CryptoService
>>>> * org.apache.fulcrum.localization.LocalizationService
>>>> * org.apache.fulcrum.intake.IntakeService
>>>> * org.apache.fulcrum.factory.FactoryService
>>>>
>>>> This is rather a proof of concept than anything else ... :-( ....
>>>> as good condidates (where I can help) are XML-RPC and XSLT service
>>>>
>>>> Cheers,
>>>>
>>>> Siegfried Goeschl
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Current State of Migrating Turbine Services To Fulcrum ....
Posted by Peter Courcoux <pe...@courcoux.biz>.
Hi Siegfried,
Comments below:-
Siegfried Goeschl wrote:
> Hi Peter,
>
> see my comments below ...
>
> Siegfried Goeschl
>
> Peter Courcoux wrote:
>
>> Siegfried,
>>
>> I've put an issue in jira regarding the fortress service and assigned
>> it to me. I have a service working locally now and am just trying to
>> build fulcrum with the fortress meta tags so I can use them within
>> fortress for testing. I've also updated the maven-fortress-plugin so
>> that it works for me with my build system.
>>
> Correct me if I'm wrong - is the usage of maven-fortress-plugin
> mandatory? I have problems with Maven builds requiring custom plugins
> since the tend to be broken when being used on multiple Maven versions
> and platforms.
>
There is an Ant task which does what is needed and which is simply
called by the maven plugin. I'm not a maven expert. Maybe Eric could
help on this.
>> I'm away from tomorrow until Monday evening and will not be making any
>> further progress until then.
>>
>> While I've been playing with fortress I have got no further switching
>> services. One question for you, are you aware of any reason that might
>> prevent us switching to the latest Avalon/excalibur dependencies for
>> all the fulcrum components. They are at RC3 now and a vote has been
>> called to release without change?
>
>
> I give the new avalon-framework a try until Monday evening and commit
> the changes by then. When using Fortress container instead of YAAFI
> there is a liittle problem - each Avalon container comes with a
> different set of variables for the Avalon context. The Fulcrum services
> currently follow the Merlin conventionn but this is easy to change. And
> YAAFI supports Fortress context naming anyway using the
> <component-flavour> tag.
>
That helps.
> Do you have an Turbine AvalonComponentService for Fortress up and
> running with the latest Fortress release?
>
Yes I'm using RC3 builds.
>>
>> In answer to your question :
>>
>> The follwoing services are still listed in the
>> TurbineResources.properties file from cvs head
>>
>> IIRC the intention was to convert all of the services listed below to
>> fulcrum services and then use them in turbine 2.4. We will need to
>> keep the old service framework in place with no changes to
>> functionality while switching to the new services so that the old
>> stuff can be deprecated and only removed from cvs head after release
>> of 2.4.
>
>
> I can leand a hand for services I know of since I never used Turbine for
> a web-application .... :-)
>
> +)
> services.XmlRpcService.classname=org.apache.turbine.services.xmlrpc.TurbineXmlRpcService
>
> +)
> services.XSLTService.classname=org.apache.turbine.services.xslt.TurbineXSLTService
>
> +)
> services.UniqueIdService.classname=org.apache.turbine.services.uniqueid.TurbineUniqueIdService
>
>
Great.
Any volunteers for any of the others?
>>
>> services.FactoryService.classname=org.apache.turbine.services.factory.TurbineFactoryService
>>
>> services.PoolService.classname=org.apache.turbine.services.pool.TurbinePoolService
>>
>> services.RunDataService.classname=org.apache.turbine.services.rundata.TurbineRunDataService
>>
>> services.ServletService.classname=org.apache.turbine.services.servlet.TurbineServletService
>>
>> services.AssemblerBrokerService.classname=org.apache.turbine.services.assemblerbroker.TurbineAssemblerBrokerService
>>
>> services.SchedulerService.classname=org.apache.turbine.services.schedule.TurbineSchedulerService
>>
>> services.XmlRpcService.classname=org.apache.turbine.services.xmlrpc.TurbineXmlRpcService
>>
>> services.UniqueIdService.classname=org.apache.turbine.services.uniqueid.TurbineUniqueIdService
>>
>> services.UploadService.classname=org.apache.turbine.services.upload.TurbineUploadService
>>
>> services.SecurityService.classname=org.apache.turbine.services.security.db.DBSecurityService
>>
>> services.PullService.classname=org.apache.turbine.services.pull.TurbinePullService
>>
>> services.TemplateService.classname=org.apache.turbine.services.template.TurbineTemplateService
>>
>> services.XSLTService.classname=org.apache.turbine.services.xslt.TurbineXSLTService
>>
>> services.VelocityService.classname=org.apache.turbine.services.velocity.TurbineVelocityService
>>
>>
>> Could I suggest that we use jira to keep track of what is being done.
>> It looks like we could both be working on the fulcrum tree at the same
>> time. (unless you finish all the conversion over the next four days,
>> that is ;-) )
>>
> Agreed
I'll catch up with you next week. I'm off for a long weekend now.
Regards,
Peter
>
>> Regards,
>>
>> Peter
>>
>>
>> Siegfried Goeschl wrote:
>>
>>> Hi folks,
>>>
>>> are there any plans which existing Turbine services need to be
>>> migrated for the next Turbine milestone release? Currently the
>>> following Avalon-based services are currently used within Turbine CVS
>>> HEAD
>>>
>>> * org.apache.torque.avalon.Torque
>>> * org.apache.fulcrum.cache.GlobalCacheService
>>> * org.apache.fulcrum.mimetype.MimeTypeService
>>> * org.apache.fulcrum.crypto.CryptoService
>>> * org.apache.fulcrum.localization.LocalizationService
>>> * org.apache.fulcrum.intake.IntakeService
>>> * org.apache.fulcrum.factory.FactoryService
>>>
>>> This is rather a proof of concept than anything else ... :-( .... as
>>> good condidates (where I can help) are XML-RPC and XSLT service
>>>
>>> Cheers,
>>>
>>> Siegfried Goeschl
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
--
------------------------------
Peter Courcoux
Telephone : +44 (0)1923 661488
Mobile : 07880 605626
email : peter@courcoux.biz
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Current State of Migrating Turbine Services To Fulcrum ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Peter,
see my comments below ...
Siegfried Goeschl
Peter Courcoux wrote:
> Siegfried,
>
> I've put an issue in jira regarding the fortress service and assigned
> it to me. I have a service working locally now and am just trying to
> build fulcrum with the fortress meta tags so I can use them within
> fortress for testing. I've also updated the maven-fortress-plugin so
> that it works for me with my build system.
>
Correct me if I'm wrong - is the usage of maven-fortress-plugin
mandatory? I have problems with Maven builds requiring custom plugins
since the tend to be broken when being used on multiple Maven versions
and platforms.
> I'm away from tomorrow until Monday evening and will not be making any
> further progress until then.
>
> While I've been playing with fortress I have got no further switching
> services. One question for you, are you aware of any reason that might
> prevent us switching to the latest Avalon/excalibur dependencies for
> all the fulcrum components. They are at RC3 now and a vote has been
> called to release without change?
I give the new avalon-framework a try until Monday evening and commit
the changes by then. When using Fortress container instead of YAAFI
there is a liittle problem - each Avalon container comes with a
different set of variables for the Avalon context. The Fulcrum services
currently follow the Merlin conventionn but this is easy to change. And
YAAFI supports Fortress context naming anyway using the
<component-flavour> tag.
Do you have an Turbine AvalonComponentService for Fortress up and
running with the latest Fortress release?
>
> In answer to your question :
>
> The follwoing services are still listed in the
> TurbineResources.properties file from cvs head
>
> IIRC the intention was to convert all of the services listed below to
> fulcrum services and then use them in turbine 2.4. We will need to
> keep the old service framework in place with no changes to
> functionality while switching to the new services so that the old
> stuff can be deprecated and only removed from cvs head after release
> of 2.4.
I can leand a hand for services I know of since I never used Turbine for
a web-application .... :-)
+)
services.XmlRpcService.classname=org.apache.turbine.services.xmlrpc.TurbineXmlRpcService
+)
services.XSLTService.classname=org.apache.turbine.services.xslt.TurbineXSLTService
+)
services.UniqueIdService.classname=org.apache.turbine.services.uniqueid.TurbineUniqueIdService
>
> services.FactoryService.classname=org.apache.turbine.services.factory.TurbineFactoryService
>
> services.PoolService.classname=org.apache.turbine.services.pool.TurbinePoolService
>
> services.RunDataService.classname=org.apache.turbine.services.rundata.TurbineRunDataService
>
> services.ServletService.classname=org.apache.turbine.services.servlet.TurbineServletService
>
> services.AssemblerBrokerService.classname=org.apache.turbine.services.assemblerbroker.TurbineAssemblerBrokerService
>
> services.SchedulerService.classname=org.apache.turbine.services.schedule.TurbineSchedulerService
>
> services.XmlRpcService.classname=org.apache.turbine.services.xmlrpc.TurbineXmlRpcService
> services.UniqueIdService.classname=org.apache.turbine.services.uniqueid.TurbineUniqueIdService
>
> services.UploadService.classname=org.apache.turbine.services.upload.TurbineUploadService
>
> services.SecurityService.classname=org.apache.turbine.services.security.db.DBSecurityService
>
> services.PullService.classname=org.apache.turbine.services.pull.TurbinePullService
>
> services.TemplateService.classname=org.apache.turbine.services.template.TurbineTemplateService
>
> services.XSLTService.classname=org.apache.turbine.services.xslt.TurbineXSLTService
>
> services.VelocityService.classname=org.apache.turbine.services.velocity.TurbineVelocityService
>
>
> Could I suggest that we use jira to keep track of what is being done.
> It looks like we could both be working on the fulcrum tree at the same
> time. (unless you finish all the conversion over the next four days,
> that is ;-) )
>
Agreed
> Regards,
>
> Peter
>
>
> Siegfried Goeschl wrote:
>
>> Hi folks,
>>
>> are there any plans which existing Turbine services need to be
>> migrated for the next Turbine milestone release? Currently the
>> following Avalon-based services are currently used within Turbine CVS
>> HEAD
>>
>> * org.apache.torque.avalon.Torque
>> * org.apache.fulcrum.cache.GlobalCacheService
>> * org.apache.fulcrum.mimetype.MimeTypeService
>> * org.apache.fulcrum.crypto.CryptoService
>> * org.apache.fulcrum.localization.LocalizationService
>> * org.apache.fulcrum.intake.IntakeService
>> * org.apache.fulcrum.factory.FactoryService
>>
>> This is rather a proof of concept than anything else ... :-( .... as
>> good condidates (where I can help) are XML-RPC and XSLT service
>>
>> Cheers,
>>
>> Siegfried Goeschl
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org