Refactor Commons to org.apache.myfaces.commons ?

[Manfred Geiler <ma...@gmail.com>]

One thing we could do for our users to make things clearer regarding
the question "Does a certain class belong to commons or not?":
Refactor all commons classes from
 org.apache.myfaces.*
to
 org.apache.myfaces.commons.*

I'm not sure at all if this is a good idea. Probably not ;-)
Just wanted to know what others think.

Manfred

Re: Refactor Commons to org.apache.myfaces.commons ?

[Manfred Geiler <ma...@gmail.com>]

On 2/20/06, Sean Schofield <se...@gmail.com> 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
>
> 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.

Yes, this sounds reasonable. If we decide against this auto-repackage
thingy, this is probably the right setting for our dependencies.

Manfred




> 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 <ma...@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 <ma...@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 <sk...@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 <ma...@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 <se...@gmail.com> wrote:
> > > > > > > Just do the svn move manuall.  Its not too hard.
> > > > > > >
> > > > > > > On 2/17/06, Arvid H�lsebus <ar...@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 <ar...@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
> > >
> >
>

Re: Refactor Commons to org.apache.myfaces.commons ?

[Manfred Geiler <ma...@gmail.com>]

On 2/21/06, Sean Schofield <se...@gmail.com> 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 <ma...@gmail.com> wrote:
> > On 2/20/06, Sean Schofield <se...@gmail.com> 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 <ma...@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 <ma...@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 <sk...@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 <ma...@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 <se...@gmail.com> wrote:
> > > > > > > > > Just do the svn move manuall.  Its not too hard.
> > > > > > > > >
> > > > > > > > > On 2/17/06, Arvid H�lsebus <ar...@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 <ar...@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
> > > > >
> > > >
> > >
> >
>

Re: Refactor Commons to org.apache.myfaces.commons ?

[Sean Schofield <se...@gmail.com>]

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 <ma...@gmail.com> wrote:
> On 2/20/06, Sean Schofield <se...@gmail.com> 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 <ma...@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 <ma...@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 <sk...@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 <ma...@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 <se...@gmail.com> wrote:
> > > > > > > > Just do the svn move manuall.  Its not too hard.
> > > > > > > >
> > > > > > > > On 2/17/06, Arvid H�lsebus <ar...@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 <ar...@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
> > > >
> > >
> >
>

Re: Refactor Commons to org.apache.myfaces.commons ?

[Manfred Geiler <ma...@gmail.com>]

On 2/20/06, Sean Schofield <se...@gmail.com> 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 <ma...@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 <ma...@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 <sk...@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 <ma...@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 <se...@gmail.com> wrote:
> > > > > > > Just do the svn move manuall.  Its not too hard.
> > > > > > >
> > > > > > > On 2/17/06, Arvid H�lsebus <ar...@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 <ar...@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
> > >
> >
>

Re: Refactor Commons to org.apache.myfaces.commons ?

[Sean Schofield <se...@gmail.com>]

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 <jo...@gmail.com> wrote:
> Maven2 is even smarter that you might realize. :-)
>
> (see below)
>
>
> On 2/20/06, Sean Schofield <sean.schofield@gmail.com > 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 < 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 <ma...@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 <sk...@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 <ma...@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 <ar...@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
> > > >
> > >
> >
>
>
>
>  --
> http://apress.com/book/bookDisplay.html?bID=10044
> Author: Pro JSF and Ajax: Building Rich Internet Components, Apress

Re: Refactor Commons to org.apache.myfaces.commons ?

[John Fallows <jo...@gmail.com>]

Maven2 is even smarter that you might realize. :-)

(see below)

On 2/20/06, Sean Schofield <se...@gmail.com> 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 <ma...@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 <ma...@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 <sk...@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.SomeUtilbecomes
> > > > 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 <ma...@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 <se...@gmail.com> wrote:
> > > > > > > Just do the svn move manuall.  Its not too hard.
> > > > > > >
> > > > > > > On 2/17/06, Arvid H�lsebus <ar...@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 <ar...@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
> > >
> >
>



--
http://apress.com/book/bookDisplay.html?bID=10044
Author: Pro JSF and Ajax: Building Rich Internet Components, Apress

Re: Refactor Commons to org.apache.myfaces.commons ?

