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
Date Mon, 08 Nov 2010 19:46:06 GMT
Hi

2010/11/8 Jakob Korherr <jakob.korherr@gmail.com>

> Hi,
>
> Last week I created a branch (see [1]) to test the shade module
> integration of shared and also implee6 for MyFaces core.
> Coincidentally, Leonardo committed a similar solution to MyFaces core
> trunk, however only for the implee6 integration.
>
> The branch at [1] uses the shade plugin to include shared and implee6.
> For shared it uses a dependency to myfaces-shared-core (NOT
> shared-impl), which will then be shaded to org.apache.myfaces.*
> (without the shared-package) - however this is only a prototype. To
> make this work I had to rename all imports in myfaces-impl from
> "shared_impl" to "shared". Everything works pretty well expect for the
> OSGi-issues mentioned by Leonardo.
>
> Using this branch you are able to work on MyFaces shared classes in
> the context of MyFaces core and not having to do a whole maven build
> when testing it, because your IDE uses shared directly as a
> dependency. Thus it really is an improvement to what we have now and
> we should try to fix the OSGi issues in some way to really make this
> work. I already did some work in this direction and I think that a
> ResourceTransformer implementation for shade that creates the Manifest
> file for OSGi is the way to go, but we certainly have to discuss this
> (maybe also with the bundle-plugin team). WDYT Leo?
>
>
Well, before try to do something like that (a ResourceTransformer
implementation)
it is good to ask if it is really necessary to do that. On a previous mail I
said that
"shared" code should be private, so there should not be used for users
outside
myfaces impl. There are exceptions (DelegateServlet), so we have to identify
first
which code could not be relocated. The effect on maven bundle plugin is
shared packages are excluded from Export-Package header, but as long as
users
don't have code importing shared_impl package it is ok to ignore this side
effect.


> However, please take a look at the branch at [1] and try to use it in
> your IDE - I think it's really great! (... and furthermore I think
> it's much easier to understand for every myfaces-developer).
>
>
> I also totally agree with Gerhard that we should provide this
> all-in-one jar, even if it may cause problems in OSGi, because our
> OSGi users will most certainly know that. It's really easy to do this
> using the shade plugin and it provides a very convenient way for
> developers to use MyFaces (especially when they're not using maven).
> As Gerhard mentioned, Mojarra will do the same and furthermore other
> projects like e.g. Weld also provide this all-in-one solution (-->
> weld-servlet).
>
>
I disagree. Our first priority should be myfaces usage in different
environments,
and then enhance IDE support. Only if the two previous objections can be
solved,
the change can be made.

regards,

Leonardo Uribe


> Regards,
> Jakob
>
> [1]
> http://svn.apache.org/repos/asf/myfaces/core/branches/2_0_3_snapshot_shade_test/
>
> 2010/11/8 Leonardo Uribe <lu4242@gmail.com>:
> > Hi
> >
> > 2010/11/8 Gerhard <gerhard.petracek@gmail.com>
> >>
> >> hi,
> >> @ide-support:
> >> since you get an additional all-in-one sources jar file, it should work.
> >> i've created external codi examples which use the all-in-one jar of codi
> >> and the ide support works perfectly.
> >
> > Yes, that's true (I checked that code) but in shared you need to change
> the
> > package name to org.apache.myfaces.shared_impl.
> >
> > Really that package renaming is questionable. Why? It exists since 1.1.x
> but
> > I don't know why this is necessary. In theory, the code inside shared
> should
> > be "private", but the truth is we have one class that could be consumed
> by
> > users:
> org.apache.myfaces.shared_impl.webapp.webxml.DelegatedFacesServlet.
> > That is the main reason why I moved the code proposed on
> > https://issues.apache.org/jira/browse/MYFACES-2944 to myfaces-impl
> package.
> >
> >>
> >> @osgi:
> >> if there are restrictions, we should improve the shade plugin.
> >> (for now: osgi users just can't use this optional all-in-one jar file -
> if
> >> we document it, it shouldn't be a problem.)
> >
> > There is a discussion of this issue here:
> >
> > https://issues.apache.org/jira/browse/FELIX-1184
> >
> > It was reported here too:
> >
> > http://jira.codehaus.org/browse/MSHADE-51
> >
> > The issue in maven is here:
> >
> > http://jira.codehaus.org/browse/MNG-2258
> >
> > Unfortunately, the only hack I can see to make this work correctly is
> create
> > a plugin with a maven lifecycle extension, and do that is very nasty,
> > because we need to create a plugin just to do that.
> >
> >>
> >> @use-case:
> >> we should really get rid of the shared module.
> >
> > I agree. First we need a more explicit plan to do it. Suggestions are
> > welcome.
> >
> > regards,
> >
> > Leonardo Uribe
> >
> >>
> >> regards,
> >> gerhard
> >> http://www.irian.at
> >>
> >> Your JSF powerhouse -
> >> JSF Consulting, Development and
> >> Courses in English and German
> >>
> >> Professional Support for Apache MyFaces
> >>
> >>
> >>
> >> 2010/11/8 Leonardo Uribe <lu4242@gmail.com>
> >>>
> >>> Hi
> >>>
> >>> Unfortunately, maven-shade-plugin has some unwanted side effects.
> >>>
> >>> - The source jar file is not updated too, so if we "shade" shared, the
> >>> sources are not updated. In theory, the source jar is used by IDEs like
> >>> Eclipse or Netbeans to show the source file of a .class.
> >>> - It does not play well with osgi bundle plugin (the one that create
> >>> manifest.mf). The problem is the manifest is generated before "shade",
> and
> >>> we need the later. Really that one is a problem related to maven
> itself.
> >>>
> >>> The only valid use case I found where maven-shade-plugin fits well is
> >>> with implee6 module, but anyway it was required to do some hacks to
> make
> >>> bundle plugin works well.
> >>>
> >>> regards,
> >>>
> >>> Leonardo Uribe
> >>
> >
> >
>
>
>
> --
> Jakob Korherr
>
> blog: http://www.jakobk.com
> twitter: http://twitter.com/jakobkorherr
> work: http://www.irian.at
>

Mime
View raw message