You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Sean Schofield <se...@gmail.com> on 2006/03/01 02:32:42 UTC
Re: [commons/shared refactoring status] shared is ready, myfaces-impl is done
Manfred,
I am unable to build the core. I get the following error message:
[INFO] -------------------------------------------------------------------------
---
[ERROR] BUILD ERROR
[INFO] -------------------------------------------------------------------------
---
[INFO] Error executing ant tasks
Embedded error: The following error occurred while executing this line:
D:\open-source\myfaces-core-1.1.2\impl\build.xml:30: D:\open-source\myfaces-core
-1.1.2\impl\target\refactored-shared-sources\main\resources not found.
[INFO] -------------------------------------------------------------------------
---
[INFO] For more information, run Maven with the -e switch
[INFO] -------------------------------------------------------------------------
I made some progress on the merge but I will need to resolve this
before I can check in.
Sean
On 2/28/06, Manfred Geiler <ma...@gmail.com> wrote:
> Ok, I did some major modifications:
> * shared module does not longer have submodules, instead the
> refactoring is now done directly in impl and tomahawk
> * shared creates two artifacts: one myfaces-shared-X.Y.Z.jar and one
> myfaces-shared-X.Y.Z-sources.jar
> * myfaces-shared-X.Y.Z.jar contains the pre-refactore shared classes
> is not needed (ie. no other project should depend on it and it will
> never be part of an assembly)
> * myfaces-shared-X.Y.Z-sources.jar contains all sources and resources
> and is used to "transfer" the shared sources two impl and tomahawk
> * impl and tomahawk now both take the
> myfaces-shared-X.Y.Z-sources.jar, unpack and refactor the sources and
> finally compile the modified shared classes together with there own
> classes
>
> There are still some quirks with the simple examples. So, please stay
> tuned or better: Please help to find the cause.
>
> Note: We are still speaking of core and tomahawk on branches 1_1_2
> until Sean is finsihed with merging down the trunk.
>
> Thanks,
> Manfred
>
>
> On 2/28/06, Manfred Geiler <ma...@gmail.com> wrote:
> > Hmm, then I made things even worse with my last checkin...
> > There are now no more relative paths without a basedir, but in
> > addition to depending on the parent src I have also added one central
> > build.xml into the parent dir. So, this one won't work with continuum
> > as well. :-(
> >
> > To be compatible to continuum one must not depend on directory
> > hierarchy. Is that really true?
> > What is the solution? Modify shared so that it produces a jar with
> > source files, that the two subprojects depend on? That will make the
> > build process even more complex than it is right now.
> >
> > Thoughts?
> >
> > Manfred
> >
> >
> > On 2/28/06, Sean Schofield <se...@gmail.com> wrote:
> > > OK the problem is that continuum puts each build in its own build with
> > > a version number. Say you build shared first, it goes in
> > > working-directory/102. Then you build shared-impl and it will have
> > > its own build number. It goes in working-directory/103. The two
> > > builds are not necessarily in the same directory.
> > >
> > > You can reproduce this problem (I think) by checking out *only* the
> > > shared-impl dir and trying to build it. The parent artifact is
> > > available in the apache snapshot repos now (thanks to continuum) and
> > > also probably exists in your local repos. Yet you can't build because
> > > you are assuming a complete directory hiearchy.
> > >
> > > This is probably only relevant to continuum since I don't think there
> > > is much of a reason to try the usecase I have mentioned above. Still
> > > if there is a way to get the src from the snapshot jar of the parent
> > > process that would be nice.
> > >
> > > Sean
> > >
> > >
> > >
> > > On 2/28/06, Manfred Geiler <ma...@gmail.com> wrote:
> > > > Hmm, perhaps the "../src/main/java" (relative path) in the ant task
> > > > does not work when run with continuum? Perhaps we should move ant task
> > > > to an external build.xml and set the basedir explicitly. Will try this
> > > > right now.
> > > >
> > > > Manfred
> > > >
> > > >
> > > > On 2/28/06, Sean Schofield <se...@gmail.com> wrote:
> > > > > Manfred,
> > > > >
> > > > > I added shared to continuum but its choking on the refactoring[1]. I
> > > > > will look into it tomorrow but if you can point me in the right
> > > > > direction ...
> > > > >
> > > > > Sean
> > > > >
> > > > > [1]http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/ProjectBuild.vm?view=ProjectBuild&buildId=536&id=102
> > > > >
> > > > > On 2/27/06, Sean Schofield <se...@gmail.com> wrote:
> > > > > > Manfred,
> > > > > >
> > > > > > I did a checkout and test build. Everything compiled ok. Later today
> > > > > > I will look into the contents of the jar file and the behind the
> > > > > > scenes maven stuff. If it looks good I think we should try to merge
> > > > > > the core down to the trunk so people can continue to make changes
> > > > > > there.
> > > > > >
> > > > > > Sean
> > > > > >
> > > > > > On 2/26/06, Manfred Geiler <ma...@gmail.com> wrote:
> > > > > > > Step 3 is now done as well.
> > > > > > >
> > > > > > > Well, some examples already work but unfortunately not all.
> > > > > > > I think most of the problems are related to ExtensionsFilter and/or
> > > > > > > expression evaluation.
> > > > > > >
> > > > > > > Any help appreciated!
> > > > > > >
> > > > > > > You need:
> > > > > > > shared (SVN: trunk)
> > > > > > > core (SVN: branch 1_1_2)
> > > > > > > tomahawk (SVN: branch 1_1_2)
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Manfred
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 2/26/06, Manfred Geiler <ma...@gmail.com> wrote:
> > > > > > > > First two (of three) steps of commons-->shared refactoring is done:
> > > > > > > >
> > > > > > > > Step 1: All former commons classes have been copied to a new shared
> > > > > > > > module and have been refactored to package
> > > > > > > > "org.apache.myfaces.shared.*"
> > > > > > > >
> > > > > > > > Step 2: An intermediate myfaces-shared-impl-2.0.0-SNAPSHOT.jar is now
> > > > > > > > built automatically. It includes all shared classes auto-refactored to
> > > > > > > > "org.apache.myfaces.shared_impl.*" namespace.
> > > > > > > > Note: The "org.apache.myfaces.shared_impl" package is different to the
> > > > > > > > originally proposed "org.apache.myfaces.impl.shared". I will explain
> > > > > > > > the reasons why I chose another package name later in separate mail.
> > > > > > > > All impl classes in branch 1_1_2 have been refactored as well and now
> > > > > > > > use those "org.apache.myfaces.shared_impl" classes. In addition to
> > > > > > > > that the shared_impl classes are now automatically bundled together
> > > > > > > > with the impl classes and included in the
> > > > > > > > myfaces-impl-1.1.2-SNAPSHOT.jar.
> > > > > > > >
> > > > > > > > Step 3 is pending: Do all that was done for impl in Step 2 for the
> > > > > > > > tomahawk classes.
> > > > > > > >
> > > > > > > >
> > > > > > > > To try out you will need:
> > > > > > > > shared (trunk)
> > > > > > > > impl (branch 1_1_2)
> > > > > > > >
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Manfred
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [commons/shared refactoring status] shared is ready, myfaces-impl
is done
Posted by Mario Ivankovits <ma...@ops.co.at>.
Manfred Geiler schrieb:
> Can some of the eclipse gurus please try that out and revise the wiki
> instructions accordingly?
>
Not that I am a guru :-), but I'll do it.
Ciao,
Mario
Re: [commons/shared refactoring status] shared is ready, myfaces-impl
is done
Posted by Werner Punz <we...@gmx.at>.
The main problem is, that if you try to build everything from scratch
with mvn eclipse:eclipse in the old project structure that worked, you
also could deploy the sandbox examples directly from eclipse that way.
Now if you do that you run into runtime issues, due to the rename of the
shared packages in the last build stage.
I will try to find a solution to this problem, but the reorg and maven
switch as it is has made things very complicated for all users trying to
hack components within an IDE, partially due to the sad state of the
maven2 plugins.
(well it used to be easier until the build three subpackages from one
source within maven issue was programmed in)
Manfred Geiler schrieb:
> I recommend adding the *-sources.jar files instead of the target dirs
> for the reasons mentioned earlier in another thread (jar sources
> read-only, target dirs volatile, ...)
>
> Can some of the eclipse gurus please try that out and revise the wiki
> instructions accordingly?
>
> Thanks,
> Manfred
>
>
>
> On 3/2/06, Werner Punz <we...@gmx.at> wrote:
>> Mario Ivankovits schrieb:
>>> Hi!
>>>> Is there any reason for having after an eclipse import references to a
>>>> non existing shared_impl package?
>>>>
>>> I've posted a workaround for this (with eclipse)
>>> See in wiki "Building with myfaces" how to workaround this problem.
>>>
>>> Unhappily you have to adjust the project, for now.
>>>
>>> Ciao,
>>> Mario
>>>
>>>
>> Thanks mario, adding the refactoring source paths helped ;-)
>>
>>
>
Re: [commons/shared refactoring status] shared is ready, myfaces-impl is done
Posted by Manfred Geiler <ma...@gmail.com>.
I recommend adding the *-sources.jar files instead of the target dirs
for the reasons mentioned earlier in another thread (jar sources
read-only, target dirs volatile, ...)
Can some of the eclipse gurus please try that out and revise the wiki
instructions accordingly?
Thanks,
Manfred
On 3/2/06, Werner Punz <we...@gmx.at> wrote:
> Mario Ivankovits schrieb:
> > Hi!
> >> Is there any reason for having after an eclipse import references to a
> >> non existing shared_impl package?
> >>
> > I've posted a workaround for this (with eclipse)
> > See in wiki "Building with myfaces" how to workaround this problem.
> >
> > Unhappily you have to adjust the project, for now.
> >
> > Ciao,
> > Mario
> >
> >
> Thanks mario, adding the refactoring source paths helped ;-)
>
>
Re: [commons/shared refactoring status] shared is ready, myfaces-impl
is done
Posted by Werner Punz <we...@gmx.at>.
Mario Ivankovits schrieb:
> Hi!
>> Is there any reason for having after an eclipse import references to a
>> non existing shared_impl package?
>>
> I've posted a workaround for this (with eclipse)
> See in wiki "Building with myfaces" how to workaround this problem.
>
> Unhappily you have to adjust the project, for now.
>
> Ciao,
> Mario
>
>
Thanks mario, adding the refactoring source paths helped ;-)
Re: [commons/shared refactoring status] shared is ready, myfaces-impl
is done
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> Is there any reason for having after an eclipse import references to a
> non existing shared_impl package?
>
I've posted a workaround for this (with eclipse)
See in wiki "Building with myfaces" how to workaround this problem.
Unhappily you have to adjust the project, for now.
Ciao,
Mario
Re: [commons/shared refactoring status] shared is ready, myfaces-impl
is done
Posted by Werner Punz <we...@gmx.at>.
Is there any reason for having after an eclipse import references to a
non existing shared_impl package?
Manfred Geiler schrieb:
> Problem should be fixed now.
> Though I do not understand why it worked for me.
> Sean, did you use the current shared or did you use a modified version
> (ie. without AddResource.properties)?
>
> Manfred
>
>
> On 3/1/06, Sean Schofield <se...@gmail.com> wrote:
>> Manfred,
>>
>> I am unable to build the core. I get the following error message:
>>
>> [INFO] -------------------------------------------------------------------------
>> ---
>> [ERROR] BUILD ERROR
>> [INFO] -------------------------------------------------------------------------
>> ---
>> [INFO] Error executing ant tasks
>>
>> Embedded error: The following error occurred while executing this line:
>> D:\open-source\myfaces-core-1.1.2\impl\build.xml:30: D:\open-source\myfaces-core
>> -1.1.2\impl\target\refactored-shared-sources\main\resources not found.
>> [INFO] -------------------------------------------------------------------------
>> ---
>> [INFO] For more information, run Maven with the -e switch
>> [INFO] -------------------------------------------------------------------------
>>
>>
>> I made some progress on the merge but I will need to resolve this
>> before I can check in.
>>
>> Sean
>>
>> On 2/28/06, Manfred Geiler <ma...@gmail.com> wrote:
>>> Ok, I did some major modifications:
>>> * shared module does not longer have submodules, instead the
>>> refactoring is now done directly in impl and tomahawk
>>> * shared creates two artifacts: one myfaces-shared-X.Y.Z.jar and one
>>> myfaces-shared-X.Y.Z-sources.jar
>>> * myfaces-shared-X.Y.Z.jar contains the pre-refactore shared classes
>>> is not needed (ie. no other project should depend on it and it will
>>> never be part of an assembly)
>>> * myfaces-shared-X.Y.Z-sources.jar contains all sources and resources
>>> and is used to "transfer" the shared sources two impl and tomahawk
>>> * impl and tomahawk now both take the
>>> myfaces-shared-X.Y.Z-sources.jar, unpack and refactor the sources and
>>> finally compile the modified shared classes together with there own
>>> classes
>>>
>>> There are still some quirks with the simple examples. So, please stay
>>> tuned or better: Please help to find the cause.
>>>
>>> Note: We are still speaking of core and tomahawk on branches 1_1_2
>>> until Sean is finsihed with merging down the trunk.
>>>
>>> Thanks,
>>> Manfred
>>>
>>>
>>> On 2/28/06, Manfred Geiler <ma...@gmail.com> wrote:
>>>> Hmm, then I made things even worse with my last checkin...
>>>> There are now no more relative paths without a basedir, but in
>>>> addition to depending on the parent src I have also added one central
>>>> build.xml into the parent dir. So, this one won't work with continuum
>>>> as well. :-(
>>>>
>>>> To be compatible to continuum one must not depend on directory
>>>> hierarchy. Is that really true?
>>>> What is the solution? Modify shared so that it produces a jar with
>>>> source files, that the two subprojects depend on? That will make the
>>>> build process even more complex than it is right now.
>>>>
>>>> Thoughts?
>>>>
>>>> Manfred
>>>>
>>>>
>>>> On 2/28/06, Sean Schofield <se...@gmail.com> wrote:
>>>>> OK the problem is that continuum puts each build in its own build with
>>>>> a version number. Say you build shared first, it goes in
>>>>> working-directory/102. Then you build shared-impl and it will have
>>>>> its own build number. It goes in working-directory/103. The two
>>>>> builds are not necessarily in the same directory.
>>>>>
>>>>> You can reproduce this problem (I think) by checking out *only* the
>>>>> shared-impl dir and trying to build it. The parent artifact is
>>>>> available in the apache snapshot repos now (thanks to continuum) and
>>>>> also probably exists in your local repos. Yet you can't build because
>>>>> you are assuming a complete directory hiearchy.
>>>>>
>>>>> This is probably only relevant to continuum since I don't think there
>>>>> is much of a reason to try the usecase I have mentioned above. Still
>>>>> if there is a way to get the src from the snapshot jar of the parent
>>>>> process that would be nice.
>>>>>
>>>>> Sean
>>>>>
>>>>>
>>>>>
>>>>> On 2/28/06, Manfred Geiler <ma...@gmail.com> wrote:
>>>>>> Hmm, perhaps the "../src/main/java" (relative path) in the ant task
>>>>>> does not work when run with continuum? Perhaps we should move ant task
>>>>>> to an external build.xml and set the basedir explicitly. Will try this
>>>>>> right now.
>>>>>>
>>>>>> Manfred
>>>>>>
>>>>>>
>>>>>> On 2/28/06, Sean Schofield <se...@gmail.com> wrote:
>>>>>>> Manfred,
>>>>>>>
>>>>>>> I added shared to continuum but its choking on the refactoring[1]. I
>>>>>>> will look into it tomorrow but if you can point me in the right
>>>>>>> direction ...
>>>>>>>
>>>>>>> Sean
>>>>>>>
>>>>>>> [1]http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/ProjectBuild.vm?view=ProjectBuild&buildId=536&id=102
>>>>>>>
>>>>>>> On 2/27/06, Sean Schofield <se...@gmail.com> wrote:
>>>>>>>> Manfred,
>>>>>>>>
>>>>>>>> I did a checkout and test build. Everything compiled ok. Later today
>>>>>>>> I will look into the contents of the jar file and the behind the
>>>>>>>> scenes maven stuff. If it looks good I think we should try to merge
>>>>>>>> the core down to the trunk so people can continue to make changes
>>>>>>>> there.
>>>>>>>>
>>>>>>>> Sean
>>>>>>>>
>>>>>>>> On 2/26/06, Manfred Geiler <ma...@gmail.com> wrote:
>>>>>>>>> Step 3 is now done as well.
>>>>>>>>>
>>>>>>>>> Well, some examples already work but unfortunately not all.
>>>>>>>>> I think most of the problems are related to ExtensionsFilter and/or
>>>>>>>>> expression evaluation.
>>>>>>>>>
>>>>>>>>> Any help appreciated!
>>>>>>>>>
>>>>>>>>> You need:
>>>>>>>>> shared (SVN: trunk)
>>>>>>>>> core (SVN: branch 1_1_2)
>>>>>>>>> tomahawk (SVN: branch 1_1_2)
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Manfred
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2/26/06, Manfred Geiler <ma...@gmail.com> wrote:
>>>>>>>>>> First two (of three) steps of commons-->shared refactoring is done:
>>>>>>>>>>
>>>>>>>>>> Step 1: All former commons classes have been copied to a new shared
>>>>>>>>>> module and have been refactored to package
>>>>>>>>>> "org.apache.myfaces.shared.*"
>>>>>>>>>>
>>>>>>>>>> Step 2: An intermediate myfaces-shared-impl-2.0.0-SNAPSHOT.jar is now
>>>>>>>>>> built automatically. It includes all shared classes auto-refactored to
>>>>>>>>>> "org.apache.myfaces.shared_impl.*" namespace.
>>>>>>>>>> Note: The "org.apache.myfaces.shared_impl" package is different to the
>>>>>>>>>> originally proposed "org.apache.myfaces.impl.shared". I will explain
>>>>>>>>>> the reasons why I chose another package name later in separate mail.
>>>>>>>>>> All impl classes in branch 1_1_2 have been refactored as well and now
>>>>>>>>>> use those "org.apache.myfaces.shared_impl" classes. In addition to
>>>>>>>>>> that the shared_impl classes are now automatically bundled together
>>>>>>>>>> with the impl classes and included in the
>>>>>>>>>> myfaces-impl-1.1.2-SNAPSHOT.jar.
>>>>>>>>>>
>>>>>>>>>> Step 3 is pending: Do all that was done for impl in Step 2 for the
>>>>>>>>>> tomahawk classes.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> To try out you will need:
>>>>>>>>>> shared (trunk)
>>>>>>>>>> impl (branch 1_1_2)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Manfred
>>>>>>>>>>
>
Re: [commons/shared refactoring status] shared is ready, myfaces-impl is done
Posted by Manfred Geiler <ma...@gmail.com>.
Problem should be fixed now.
Though I do not understand why it worked for me.
Sean, did you use the current shared or did you use a modified version
(ie. without AddResource.properties)?
Manfred
On 3/1/06, Sean Schofield <se...@gmail.com> wrote:
> Manfred,
>
> I am unable to build the core. I get the following error message:
>
> [INFO] -------------------------------------------------------------------------
> ---
> [ERROR] BUILD ERROR
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] Error executing ant tasks
>
> Embedded error: The following error occurred while executing this line:
> D:\open-source\myfaces-core-1.1.2\impl\build.xml:30: D:\open-source\myfaces-core
> -1.1.2\impl\target\refactored-shared-sources\main\resources not found.
> [INFO] -------------------------------------------------------------------------
> ---
> [INFO] For more information, run Maven with the -e switch
> [INFO] -------------------------------------------------------------------------
>
>
> I made some progress on the merge but I will need to resolve this
> before I can check in.
>
> Sean
>
> On 2/28/06, Manfred Geiler <ma...@gmail.com> wrote:
> > Ok, I did some major modifications:
> > * shared module does not longer have submodules, instead the
> > refactoring is now done directly in impl and tomahawk
> > * shared creates two artifacts: one myfaces-shared-X.Y.Z.jar and one
> > myfaces-shared-X.Y.Z-sources.jar
> > * myfaces-shared-X.Y.Z.jar contains the pre-refactore shared classes
> > is not needed (ie. no other project should depend on it and it will
> > never be part of an assembly)
> > * myfaces-shared-X.Y.Z-sources.jar contains all sources and resources
> > and is used to "transfer" the shared sources two impl and tomahawk
> > * impl and tomahawk now both take the
> > myfaces-shared-X.Y.Z-sources.jar, unpack and refactor the sources and
> > finally compile the modified shared classes together with there own
> > classes
> >
> > There are still some quirks with the simple examples. So, please stay
> > tuned or better: Please help to find the cause.
> >
> > Note: We are still speaking of core and tomahawk on branches 1_1_2
> > until Sean is finsihed with merging down the trunk.
> >
> > Thanks,
> > Manfred
> >
> >
> > On 2/28/06, Manfred Geiler <ma...@gmail.com> wrote:
> > > Hmm, then I made things even worse with my last checkin...
> > > There are now no more relative paths without a basedir, but in
> > > addition to depending on the parent src I have also added one central
> > > build.xml into the parent dir. So, this one won't work with continuum
> > > as well. :-(
> > >
> > > To be compatible to continuum one must not depend on directory
> > > hierarchy. Is that really true?
> > > What is the solution? Modify shared so that it produces a jar with
> > > source files, that the two subprojects depend on? That will make the
> > > build process even more complex than it is right now.
> > >
> > > Thoughts?
> > >
> > > Manfred
> > >
> > >
> > > On 2/28/06, Sean Schofield <se...@gmail.com> wrote:
> > > > OK the problem is that continuum puts each build in its own build with
> > > > a version number. Say you build shared first, it goes in
> > > > working-directory/102. Then you build shared-impl and it will have
> > > > its own build number. It goes in working-directory/103. The two
> > > > builds are not necessarily in the same directory.
> > > >
> > > > You can reproduce this problem (I think) by checking out *only* the
> > > > shared-impl dir and trying to build it. The parent artifact is
> > > > available in the apache snapshot repos now (thanks to continuum) and
> > > > also probably exists in your local repos. Yet you can't build because
> > > > you are assuming a complete directory hiearchy.
> > > >
> > > > This is probably only relevant to continuum since I don't think there
> > > > is much of a reason to try the usecase I have mentioned above. Still
> > > > if there is a way to get the src from the snapshot jar of the parent
> > > > process that would be nice.
> > > >
> > > > Sean
> > > >
> > > >
> > > >
> > > > On 2/28/06, Manfred Geiler <ma...@gmail.com> wrote:
> > > > > Hmm, perhaps the "../src/main/java" (relative path) in the ant task
> > > > > does not work when run with continuum? Perhaps we should move ant task
> > > > > to an external build.xml and set the basedir explicitly. Will try this
> > > > > right now.
> > > > >
> > > > > Manfred
> > > > >
> > > > >
> > > > > On 2/28/06, Sean Schofield <se...@gmail.com> wrote:
> > > > > > Manfred,
> > > > > >
> > > > > > I added shared to continuum but its choking on the refactoring[1]. I
> > > > > > will look into it tomorrow but if you can point me in the right
> > > > > > direction ...
> > > > > >
> > > > > > Sean
> > > > > >
> > > > > > [1]http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/ProjectBuild.vm?view=ProjectBuild&buildId=536&id=102
> > > > > >
> > > > > > On 2/27/06, Sean Schofield <se...@gmail.com> wrote:
> > > > > > > Manfred,
> > > > > > >
> > > > > > > I did a checkout and test build. Everything compiled ok. Later today
> > > > > > > I will look into the contents of the jar file and the behind the
> > > > > > > scenes maven stuff. If it looks good I think we should try to merge
> > > > > > > the core down to the trunk so people can continue to make changes
> > > > > > > there.
> > > > > > >
> > > > > > > Sean
> > > > > > >
> > > > > > > On 2/26/06, Manfred Geiler <ma...@gmail.com> wrote:
> > > > > > > > Step 3 is now done as well.
> > > > > > > >
> > > > > > > > Well, some examples already work but unfortunately not all.
> > > > > > > > I think most of the problems are related to ExtensionsFilter and/or
> > > > > > > > expression evaluation.
> > > > > > > >
> > > > > > > > Any help appreciated!
> > > > > > > >
> > > > > > > > You need:
> > > > > > > > shared (SVN: trunk)
> > > > > > > > core (SVN: branch 1_1_2)
> > > > > > > > tomahawk (SVN: branch 1_1_2)
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Manfred
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 2/26/06, Manfred Geiler <ma...@gmail.com> wrote:
> > > > > > > > > First two (of three) steps of commons-->shared refactoring is done:
> > > > > > > > >
> > > > > > > > > Step 1: All former commons classes have been copied to a new shared
> > > > > > > > > module and have been refactored to package
> > > > > > > > > "org.apache.myfaces.shared.*"
> > > > > > > > >
> > > > > > > > > Step 2: An intermediate myfaces-shared-impl-2.0.0-SNAPSHOT.jar is now
> > > > > > > > > built automatically. It includes all shared classes auto-refactored to
> > > > > > > > > "org.apache.myfaces.shared_impl.*" namespace.
> > > > > > > > > Note: The "org.apache.myfaces.shared_impl" package is different to the
> > > > > > > > > originally proposed "org.apache.myfaces.impl.shared". I will explain
> > > > > > > > > the reasons why I chose another package name later in separate mail.
> > > > > > > > > All impl classes in branch 1_1_2 have been refactored as well and now
> > > > > > > > > use those "org.apache.myfaces.shared_impl" classes. In addition to
> > > > > > > > > that the shared_impl classes are now automatically bundled together
> > > > > > > > > with the impl classes and included in the
> > > > > > > > > myfaces-impl-1.1.2-SNAPSHOT.jar.
> > > > > > > > >
> > > > > > > > > Step 3 is pending: Do all that was done for impl in Step 2 for the
> > > > > > > > > tomahawk classes.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > To try out you will need:
> > > > > > > > > shared (trunk)
> > > > > > > > > impl (branch 1_1_2)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Manfred
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>