Yes I think this is unecessarily complicated. I've certainly never
contemplated anything like this before. If you think about it this
must be a fairly common problem. How many projects out there rely on
different versions of commons-collections?
My guess is that if you use maven to build something with two
different projects which each have a different transitive dependency
on commons-collections, you will end up with two commons-collections
in your WAR or whatever. We should ask John Fallows about this. He
seems to know all the maven details.
What I mean by "last minute" is that the java files will have one
package name during development and IDE testing and then just before
you do a maven build you will switch it all around. I agree that this
is better then tampering with byte code but it still seems like an
extreme solution to something that must be a relatively common
problem.
Ideally maven would have a feature that would include the newest
version of a dependency in the case of multiple conflicting versions
of a transitive dependency. If it doesn't perhaps we could put our
energies into helping them resolve this. In the meantime, I think my
proposed workaround would be better.
Sean
On 2/21/06, Manfred Geiler <[EMAIL PROTECTED]> wrote:
> 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.
>
> Do you really think this is complicated? I wanted to be as precise as
> possible - therefore the length of my email. Please reconsider, there
> is no really complex part in my proposal.
> I think a textual search-and-replace *is* a simple solution - in
> contrast to byte code manipulation or the like.
> What do you mean by "last minute"? This sounds like "hasty" or "dangerous".
> On a normal build (with SNAPSHOT versions) the intermediate transport
> lib will automatically be built and impl will be compiled against it.
> So, if there ever be a problem with the search-and-replace or for
> whatever reason the search-and-replace does not go far enough, you
> will immediately get a compile error. And under normal circumstances a
> developer won't commit changes in commons that lead to such an error.
> So, I cannot see any danger here.
>
> Manfred
>
>
>
> > 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 <[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
> > > >
> > >
> >
>
