myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Schofield" <sean.schofi...@gmail.com>
Subject Re: Refactor Commons to org.apache.myfaces.commons ?
Date Mon, 20 Feb 2006 13:50:07 GMT
Wow that seems really complicated.  I have serious concerns about last
minute search and replace on the source code.  There's got to be a
easier solution.  Until we started down the maven path we were fine
with the way it is.  Lets re-examine why we are considering this in
the first place.

Manfred's scenario ...

Scenario:

1. We release commons-1.1.2 + core 1.1.2 (core 1.1.2 depends on commons-1.1.2)
2. days go by...
3. We release commons-1.1.3 (because there where significant changes)
+ tomahawk 1.1.3 (which depends on commons-1.1.3)

So, there are now the following official releases out there:

commons-1.1.2
commons-1.1.3
core-1.1.2
tomahawk-1.1.3

User "happy" starts his brandnew Maven project "unlucky", decides to
use the latest stable releases of everything and defines the following
dependencies:

XY depends on myfaces-api 1.1.2 (scope compile)
XY depends on myfaces-impl 1.1.2 (scope runtime)
XY depends on tomahawk 1.1.3 (scope compile)

Now he builds the WAR. Guess what he ends up with?
WEB-INF/lib/myfaces-api-1.1.2.jar
WEB-INF/lib/myfaces-commons-1.1.2.jar
WEB-INF/lib/myfaces-commons-1.1.3.jar
WEB-INF/lib/myfaces-impl-1.1.2.jar
WEB-INF/lib/myfaces-tomahawk-1.1.3.jar

I think we can solve this usecase without resorting to last minute
code refactoring by maven, or even worse, changing bytecode around.  I
just don't think those solutions are necessary.

One solution could be is that we make the scope of the commons
dependency in core and tomahawk to be provided.  That way its not
transitive and you don't end up with two versions of the commons jar
in your WAR.  What that means is that you need to declare explicitly a
commons dependency in your project as well as core and/or tomahawk.

In this case you would just say your project depends on commons
version 1.1.3.  Everything will be fine as long as 1.1.3 does not
break backwards compatability with an earlier version of the core.  We
can easily test this when we release tomahawk and if it does break
backwards compatability, we can release a newer version of the core as
well.

Its not ideal but its much better then the other alternatives we are
considering.  I think we carefully document and explain this on the
website and include instructions and considerations for those building
with maven or using myfaces implementation in their J2EE containers.

Sean




