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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> > > > > Just do the svn move manuall. Its not too hard.
> > > > >
> > > > > On 2/17/06, Arvid Hülsebus <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>
