great! thx jakob & mark!
+1!
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/7/11 Jakob Korherr <[email protected]
<mailto:[email protected]>>
Hi,
> right - there are no entries in the manifest. they will be
generated for the separated osgi bundle/s during the build (based on
the build config).
Jep! That was the idea in the first place (look at the branch and
you'll see no bundle plugin in myfaces-api or myfaces-impl, but in
myfaces-bundle).
@Leo: From my point of view, the branch is complete. In addition, Mark
committed my patch for MJAVADOC-320, thus the javadoc generation does
already work too (if you use the latest 2.8.1-SNAPSHOT of the
javadoc-plugin).
Here is a short summary of the proposed changes:
- remove felix bundle plugin executions from myfaces-api and
myfaces-impl (we have myfaces-bundle for OSGi).
- use maven-shade-plugin with package relocation (shared to
shared_impl) in myfaces-impl instead of
a) ant-task to rename source from shared to shared_impl
(myfaces-shared-impl project)
b) dependency plugin to unpack shared-impl-sources.jar in
myfaces-impl and build-helper-plugin to add these sources as a new
source folder
- use maven-javadoc-plugin with includeSourceDependencies=true for
shared (and impl-ee6) in order to include the javadocs of shared in
the myfaces-impl javadocs
These changes have the following implications:
- all imports of myfaces-shared code in myfaces-impl will go to
org.apache.myfaces.shared.* instead of
org.apache.myfaces.shared_impl.*, because relocation is done on
class-file-basis instead of source-file-basis.
- myfaces-shared-core will be a direct dependency of myfaces-impl at
development time, thus enabling hot-deployments,... when changing
stuff in shared at development time.
- myfaces-shared-impl project will be obsolete (b/c - as already
mentioned - myfaces-impl uses shared-core instead of shared-impl).
If there are no objections, I will merge in the changes from the
branch soon!
Regards,
Jakob
2011/7/8 Leonardo Uribe <[email protected] <mailto:[email protected]>>:
> Hi Gerhard
>
> Ok, now that part has sense.
>
> There are still some things to check before apply the change. Please
> let me know when all code is on the branch and I'll do a final
in-deep
> check.
>
> regards,
>
> Leonardo Uribe
>
> 2011/7/8 Gerhard Petracek <[email protected]
<mailto:[email protected]>>:
>> hi leo,
>> right - there are no entries in the manifest. they will be
generated for the
>> separated osgi bundle/s during the build (based on the build
config).
>> regards,
>> gerhard
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>>
>>
>> 2011/7/8 Leonardo Uribe <[email protected] <mailto:[email protected]>>
>>>
>>> Hi
>>>
>>> Ok, I agree it is not a problem, but if that so, shouldn't we
remove
>>> OSGi entries on the manifests in myfaces-api and impl jars? just to
>>> prevent possible confusions about that.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2011/7/8 Gerhard Petracek <[email protected]
<mailto:[email protected]>>:
>>> > +1!
>>> > regards,
>>> > gerhard
>>> >
>>> > http://www.irian.at
>>> >
>>> > Your JSF powerhouse -
>>> > JSF Consulting, Development and
>>> > Courses in English and German
>>> >
>>> > Professional Support for Apache MyFaces
>>> >
>>> >
>>> >
>>> > 2011/7/8 Mark Struberg <[email protected]
<mailto:[email protected]>>
>>> >>
>>> >> Leo, SpringDM does much more work usually to tweak something
for their
>>> >> needs!
>>> >> They can just use the myfaces-bundle.jar as each and every
other OSGi
>>> >> user
>>> >> does too.
>>> >>
>>> >> What I meant was more: we shall _not_ do something ugly just
to make
>>> >> OSGi
>>> >> happy ^^
>>> >>
>>> >> So using the maven-shade-plugin is perfectly fine and will
be a big
>>> >> benefit for cleaning up the shared project!
>>> >>
>>> >> LieGrue,
>>> >> strub
>>> >>
>>> >> --- On Fri, 7/8/11, Leonardo Uribe <[email protected]
<mailto:[email protected]>> wrote:
>>> >>
>>> >> > From: Leonardo Uribe <[email protected]
<mailto:[email protected]>>
>>> >> > Subject: Re: Use maven-shade-plugin to prevent duplicate
code -
>>> >> > revisited
>>> >> > To: "MyFaces Development" <[email protected]
<mailto:[email protected]>>
>>> >> > Date: Friday, July 8, 2011, 3:20 PM
>>> >> > Hi
>>> >> >
>>> >> > I don't think the OSGi mention is off-topic. In theory it
>>> >> > is possible
>>> >> > to setup myfaces-api and myfaces-impl jars in a OSGi
>>> >> > container using
>>> >> > SpringDM. The changes proposed just prevents that possible
>>> >> > setup to
>>> >> > work, but that one was the first known successful
>>> >> > environment to use.
>>> >> > Note in this case the are no problems with FactoryFinder,
>>> >> > because
>>> >> > Spring DM provide a thread context classloader (TCCL) that
>>> >> > fix that.
>>> >> >
>>> >> > The changes proposed impose the restriction that anyone who
>>> >> > wants to
>>> >> > use OSGi should use myfaces-bundle jar instead. But from
>>> >> > other point
>>> >> > of view it is clear that in such environment users could
>>> >> > want to use
>>> >> > mojarra api and myfaces impl, even if that is not really
>>> >> > possible.
>>> >> >
>>> >> > Note the previous arguments are questionable of course,
>>> >> > because in
>>> >> > practice people will use myfaces-bundle jar, keeping things
>>> >> > simple
>>> >> > because you have to deal only with one bundle. So it does
>>> >> > not suppose
>>> >> > a problem, just a "side effect" to keep in mind.
>>> >> >
>>> >> > I think it is required to specify in more details which are
>>> >> > the "side
>>> >> > effects" of the changes proposed. Note on a previous mail i
>>> >> > said "...
>>> >> > I haven't look the code provided in deep ...", but I guess
>>> >> > the patch
>>> >> > proposed will prevent @JSFWebConfigParam annotations to be
>>> >> > scanned for
>>> >> > myfaces builder plugin and consequently break this
>>> >> > generated site
>>> >> > page:
>>> >> >
>>> >> > http://myfaces.apache.org/core20/myfaces-impl/webconfig.html
>>> >> > http://myfaces.apache.org/core21/myfaces-impl/webconfig.html
>>> >> >
>>> >> > I don't see very clear the "benefits" of the change. I
>>> >> > suppose it
>>> >> > enhance debugging in some way, but is that true? can I do a
>>> >> > change on
>>> >> > shared, and do not have to recompile to see the change? If
>>> >> > I set a
>>> >> > break point on shared-core, the debugger will stop there? I
>>> >> > would like
>>> >> > to see a strong (and maybe heavier and tedious but
>>> >> > necessary)
>>> >> > argumentation before do the change.
>>> >> >
>>> >> > regards,
>>> >> >
>>> >> > Leonardo Uribe
>>> >> >
>>> >> > 2011/7/8 Gerhard Petracek <[email protected]
<mailto:[email protected]>>:
>>> >> > > hi mark,
>>> >> > > that's a bit off-topic ;) we already (have to) provide
>>> >> > osgi bundles. we just
>>> >> > > continue to do the same with the shade-plugin.
>>> >> > > regards,
>>> >> > > gerhard
>>> >> > >
>>> >> > > http://www.irian.at
>>> >> > >
>>> >> > > Your JSF powerhouse -
>>> >> > > JSF Consulting, Development and
>>> >> > > Courses in English and German
>>> >> > >
>>> >> > > Professional Support for Apache MyFaces
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > > 2011/7/8 Mark Struberg <[email protected]
<mailto:[email protected]>>
>>> >> > >>
>>> >> > >> Hi folks!
>>> >> > >>
>>> >> > >> There are 2 problems with JSF under OSGi
>>> >> > >>
>>> >> > >> a) OSGi is in reality a _big_ mess and not really
>>> >> > worth the troubles ;)
>>> >> > >> It _should_ make it possible to elegantly switch
>>> >> > implementations, but in
>>> >> > >> practice you need to import/export all packages
>>> >> > explicitly, even those which
>>> >> > >> are only used indirectly.
>>> >> > >>
>>> >> > >> b) the design of the JSF-api could be more clear
>>> >> > with separation (hey,
>>> >> > >> it's 10 years old!). It is not possible to use a
>>> >> > MyFaces-impl with a
>>> >> > >> mojarra-api and vice versa, because methods like
>>> >> > >> FacesContext#getCurrentInstance() (and similar)
>>> >> > access impl classes from the
>>> >> > >> API package. This makes it pretty hard to work
>>> >> > OSGi.
>>> >> > >>
>>> >> > >> LieGrue,
>>> >> > >> strub
>>> >> > >>
>>> >> > >> --- On Fri, 7/8/11, Jakob Korherr
<[email protected] <mailto:[email protected]>>
>>> >> > wrote:
>>> >> > >>
>>> >> > >> > From: Jakob Korherr <[email protected]
<mailto:[email protected]>>
>>> >> > >> > Subject: Re: Use maven-shade-plugin to
>>> >> > prevent duplicate code -
>>> >> > >> > revisited
>>> >> > >> > To: "MyFaces Development" <[email protected]
<mailto:[email protected]>>
>>> >> > >> > Date: Friday, July 8, 2011, 1:09 PM
>>> >> > >> > Hi Leo,
>>> >> > >> >
>>> >> > >> > Yes, I remember that you did some work
>>> >> > related to this
>>> >> > >> > stuff. Some
>>> >> > >> > comments about your problems:
>>> >> > >> >
>>> >> > >> > 1) If you use myfaces-impl, the packages
>>> >> > really are
>>> >> > >> > *.shared_impl.*
>>> >> > >> > (shade does the relocation on the classes).
>>> >> > But a part of
>>> >> > >> > this
>>> >> > >> > statement is still true - we need to check
>>> >> > config files
>>> >> > >> > with
>>> >> > >> > references to shared and shared_impl.
>>> >> > >> >
>>> >> > >> > 2) That's not true. We solved this problem in
>>> >> > CODI, as
>>> >> > >> > described.
>>> >> > >> > Please take a look at the code ;)
>>> >> > >> >
>>> >> > >> > 3) We don't need to execute felix bundle
>>> >> > plugin directly
>>> >> > >> > in
>>> >> > >> > myfaces-impl, b/c it won't work in an OSGi
>>> >> > environment
>>> >> > >> > anyway (see
>>> >> > >> > e.g. FactoryFinder problems). We have
>>> >> > myfaces-bundle for
>>> >> > >> > this matter!
>>> >> > >> >
>>> >> > >> > Regards,
>>> >> > >> > Jakob
>>> >> > >> >
>>> >> > >> > 2011/7/7 Leonardo Uribe <[email protected]
<mailto:[email protected]>>:
>>> >> > >> > > Hi
>>> >> > >> > >
>>> >> > >> > > I haven't look the code provided in
>>> >> > deep, but long
>>> >> > >> > time ago I tried
>>> >> > >> > > it. In that time I saw the following
>>> >> > problems:
>>> >> > >> > >
>>> >> > >> > > 1. There are some classes on shared that
>>> >> > are used
>>> >> > >> > outside it. For
>>> >> > >> > > example, see
>>> >> > >> >
>>> >> > org.apache.myfaces.shared.webapp.webxml.DelegatedFacesServlet.
>>> >> > >> > > We need to detect all similar cases and
>>> >> > move those
>>> >> > >> > classes to
>>> >> > >> > > myfaces-impl, but renaming shared with
>>> >> > shared-impl, or
>>> >> > >> > just create
>>> >> > >> > > classes that extends from the ones in
>>> >> > shared, to
>>> >> > >> > preserve backward
>>> >> > >> > > behavior. In theory, the affected
>>> >> > packages are:
>>> >> > >> > >
>>> >> > >> > >
>>> >> > org.apache.myfaces.shared_impl.webapp.webxml
>>> >> > >> > >
>>> >> > org.apache.myfaces.shared_impl.taglib
>>> >> > >> > >
>>> >> > org.apache.myfaces.shared_impl.taglib.core
>>> >> > >> > >
>>> >> > >> > > 2. Generated artifacts (-sources.jar,
>>> >> > -javadoc.jar)
>>> >> > >> > has problems. It
>>> >> > >> > > is clear javadoc and source jars will
>>> >> > not have
>>> >> > >> > shared-impl.
>>> >> > >> > > 3. shade plugin and felix maven bundle
>>> >> > plugin does not
>>> >> > >> > play well. By
>>> >> > >> > > default bundle plugin is executed before
>>> >> > shade plugin,
>>> >> > >> > but what you
>>> >> > >> > > want is the opposite, so the information
>>> >> > on
>>> >> > >> > MANIFEST.MF could be
>>> >> > >> > > generated taking into account all
>>> >> > classes. Note if we
>>> >> > >> > solve 1, this
>>> >> > >> > > should not be a problem, because classes
>>> >> > inside shared
>>> >> > >> > are myfaces
>>> >> > >> > > internals (remember why spi interfaces
>>> >> > are on impl
>>> >> > >> > package and not in
>>> >> > >> > > shared).
>>> >> > >> > >
>>> >> > >> > > I'll keep an eye on the resulting work.
>>> >> > >> > >
>>> >> > >> > > regards,
>>> >> > >> > >
>>> >> > >> > > Leonardo Uribe
>>> >> > >> > >
>>> >> > >> > > 2011/7/7 Gerhard Petracek
<[email protected] <mailto:[email protected]>>:
>>> >> > >> > >> hi jakob,
>>> >> > >> > >> great - thx!
>>> >> > >> > >> regards,
>>> >> > >> > >> gerhard
>>> >> > >> > >>
>>> >> > >> > >> http://www.irian.at
>>> >> > >> > >>
>>> >> > >> > >> Your JSF powerhouse -
>>> >> > >> > >> JSF Consulting, Development and
>>> >> > >> > >> Courses in English and German
>>> >> > >> > >>
>>> >> > >> > >> Professional Support for Apache
>>> >> > MyFaces
>>> >> > >> > >>
>>> >> > >> > >>
>>> >> > >> > >>
>>> >> > >> > >> 2011/7/7 Jakob Korherr <[email protected]
<mailto:[email protected]>>
>>> >> > >> > >>>
>>> >> > >> > >>> Hi guys,
>>> >> > >> > >>>
>>> >> > >> > >>> I committed a working draft to
>>> >> > the branch at
>>> >> > >> > [1]. However, there are
>>> >> > >> > >>> some issues with the
>>> >> > javadoc-plugin (see [2])
>>> >> > >> > that must be fixed first
>>> >> > >> > >>> in order to get the expected
>>> >> > javadoc. The
>>> >> > >> > other stuff (shading of
>>> >> > >> > >>> shared and impl-ee6) already
>>> >> > works as
>>> >> > >> > expected!
>>> >> > >> > >>>
>>> >> > >> > >>> Feel free to try it out
>>> >> > yourself. Comments and
>>> >> > >> > suggestions are welcome!
>>> >> > >> > >>>
>>> >> > >> > >>> Regards,
>>> >> > >> > >>> Jakob
>>> >> > >> > >>>
>>> >> > >> > >>> [1]
>>> >> > >> > >>>
>>> >> > >> > >>>
>>> >> > >> > >>>
>>> >> > >> > >>>
https://svn.apache.org/repos/asf/myfaces/core/branches/2.0.8_shade_prototype/
>>> >> > >> > >>> [2] https://jira.codehaus.org/browse/MJAVADOC-320
>>> >> > >> > >>>
>>> >> > >> > >>> 2011/7/7 Werner Punz <[email protected]
<mailto:[email protected]>>:
>>> >> > >> > >>> > Excellent news ++1, the
>>> >> > shared as we have
>>> >> > >> > it is a bad design decision I
>>> >> > >> > >>> > hope
>>> >> > >> > >>> > shade will get rid of our
>>> >> > debugging
>>> >> > >> > issues we have with our current
>>> >> > >> > >>> > shared.
>>> >> > >> > >>> >
>>> >> > >> > >>> >
>>> >> > >> > >>> > Werner
>>> >> > >> > >>> >
>>> >> > >> > >>> >
>>> >> > >> > >>> > Am 07.07.11 11:04, schrieb
>>> >> > Jakob
>>> >> > >> > Korherr:
>>> >> > >> > >>> >>
>>> >> > >> > >>> >> Hi Gerhard,
>>> >> > >> > >>> >>
>>> >> > >> > >>> >> Thx for (re-)opening
>>> >> > this thread. I
>>> >> > >> > already created a jira issue [1]
>>> >> > >> > >>> >> and a core-branch [2]
>>> >> > for
>>> >> > >> > prototyping.
>>> >> > >> > >>> >>
>>> >> > >> > >>> >> Currently I am
>>> >> > struggling a little
>>> >> > >> > bit with the javadoc-plugin, but
>>> >> > >> > >>> >> this stuff should be
>>> >> > fixed soon
>>> >> > >> > (maybe even today).
>>> >> > >> > >>> >>
>>> >> > >> > >>> >> I'll let you guys know
>>> >> > when I am done
>>> >> > >> > with the configuration, so that
>>> >> > >> > >>> >> you can try it out
>>> >> > yourselves!
>>> >> > >> > >>> >>
>>> >> > >> > >>> >> Regards,
>>> >> > >> > >>> >> Jakob
>>> >> > >> > >>> >>
>>> >> > >> > >>> >> [1]
https://issues.apache.org/jira/browse/MYFACES-3205
>>> >> > >> > >>> >> [2]
>>> >> > >> > >>> >>
>>> >> > >> > >>> >>
>>> >> > >> > >>> >>
>>> >> > >> > >>> >>
>>> >> > >> > >>> >>
https://svn.apache.org/repos/asf/myfaces/core/branches/2.0.8_shade_prototype/
>>> >> > >> > >>> >>
>>> >> > >> > >>> >> 2011/7/7 Gerhard
>>> >> > Petracek<[email protected]
<mailto:[email protected]>>:
>>> >> > >> > >>> >>>
>>> >> > >> > >>> >>> hi @ all,
>>> >> > >> > >>> >>> the goal (as we
>>> >> > discussed before)
>>> >> > >> > is to get rid of the shared-impl
>>> >> > >> > >>> >>> module
>>> >> > >> > >>> >>> and move to the
>>> >> > shade-plugin for
>>> >> > >> > maven.
>>> >> > >> > >>> >>> issues with javadoc
>>> >> > and osgi
>>> >> > >> > bundles prevented us from doing this
>>> >> > >> > >>> >>> step.
>>> >> > >> > >>> >>> however, with codi
>>> >> > v1 we have a
>>> >> > >> > project(-configuration) which fixes
>>> >> > >> > >>> >>> all
>>> >> > >> > >>> >>> the
>>> >> > >> > >>> >>> issues we had with
>>> >> > the
>>> >> > >> > shade-plugin.
>>> >> > >> > >>> >>> -> imo we can
>>> >> > (and should)
>>> >> > >> > use it also for myfaces-core.
>>> >> > >> > >>> >>> regards,
>>> >> > >> > >>> >>> gerhard
>>> >> > >> > >>> >>
>>> >> > >> > >>> >>
>>> >> > >> > >>> >>
>>> >> > >> > >>> >
>>> >> > >> > >>> >
>>> >> > >> > >>> >
>>> >> > >> > >>>
>>> >> > >> > >>>
>>> >> > >> > >>>
>>> >> > >> > >>> --
>>> >> > >> > >>> Jakob Korherr
>>> >> > >> > >>>
>>> >> > >> > >>> blog: http://www.jakobk.com
>>> >> > >> > >>> twitter: http://twitter.com/jakobkorherr
>>> >> > >> > >>> work: http://www.irian.at
>>> >> > >> > >>
>>> >> > >> > >>
>>> >> > >> > >
>>> >> > >> >
>>> >> > >> >
>>> >> > >> >
>>> >> > >> > --
>>> >> > >> > Jakob Korherr
>>> >> > >> >
>>> >> > >> > blog: http://www.jakobk.com
>>> >> > >> > twitter: http://twitter.com/jakobkorherr
>>> >> > >> > work: http://www.irian.at
>>> >> > >> >
>>> >> > >
>>> >> > >
>>> >> >
>>> >
>>> >
>>
>>
>
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
