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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to