On 2/18/06, Manfred Geiler <manfred.geiler@gmail.com> wrote:
> As Martin already has mentioned, I'm more and more convinced too, that
> repackaging commons for impl is the only solution that will make as
> carefree in the long run.
>
> Though, I do not agree that it is necessary or advantageous to
> repackage commons for all component libs (tomahawk, tobago, adffaces).
> This would bring commons far away from the original idea of having a
> Jakarta commons like JSF library with goodies and convenient base
> classes for custom components. Yes, people will probably have
> conflicts. But the release cycles of our component libs should be fast
> enough and commons should become stable enough, so that this is no
> longer a problem.
>
> MyFaces-Core (ie. impl) is different insofar as
>  * we want to keep release cycles at a minimum
>  * it will become integrated part of containers (already shipped with
> JBoss 4.x), or
>  * people make them "part" of their containers by sharing
> myfaces-api.jar and myfaces-impl.jar in the containers common/lib or
> shared/lib dir.
> The last two points also will have influence on how people will
> configure their own Maven projects: "provided" dependency on
> myfaces-api.jar and myfaces-impl.jar of the version that was shipped
> with (or is integrated in) the container. People will behave
> conservative in changing their container environment and behave
> liberal when using the newest component lib.
> However, as soon as we have a repackaging solution, it is easy enough
> to use it not only for impl. So, let's discuss repackaging in general
> first and postpone the question of using repackaged commons lib for
> tomahawk et al. for a while, ok?
>
> Here is my idea for a (not-so-high-sophisticated but) easy repackaging solution:
> 1. First of all we refactor Commons to org.apache.myfaces.commons.*
> (we already have an agreement on this)
>
> 2. Next we create a sub-project in commons. Working title
> "intermediate-commons-impl".
>
> => This project's outcome will be the intermediate-commons-impl.jar
> file with all commons classes auto-repackaged to
> org.apache.myfaces.commons.impl.* (like proposed by Simon).
>
> => This jar file will not be shipped or included in any assembly
> (therefore "intermediate"). It only serves as the Maven-way medium to
> transport the repackaged commons classes to the impl module. The
> repackaged class files will later be included directly into
> myfaces-impl.jar.
>
> => Why a sub-project in commons? Because we have the commons sources
> at hand by using a path like ../src/main/java
>
> => How to create this intermediate-commons-impl.jar? I think a simple
> search-and-replace on source level could do the job (not sure but
> worth a try IMHO):
>    <plugin>
>      <artifactId>maven-antrun-plugin</artifactId>
>      <executions>
>        <execution>
>          <phase>generate-sources</phase>
>          <configuration>
>            <tasks>
>              <copy
> todir="${project.build.directory}/generated-sources/main/java">
>                <fileset dir="../src/main/java"/>
>              </copy>
>              <replace
> dir="${project.build.directory}/generated-sources/main/java">
>                <include name="**/*.java"/>
>                <replacetoken>org.apache.myfaces.commons.</replacetoken>
>                <replacevalue>org.apache.myfaces.commons.impl.</replacevalue>
>              </replace>
>            </tasks>
>            <sourceRoot>${project.build.directory}/generated-sources/main/java</sourceRoot>
>          </configuration>
>          <goals>
>            <goal>run</goal>
>          </goals>
>        </execution>
>      </executions>
>    </plugin>
>
> => How to integrate in myfaces-impl.jar?
>       * We add a dependency, so that impl classes can be compiled
> against org.apache.myfaces.commons.impl.* classes.
>       * We use "provided" as dependency scope to avoid
> intermediate-commons-impl.jar of being shipped with core assembly.
>       * We do a one-time refactoring for impl classes where we switch
> the impl classes to org.apache.myfaces.commons.impl.*
>       * We should be able to trick the maven-dependency-plugin into
> expanding the intermediate-commons-impl.jar classes into
> target/classes so that they get packed together with the impl classes.
>
> That's it.
>
> Thoughts?
>
> Please note: I do not want to create an accomplished fact here. I am
> aware that we should held a voting on "auto-repackaging yes/no" in the
> end. I only wanted to share my ideas with you first. And my personal
> feeling is, that we should not hold a final voting on this before we
> did not have a chance to experiment a little bit first.
>
> Manfred
>
>
>
> On 2/18/06, Martin Marinschek <martin.marinschek@gmail.com> wrote:
> > My opinion is that you're absolutely right.
> >
> > This point of view has already been voiced by John Fallows a year ago,
> > but at this time we weren't ready to see it his way ;)
> >
> > I do believe we will need to go down this road.
> >
> > We discussed with Manfred yesterday, and we were of the opinion that
> > we'd need to repackage only once, though - so use commons for tomahawk
> > and repackage it for impl.
> >
> > But in the light of a new day, if we want to use commons for tobago as
> > well, we'll need to repackage it for every other subproject which
> > might use it.
> >
> > regards,
> >
> > Martin
> >
> >
> >
> > On 2/17/06, Simon Kitching <skitching@apache.org> wrote:
> > > Hi All,
> > >
> > > I'm personally not in favour of releasing commons at all.
> > > I think the correct solution is to have a build step that automatically
> > > changes the package-name of the commons classes and builds it into the
> > > real project being built.
> > >
> > > As an example, when building impl, org.apache.myfaces.SomeUtil becomes
> > > org.apache.myfaces.impl.SomeUtil and is then included in the impl
> > > jarfile. For tomahawk, the class becomes
> > > org.apache.myfaces.tomahawk.SomeUtil etc.
> > >
> > > This should:
> > > (a) solve the branching/synchronisation issues discussed on the thread
> > > titled "New Tomahawk Branch".
> > > (b) solve any version-conflict issues, where a new version of tomahawk
> > > is being used against an older version of myfaces impl and vice versa.
> > > (c) restore the number of jarfiles in myfaces to the same as the sun RI,
> > > ie api, impl.
> > >
> > > Actually, I would be in favour of renaming all commons stuff to
> > > org.apache.myfaces.commons anyway; that would still work fine with
> > > either approach and is clearer.
> > >
> > > I'm not quite sure what the best way to handle the build is; source
> > > could build against org.apache.myfaces.SomeUtil, and the package
> > > tweaking then occurs after the code is all built. Alternatively source
> > > could build against org.apache.myfaces.{module}.SomeUtil, which means a
> > > muilt-step build process: (a) repackage .class files from commons, (b)
> > > build source, (c) include commons classes into module jarfile.
> > >
> > > I am willing to put some time into this; I've done some bytecode
> > > manipulation stuff before and this isn't trivial but isn't terribly
> > > difficult either.
> > >
> > > I really do think that releasing a commons jarfile will cause very nasty
> > > release implications in the future.
> > >
> > > Opinions?
> > >
> > > Regards,
> > >
> > > Simon
> > >
> > > On Fri, 2006-02-17 at 10:05 -0500, Mike Kienenberger wrote:
> > > > The benefits outweight the downsides.  Currently, there's no guarantee
> > > > that any particular Myfaces release will support your custom
> > > > components if you have a dependency on our classes.
> > > >
> > > > Also, up to this point, if you're depending on Myfaces classes for
> > > > your custom components, it's difficult to know if you're depending on
> > > > API, IMPL, COMMONS, or TOMAHAWK pieces.   This should make it far
> > > > clearer, and make it easier for developers in the long run.
> > > >
> > > > A separate commons release is also new enough that it shouldn't be too
> > > > big of an issue.
> > > >
> > > > The sooner we start doing things the "right" way, the sooner people
> > > > can feel safe about using commons to build their components.
> > > >
> > > > On 2/17/06, Manfred Geiler <manfred.geiler@gmail.com> wrote:
> > > > > Well it's a package refactoring. So, each dependend (or using) class
> > > > > in impl and tomahawk must be aligned as well. I'm feeling much warmer
> > > > > when doing this within my IDE, which has total knowledge of all
> > > > > dependencies.  ;-)
> > > > >
> > > > > BTW, is everyone really aware of what I'm proposing here?
> > > > > We have an already released myfaces-commons-1.1.2 lib with package
structure
> > > > > org.apache.myfaces.*
> > > > > The next myfaces-commons-1.1.3 will have package structure
> > > > > org.apache.myfaces.commons.*
> > > > > This is not what normally should happen between minor release changes,
right?
> > > > > At least we must make prominent notice about this in commons 1.1.3
> > > > > release notes.
> > > > > Do you think there are already people out there, using myfaces-commons
> > > > > as base for there own components? They might be angry, no?  ;-)
> > > > >
> > > > > Everyone really sure? Really no objections?
> > > > > :-)
> > > > >
> > > > > Manfred
> > > > >
> > > > >
> > > > > On 2/17/06, Sean Schofield <sean.schofield@gmail.com> wrote:
> > > > > > Just do the svn move manuall.  Its not too hard.
> > > > > >
> > > > > > On 2/17/06, Arvid H´┐Żlsebus <arvid.huelsebus@atanion.com>
wrote:
> > > > > > > It looks like he had only problems with older versions
of IDEA or the
> > > > > > > Subversion client. We can't report any problems with IDEA
5.1.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Arvid
> > > > > > >
> > > > > > > Martin Marinschek wrote:
> > > > > > > > +1 from me. definitely.
> > > > > > > >
> > > > > > > > regards,
> > > > > > > >
> > > > > > > > Martin
> > > > > > > >
> > > > > > > > On 2/17/06, Arvid H´┐Żlsebus <arvid.huelsebus@atanion.com>
wrote:
> > > > > > > >
> > > > > > > >> Normally it does, but there are some limitations.
I will ask Udo when he
> > > > > > > >> is back -- in about 30 minutes. He gained some
experience restructuring
> > > > > > > >> our repository for the donation of the Tobago
source.
> > > > > > > >>
> > > > > > > >> Regards,
> > > > > > > >> Arvid
> > > > > > > >>
> > > > > > > >> Manfred Geiler wrote:
> > > > > > > >>
> > > > > > > >>>> pps. Use svn move to do this so we don't
lose our history
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>> Does anyone know if IntelliJ does "svn move"
behind the scenes when
> > > > > > > >>> moving (refactoring) classes?
> > > > > > > >>>
> > > > > > > >>> Thanks,
> > > > > > > >>> Manfred
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > http://www.irian.at
> > > > > > > >
> > > > > > > > Your JSF powerhouse -
> > > > > > > > JSF Consulting, Development and
> > > > > > > > Courses in English and German
> > > > > > > >
> > > > > > > > Professional Support for Apache MyFaces
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
Mime
View raw message