On 2/21/06, Sean Schofield <[EMAIL PROTECTED]> wrote: > 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.
No, that's not exactly what I have proposed. Sorry if my description was misleading. The key point is this: * We do a one-time refactoring for impl classes where we switch the impl classes to org.apache.myfaces.commons.impl.* That means, impl classes would not know anything of the original o.a.m.commons.* classes any more. They would always be linked with the already repackaged o.a.m.commons.impl.* classes. So, testing and development of core is always against the repackaged commons classes. And if we do not auto-repackage for tomahawk, those tests would always be against the original o.a.m.commons.* classes. So, I don' t see a real problem here. Manfred > > 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 > > > > > > > > > > > > > > >