[Sean Schofield <se...@gmail.com>]

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 <ma...@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 <ma...@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 <sk...@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 <ma...@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 <se...@gmail.com> wrote:
> > > > > > Just do the svn move manuall.  Its not too hard.
> > > > > >
> > > > > > On 2/17/06, Arvid H�lsebus <ar...@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 <ar...@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
> >
>

Re: Refactor Commons to org.apache.myfaces.commons ?

[Manfred Geiler <ma...@gmail.com>]

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 <ma...@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 <sk...@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 <ma...@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 <se...@gmail.com> wrote:
> > > > > Just do the svn move manuall.  Its not too hard.
> > > > >
> > > > > On 2/17/06, Arvid Hülsebus <ar...@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 <ar...@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
>

Re: Refactor Commons to org.apache.myfaces.commons ?

[Martin Marinschek <ma...@gmail.com>]

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 <sk...@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 <ma...@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 <se...@gmail.com> wrote:
> > > > Just do the svn move manuall.  Its not too hard.
> > > >
> > > > On 2/17/06, Arvid Hülsebus <ar...@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 <ar...@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

Re: Refactor Commons to org.apache.myfaces.commons ?

[Sean Schofield <se...@gmail.com>]

Yes lets take a moment to reconsider all of our options.

Sean

On 2/17/06, Simon Kitching <sk...@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 <ma...@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 <se...@gmail.com> wrote:
> > > > Just do the svn move manuall.  Its not too hard.
> > > >
> > > > On 2/17/06, Arvid Hülsebus <ar...@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 <ar...@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
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
>
>

Re: Refactor Commons to org.apache.myfaces.commons ?

[Simon Kitching <sk...@apache.org>]

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 <ma...@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 <se...@gmail.com> wrote:
> > > Just do the svn move manuall.  Its not too hard.
> > >
> > > On 2/17/06, Arvid Hülsebus <ar...@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 <ar...@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
> > > > >
> > > > >
> > > >
> > >
> >

Re: Refactor Commons to org.apache.myfaces.commons ?

[Mike Kienenberger <mk...@gmail.com>]

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 <ma...@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 <se...@gmail.com> wrote:
> > Just do the svn move manuall.  Its not too hard.
> >
> > On 2/17/06, Arvid Hülsebus <ar...@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 <ar...@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
> > > >
> > > >
> > >
> >
>

Re: Refactor Commons to org.apache.myfaces.commons ?

[Manfred Geiler <ma...@gmail.com>]

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 <se...@gmail.com> wrote:
> Just do the svn move manuall.  Its not too hard.
>
> On 2/17/06, Arvid Hülsebus <ar...@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 <ar...@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
> > >
> > >
> >
>

Re: Refactor Commons to org.apache.myfaces.commons ?

[Bruno Aranda <br...@gmail.com>]

+1

On 2/17/06, Sean Schofield <se...@gmail.com> wrote:
> One thing you could do is refactor using IDE so that the impl and
> tomahawk stuff are changed automatically.  Then revert your entire
> commons dir back to the way it was.  Then do an svn move for just the
> commons stuff (all at once) and then checkout.  Then check in the IDE
> refactored stuff.
>
> Make sense?  Once we get a few more +1's I'm willing to help with the
> svn move if you need it.
>
> Sean
>
> On 2/17/06, Sean Schofield <se...@gmail.com> wrote:
> > Just do the svn move manuall.  Its not too hard.
> >
> > On 2/17/06, Arvid Hülsebus <ar...@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 <ar...@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
> > > >
> > > >
> > >
> >
>

Re: Refactor Commons to org.apache.myfaces.commons ?

[Sean Schofield <se...@gmail.com>]

One thing you could do is refactor using IDE so that the impl and
tomahawk stuff are changed automatically.  Then revert your entire
commons dir back to the way it was.  Then do an svn move for just the
commons stuff (all at once) and then checkout.  Then check in the IDE
refactored stuff.

Make sense?  Once we get a few more +1's I'm willing to help with the
svn move if you need it.

Sean

On 2/17/06, Sean Schofield <se...@gmail.com> wrote:
> Just do the svn move manuall.  Its not too hard.
>
> On 2/17/06, Arvid Hülsebus <ar...@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 <ar...@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
> > >
> > >
> >
>

Re: Refactor Commons to org.apache.myfaces.commons ?

[Sean Schofield <se...@gmail.com>]

Just do the svn move manuall.  Its not too hard.

On 2/17/06, Arvid Hülsebus <ar...@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 <ar...@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
> >
> >
>

