My opinion is that you're absolutely right.
This point of view has already been voiced by John Fallows a year ago,
but at this time we weren't ready to see it his way ;)
I do believe we will need to go down this road.
We discussed with Manfred yesterday, and we were of the opinion that
we'd need to repackage only once, though - so use commons for tomahawk
and repackage it for impl.
But in the light of a new day, if we want to use commons for tobago as
well, we'll need to repackage it for every other subproject which
might use it.
regards,
Martin
On 2/17/06, Simon Kitching <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I'm personally not in favour of releasing commons at all.
> I think the correct solution is to have a build step that automatically
> changes the package-name of the commons classes and builds it into the
> real project being built.
>
> As an example, when building impl, org.apache.myfaces.SomeUtil becomes
> org.apache.myfaces.impl.SomeUtil and is then included in the impl
> jarfile. For tomahawk, the class becomes
> org.apache.myfaces.tomahawk.SomeUtil etc.
>
> This should:
> (a) solve the branching/synchronisation issues discussed on the thread
> titled "New Tomahawk Branch".
> (b) solve any version-conflict issues, where a new version of tomahawk
> is being used against an older version of myfaces impl and vice versa.
> (c) restore the number of jarfiles in myfaces to the same as the sun RI,
> ie api, impl.
>
> Actually, I would be in favour of renaming all commons stuff to
> org.apache.myfaces.commons anyway; that would still work fine with
> either approach and is clearer.
>
> I'm not quite sure what the best way to handle the build is; source
> could build against org.apache.myfaces.SomeUtil, and the package
> tweaking then occurs after the code is all built. Alternatively source
> could build against org.apache.myfaces.{module}.SomeUtil, which means a
> muilt-step build process: (a) repackage .class files from commons, (b)
> build source, (c) include commons classes into module jarfile.
>
> I am willing to put some time into this; I've done some bytecode
> manipulation stuff before and this isn't trivial but isn't terribly
> difficult either.
>
> I really do think that releasing a commons jarfile will cause very nasty
> release implications in the future.
>
> Opinions?
>
> Regards,
>
> Simon
>
> On Fri, 2006-02-17 at 10:05 -0500, Mike Kienenberger wrote:
> > The benefits outweight the downsides. Currently, there's no guarantee
> > that any particular Myfaces release will support your custom
> > components if you have a dependency on our classes.
> >
> > Also, up to this point, if you're depending on Myfaces classes for
> > your custom components, it's difficult to know if you're depending on
> > API, IMPL, COMMONS, or TOMAHAWK pieces. This should make it far
> > clearer, and make it easier for developers in the long run.
> >
> > A separate commons release is also new enough that it shouldn't be too
> > big of an issue.
> >
> > The sooner we start doing things the "right" way, the sooner people
> > can feel safe about using commons to build their components.
> >
> > On 2/17/06, Manfred Geiler <[EMAIL PROTECTED]> wrote:
> > > Well it's a package refactoring. So, each dependend (or using) class
> > > in impl and tomahawk must be aligned as well. I'm feeling much warmer
> > > when doing this within my IDE, which has total knowledge of all
> > > dependencies. ;-)
> > >
> > > BTW, is everyone really aware of what I'm proposing here?
> > > We have an already released myfaces-commons-1.1.2 lib with package
> > > structure
> > > org.apache.myfaces.*
> > > The next myfaces-commons-1.1.3 will have package structure
> > > org.apache.myfaces.commons.*
> > > This is not what normally should happen between minor release changes,
> > > right?
> > > At least we must make prominent notice about this in commons 1.1.3
> > > release notes.
> > > Do you think there are already people out there, using myfaces-commons
> > > as base for there own components? They might be angry, no? ;-)
> > >
> > > Everyone really sure? Really no objections?
> > > :-)
> > >
> > > Manfred
> > >
> > >
> > > On 2/17/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
> > > > Just do the svn move manuall. Its not too hard.
> > > >
> > > > On 2/17/06, Arvid Hülsebus <[EMAIL PROTECTED]> wrote:
> > > > > It looks like he had only problems with older versions of IDEA or the
> > > > > Subversion client. We can't report any problems with IDEA 5.1.
> > > > >
> > > > > Regards,
> > > > > Arvid
> > > > >
> > > > > Martin Marinschek wrote:
> > > > > > +1 from me. definitely.
> > > > > >
> > > > > > regards,
> > > > > >
> > > > > > Martin
> > > > > >
> > > > > > On 2/17/06, Arvid Hülsebus <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > >> Normally it does, but there are some limitations. I will ask Udo
> > > > > >> when he
> > > > > >> is back -- in about 30 minutes. He gained some experience
> > > > > >> restructuring
> > > > > >> our repository for the donation of the Tobago source.
> > > > > >>
> > > > > >> Regards,
> > > > > >> Arvid
> > > > > >>
> > > > > >> Manfred Geiler wrote:
> > > > > >>
> > > > > >>>> pps. Use svn move to do this so we don't lose our history
> > > > > >>>>
> > > > > >>>>
> > > > > >>> Does anyone know if IntelliJ does "svn move" behind the scenes
> > > > > >>> when
> > > > > >>> moving (refactoring) classes?
> > > > > >>>
> > > > > >>> Thanks,
> > > > > >>> Manfred
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > http://www.irian.at
> > > > > >
> > > > > > Your JSF powerhouse -
> > > > > > JSF Consulting, Development and
> > > > > > Courses in English and German
> > > > > >
> > > > > > Professional Support for Apache MyFaces
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
