myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Punz <werner.p...@gmail.com>
Subject Re: Use maven-shade-plugin to prevent duplicate code - revisited
Date Mon, 11 Jul 2011 09:42:01 GMT
+1

Am 11.07.11 11:39, schrieb Gerhard Petracek:
> 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 <jakob.korherr@gmail.com
> <mailto:jakob.korherr@gmail.com>>
>
>     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 <lu4242@gmail.com <mailto:lu4242@gmail.com>>:
>      > 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 <gerhard.petracek@gmail.com
>     <mailto:gerhard.petracek@gmail.com>>:
>      >> 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 <lu4242@gmail.com <mailto:lu4242@gmail.com>>
>      >>>
>      >>> 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 <gerhard.petracek@gmail.com
>     <mailto:gerhard.petracek@gmail.com>>:
>      >>> > +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 <struberg@yahoo.de
>     <mailto:struberg@yahoo.de>>
>      >>> >>
>      >>> >> 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 <lu4242@gmail.com
>     <mailto:lu4242@gmail.com>> wrote:
>      >>> >>
>      >>> >> > From: Leonardo Uribe <lu4242@gmail.com
>     <mailto:lu4242@gmail.com>>
>      >>> >> > Subject: Re: Use maven-shade-plugin to prevent duplicate
>     code -
>      >>> >> > revisited
>      >>> >> > To: "MyFaces Development" <dev@myfaces.apache.org
>     <mailto:dev@myfaces.apache.org>>
>      >>> >> > 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 <gerhard.petracek@gmail.com
>     <mailto:gerhard.petracek@gmail.com>>:
>      >>> >> > > 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 <struberg@yahoo.de
>     <mailto:struberg@yahoo.de>>
>      >>> >> > >>
>      >>> >> > >> 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
>     <jakob.korherr@gmail.com <mailto:jakob.korherr@gmail.com>>
>      >>> >> > wrote:
>      >>> >> > >>
>      >>> >> > >> > From: Jakob Korherr <jakob.korherr@gmail.com
>     <mailto:jakob.korherr@gmail.com>>
>      >>> >> > >> > Subject: Re: Use maven-shade-plugin to
>      >>> >> > prevent duplicate code -
>      >>> >> > >> > revisited
>      >>> >> > >> > To: "MyFaces Development" <dev@myfaces.apache.org
>     <mailto:dev@myfaces.apache.org>>
>      >>> >> > >> > 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 <lu4242@gmail.com
>     <mailto:lu4242@gmail.com>>:
>      >>> >> > >> > > 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
>     <gerhard.petracek@gmail.com <mailto:gerhard.petracek@gmail.com>>:
>      >>> >> > >> > >> 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 <jakob.korherr@gmail.com
>     <mailto:jakob.korherr@gmail.com>>
>      >>> >> > >> > >>>
>      >>> >> > >> > >>> 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 <werner.punz@gmail.com
>     <mailto:werner.punz@gmail.com>>:
>      >>> >> > >> > >>> > 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<gerhard.petracek@gmail.com
>     <mailto:gerhard.petracek@gmail.com>>:
>      >>> >> > >> > >>> >>>
>      >>> >> > >> > >>> >>> 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
>
>



Mime
View raw message