myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
Subject Re: Use maven-shade-plugin to prevent duplicate code - revisited
Date Thu, 28 Jul 2011 00:21:18 GMT
Hi

Ok, it is done. Now core has a new module called shared and
shared-impl is gone. For checkout 2.0.x or 2.1.x (trunk), compile
shared 4.0.x or 4.1.x is no longer necessary, since all code is now on
2.0.x/2.1.x places. I'll do the additional adjustments on myfaces site
soon. The idea is redesign the site for be more user friendly.

regards,

Leonardo Uribe

2011/7/25 Leonardo Uribe <lu4242@gmail.com>:
> Hi
>
> If no objections I'll do the changes on 2.0.x and 2.1.x next Wednesday.
>
> regards,
>
> Leonardo Uribe
>
> 2011/7/24 Gerhard Petracek <gerhard.petracek@gmail.com>:
>> hi leo,
>> i made a short test and the usage looks fine.
>> furthermore, i had a quick look at the build files and besides the obvious
>> differences (which are required for your suggestion) i saw some details
>> which are different compared to the branch created by jakob.
>> if those differences are fine for everyone (esp. jakob and mark), we can use
>> this suggestion (at least for now) since it improves the current situation.
>> 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/23 Leonardo Uribe <lu4242@gmail.com>
>>>
>>> Hi
>>>
>>> To close this problem quickly (I'm getting tired of this issue, and I
>>> want to do some performance stuff on shared), I created a branch with
>>> the proposal for 2.1.x:
>>>
>>>
>>> http://svn.apache.org/repos/asf/myfaces/core/branches/refactor_shared_2_1_x/
>>>
>>> http://svn.apache.org/repos/asf/myfaces/shared/branches/refactor_shared_4_1_x/
>>>
>>> There you can see in practice what I'm saying. A profile was added on
>>> shared to sync code in a semi-automatic way. Just type mvn install
>>> -Dsynch-shared=true and then commit the changes. Now core has a new
>>> module and use shade plugin, but since all package names were renamed
>>> from shared to shared-impl, the confusion about packages is gone (and
>>> shared-impl too), and you can see the advantage of shade over unpack
>>> goal: the module is added as dependency on your pom. Only some
>>> selected classes were let on the same package to ensure backward
>>> compatibility.
>>>
>>> In all this refactoring, care must be taken to preserve svn history,
>>> doing the changes directly on svn repo instead copy and commit.
>>>
>>> If no objections, I'll do this refactor soon for 2.0.x / 2.1.x .
>>>
>>> The "spread" build idea for myfaces will be done after commit this code.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2011/7/13 Leonardo Uribe <lu4242@gmail.com>:
>>> > Hi
>>> >
>>> > I have checked the questions I had and here are the answers (You can
>>> > try it without any special setup, just mvn clean install and then mvn
>>> > site -Pgenerate-site):
>>> >
>>> > What happen with the site documentation?
>>> >
>>> > - javadoc report is not generated (????).
>>> > - x-ref report doesn't show shared code.
>>> > - JDepend and PMD reports doesn't take shared.
>>> >
>>> > All that is expected, because in practice we are "shading" shared.
>>> >
>>> > Isn't any problem with @JSFWebConfigParam?
>>> >
>>> > As I was expecting, the report doesn't take any init param on shared,
>>> > because those sources are not scanned anymore.
>>> >
>>> > How debugging looks with the proposed code?
>>> >
>>> > It works. You see org.apache.myfaces.shared instead
>>> > org.apache.myfaces.shared-impl, but the line breaks are ok. I seems
>>> > there was some fix on maven shade plugin related to this problem.
>>> >
>>> > What I see in this code is just use shade plugin instead unpack goal
>>> > for shared. But I have to say that the evidence is clear: unpack goal
>>> > fits better.
>>> >
>>> > But the main big problem is how to get rid of shared. First I have to
>>> > remember why we want so badly to get rid of it:
>>> >
>>> > 1. When there is an error there, you have to compile shared core,
>>> > shared-impl and myfaces core impl to reflect the change. If you are
>>> > debugging on a web app, you have to compile it too. In short this
>>> > means a lot of time waiting.
>>> > 2. When there is an error there, users get confused, because it is
>>> > another project.
>>> >
>>> > I think this alternative is possible
>>> >
>>> > 1. the base code on shared should live as a module on myfaces-core
>>> > project.
>>> > 2. shared project should do a hard copy of the code inside myfaces
>>> > core project. This means just sync the code from time to time and
>>> > release it. In this way projects like tomahawk or any other can
>>> > "shade" or "unpack" that code an use it.
>>> >
>>> > The next step is have a "spread" build of myfaces. This means have
>>> > some modules like this:
>>> >
>>> > api
>>> > shared
>>> > impl-base
>>> > impl-ee6
>>> > .....
>>> >
>>> > impl (the sum of shared + impl-base + impl-ee6 + ...)
>>> > bundle
>>> >
>>> > If shared is a module just like api or impl in myfaces folder, you can
>>> > setup a project that use api + all separate modules. In this way, if
>>> > there is an error on shared, you can compile just that module and your
>>> > web application and that's it!. Sounds almost obvious, isn't it?.
>>> >
>>> > Do this means change all package names on impl from shared-impl to
>>> > shared. Each module will have its own myfaces-metadata.xml, so builder
>>> > plugin will work correctly.
>>> >
>>> > Suggestions are welcome.
>>> >
>>> > regards,
>>> >
>>> > Leonardo Uribe
>>> >
>>> > 2011/7/11 Jakob Korherr <jakob.korherr@gmail.com>:
>>> >> Hi,
>>> >>
>>> >> I agree with Gerhard.
>>> >>
>>> >> Unfortunately I did not try a whole release + site build with the new
>>> >> configuration since you always do that, Leo. So please check on that
>>> >> as soon as possible for you.
>>> >>
>>> >> Regards,
>>> >> Jakob
>>> >>
>>> >> 2011/7/11 Gerhard Petracek <gerhard.petracek@gmail.com>:
>>> >>> hi leo,
>>> >>> actually we should talk about the priority.
>>> >>> imo it has a very high priority!
>>> >>> 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 Leonardo Uribe <lu4242@gmail.com>
>>> >>>>
>>> >>>> Hi Gerhard
>>> >>>>
>>> >>>> Does somebody reviewed if the site documentation is generated
>>> >>>> correctly? Isn't any problem with @JSFWebConfigParam? has anybody
>>> >>>> debugged something with the proposed code?. That's the unresolved
>>> >>>> questions I want to solve before apply it (I already mention that
>>> >>>> without response, right?), but if somebody can answer those questions
>>> >>>> could speed it up.
>>> >>>>
>>> >>>> I'm not asking for a loooooot of time. But note there are other
>>> >>>> issues
>>> >>>> right now ( improve error logging and exception handling,
>>> >>>> MYFACES-3216, fix #{component} refs and isRendered(), improve site
>>> >>>> documentation ), that takes priority over this one.
>>> >>>>
>>> >>>> regards,
>>> >>>>
>>> >>>> Leonardo Uribe
>>> >>>>
>>> >>>> 2011/7/11 Gerhard Petracek <gerhard.petracek@gmail.com>:
>>> >>>> > hi leo,
>>> >>>> > right now i don't see a reason why it should take a lot of time. in
>>> >>>> > the
>>> >>>> > end
>>> >>>> > you just have to look at the resulting artifacts.
>>> >>>> > the javadoc plugin is no blocker (if there is no official release,
>>> >>>> > we
>>> >>>> > can do
>>> >>>> > an external release. as soon as there is an official release of it,
>>> >>>> > we
>>> >>>> > can
>>> >>>> > switch back to it).
>>> >>>> > please provide a bit more information about the "other issues".
>>> >>>> > 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 Leonardo Uribe <lu4242@gmail.com>
>>> >>>> >>
>>> >>>> >> Hi
>>> >>>> >>
>>> >>>> >> Please don't commit the changes until I do a final review. That
>>> >>>> >> will
>>> >>>> >> take some time, so please be patient, there are other issues on
>>> >>>> >> core
>>> >>>> >> right now that we need to solve too. Anyway we can't commit the
>>> >>>> >> code
>>> >>>> >> without a release of javadoc plugin.
>>> >>>> >>
>>> >>>> >> regards,
>>> >>>> >>
>>> >>>> >> Leonardo Uribe
>>> >>>> >>
>>> >>>> >> 2011/7/11 Jakob Korherr <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>:
>>> >>>> >> >> 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>:
>>> >>>> >> >>> 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>
>>> >>>> >> >>>>
>>> >>>> >> >>>> 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>:
>>> >>>> >> >>>> > +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>
>>> >>>> >> >>>> >>
>>> >>>> >> >>>> >> 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>
>>> >>>> >> >>>> >> wrote:
>>> >>>> >> >>>> >>
>>> >>>> >> >>>> >> > From: Leonardo Uribe <lu4242@gmail.com>
>>> >>>> >> >>>> >> > Subject: Re: Use maven-shade-plugin to prevent duplicate
>>> >>>> >> >>>> >> > code
>>> >>>> >> >>>> >> > -
>>> >>>> >> >>>> >> > revisited
>>> >>>> >> >>>> >> > To: "MyFaces Development" <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>:
>>> >>>> >> >>>> >> > > 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>
>>> >>>> >> >>>> >> > >>
>>> >>>> >> >>>> >> > >> 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>
>>> >>>> >> >>>> >> > wrote:
>>> >>>> >> >>>> >> > >>
>>> >>>> >> >>>> >> > >> > From: Jakob Korherr <jakob.korherr@gmail.com>
>>> >>>> >> >>>> >> > >> > Subject: Re: Use maven-shade-plugin to
>>> >>>> >> >>>> >> > prevent duplicate code -
>>> >>>> >> >>>> >> > >> > revisited
>>> >>>> >> >>>> >> > >> > To: "MyFaces Development" <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>:
>>> >>>> >> >>>> >> > >> > > 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>:
>>> >>>> >> >>>> >> > >> > >> 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>
>>> >>>> >> >>>> >> > >> > >>>
>>> >>>> >> >>>> >> > >> > >>> 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>:
>>> >>>> >> >>>> >> > >> > >>> > 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>:
>>> >>>> >> >>>> >> > >> > >>> >>>
>>> >>>> >> >>>> >> > >> > >>> >>> 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
>>> >>>> >> >
>>> >>>> >
>>> >>>> >
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Jakob Korherr
>>> >>
>>> >> blog: http://www.jakobk.com
>>> >> twitter: http://twitter.com/jakobkorherr
>>> >> work: http://www.irian.at
>>> >>
>>> >
>>
>>
>

Mime
View raw message