Re: Refactor Commons to org.apache.myfaces.commons ?

[Arvid Hülsebus <ar...@atanion.com>]

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 <ar...@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
>
>   

Re: Refactor Commons to org.apache.myfaces.commons ?

[Martin Marinschek <ma...@gmail.com>]

+1 from me. definitely.

regards,

Martin

On 2/17/06, Arvid Hülsebus <ar...@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

Re: Refactor Commons to org.apache.myfaces.commons ?

[Arvid Hülsebus <ar...@atanion.com>]

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
>
>   

Re: Refactor Commons to org.apache.myfaces.commons ?

[Manfred Geiler <ma...@gmail.com>]

> 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

Re: Refactor Commons to org.apache.myfaces.commons ?

[Sean Schofield <se...@gmail.com>]

Well tomahawk just branched now too so we might be safe to refactor at
this point.  It won't impact the upcoming core or tomahawk releases.

My suggestion is that we start with commons first and see how that
goes.  I can't think of anything where the class name would be
hard-coded.  Why don't we see if we can get a few +1's before such a
big change though?

Here's mine: +1

Sean

ps. I am not volunteering.

pps. Use svn move to do this so we don't lose our history


On 2/17/06, Matthias Wessendorf <mw...@gmail.com> wrote:
> > So, we should decide this BEFORE the release.
>
> I was only talking about tomahawk / sandbox
>
> for commons, yes ;-)
>
> > Manfred
> >
>
>
> --
> Matthias Wessendorf
> Zülpicher Wall 12, 239
> 50674 Köln
> http://www.wessendorf.net
> mwessendorf-at-gmail-dot-com
>

Re: Refactor Commons to org.apache.myfaces.commons ?

[Matthias Wessendorf <mw...@gmail.com>]

> So, we should decide this BEFORE the release.

I was only talking about tomahawk / sandbox

for commons, yes ;-)

> Manfred
>


--
Matthias Wessendorf
Zülpicher Wall 12, 239
50674 Köln
http://www.wessendorf.net
mwessendorf-at-gmail-dot-com

Re: Refactor Commons to org.apache.myfaces.commons ?

[Manfred Geiler <ma...@gmail.com>]

On 2/17/06, Matthias Wessendorf <mw...@gmail.com> wrote:
> > to
> >  org.apache.myfaces.commons.*
>
> yes, why not.
>
> > I'm not sure at all if this is a good idea. Probably not ;-)
> > Just wanted to know what others think.
>
> hehe, was just thinking the same
>
> What about tomahawk  ?
>
> o.a.m.custom.* ->
> o,a.m.tomahawk.*
>
> and for sandbox?
>
> o.a.m.tomahawk.sandbox.*
>
> or
>
> o.a.m.sandbox.*
>
> As you mentioned before... a release is more important.


Yes, but once the first commons release is out, there is no chance any
more to do this refactoring. At least not before we do a version jump
from 1.1.x to 1.2.x.
So, we should decide this BEFORE the release.

Manfred

Re: Refactor Commons to org.apache.myfaces.commons ?

[Matthias Wessendorf <mw...@gmail.com>]

> to
>  org.apache.myfaces.commons.*

yes, why not.

> I'm not sure at all if this is a good idea. Probably not ;-)
> Just wanted to know what others think.

hehe, was just thinking the same

What about tomahawk  ?

o.a.m.custom.* ->
o,a.m.tomahawk.*

and for sandbox?

o.a.m.tomahawk.sandbox.*

or

o.a.m.sandbox.*

As you mentioned before... a release is more important.

Just my $0.02

-Matthias
> Manfred
>


--
Matthias Wessendorf
Zülpicher Wall 12, 239
50674 Köln
http://www.wessendorf.net
mwessendorf-at-gmail-dot-com

Re: Refactor Commons to org.apache.myfaces.commons ?

[Mike Kienenberger <mk...@gmail.com>]

Sounds good to me.

+1 for renaming them.

On 2/17/06, Manfred Geiler <ma...@gmail.com> wrote:
> One thing we could do for our users to make things clearer regarding
> the question "Does a certain class belong to commons or not?":
> Refactor all commons classes from
>  org.apache.myfaces.*
> to
>  org.apache.myfaces.commons.*
>
> I'm not sure at all if this is a good idea. Probably not ;-)
> Just wanted to know what others think.
>
> Manfred
>