Is it safe to say we are going to stick with commons the way it is for
the upcoming core and tomahawk release? If so, I think we should go
ahead and create the JIRA project. I'd like to do that and then issue
some announcements and documentation on our new JIRA strategy.
Sean
On 2/21/06, John Fallows <[EMAIL PROTECTED]> wrote:
> Maven2 is even smarter that you might realize. :-)
>
> (see below)
>
>
> On 2/20/06, Sean Schofield <[EMAIL PROTECTED] > wrote:
> > 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
>
> Only one version of commons will be selected, so either commons-1.1.2 or
> commons-1.1.3 but not both, as long as both versions have the same groupId
> and artifactId in the Maven2 repository.
>
> I'm not totally certain of the exact selection algorithm used by Maven2 to
> choose the winning version, but I believe selecting the latest version makes
> the most sense.
>
> Kind Regards,
> John Fallows.
>
> > 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 < [EMAIL PROTECTED]> 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 <[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
> > > >
> > >
> >
>
>
>
> --
> http://apress.com/book/bookDisplay.html?bID=10044
> Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
