>> > in
>> >>> >>>> >> > myfaces-bundle).
>> >>> >>>> >> >
>> >>> >>>> >> > @Leo: From my point of view, the branch is complete. In
>> >>> >>>> >> >
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
>>> >>>> &g
gt; >>>> >>
>> >>>> >> >>>> >> Leo, SpringDM does much more work usually to tweak
>> >>>> >> >>>> >> something
>> >>>> >> >>>> >> for
>> >>>
gt; >> >
>>>> >> > 2011/7/8 Leonardo Uribe :
>>>> >> >> Hi Gerhard
>>>> >> >>
>>>> >> >> Ok, now that part has sense.
>>>> >> >>
>>>> >> >>
> >> Leonardo Uribe
>>> >> >>
>>> >> >> 2011/7/8 Gerhard Petracek :
>>> >> >>> hi leo,
>>> >> >>> right - there are no entries in the manifest. they will be
>>> >> >>> generated
>
ld
>> >> >>> config).
>> >> >>> regards,
>> >> >>> gerhard
>> >> >>> http://www.irian.at
>> >> >>>
>> >> >>> Your JSF powerhouse -
>> >> >>> JSF Consulting, Development and
&g
so, shouldn't we remove
>> >>>> OSGi entries on the manifests in myfaces-api and impl jars? just to
>> >>>> prevent possible confusions about that.
>> >>>>
>> >>>> regards,
>> >>>>
>> >>>&
gt;>
> >>>> 2011/7/8 Gerhard Petracek :
> >>>> > +1!
> >>>> > regards,
> >>>> > gerhard
> >>>> >
> >>>> > http://www.irian.at
> >>>> >
> >>>> > Your JSF powerh
; http://www.irian.at
>>>> >
>>>> > Your JSF powerhouse -
>>>> > JSF Consulting, Development and
>>>> > Courses in English and German
>>>> >
>>>> > Professional Support for Apache MyFaces
>>>>
> > regards,
>>> >> >
>>> >> > Leonardo Uribe
>>> >> >
>>> >> > 2011/7/8 Gerhard Petracek mailto:gerhard.petra...@gmail.com>>:
>>> >> > > hi mark,
>>> >
t;>> >
> >>> > Your JSF powerhouse -
> >>> > JSF Consulting, Development and
> >>> > Courses in English and German
> >>> >
> >>> > Professional Support for Apache MyFaces
> >>> >
> >>> >
>
re 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 _
ak 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
>>
t; >> 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
will be a big
>> benefit for cleaning up the shared project!
>>
>> LieGrue,
>> strub
>>
>> --- On Fri, 7/8/11, Leonardo Uribe wrote:
>>
>> > From: Leonardo Uribe
>> > Subject: Re: Use maven-shade-plugin to prevent duplicate code -
>> &
project!
>
> LieGrue,
> strub
>
> --- On Fri, 7/8/11, Leonardo Uribe wrote:
>
> > From: Leonardo Uribe
> > Subject: Re: Use maven-shade-plugin to prevent duplicate code - revisited
> > To: "MyFaces Development"
> > Date: Friday, July 8, 2011
fine and will be a big benefit for
cleaning up the shared project!
LieGrue,
strub
--- On Fri, 7/8/11, Leonardo Uribe wrote:
> From: Leonardo Uribe
> Subject: Re: Use maven-shade-plugin to prevent duplicate code - revisited
> To: "MyFaces Development"
> Date: Friday, July
y 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
from the
>> API package. This makes it pretty hard to work OSGi.
>>
>> LieGrue,
>> strub
>>
>> --- On Fri, 7/8/11, Jakob Korherr wrote:
>>
>> > From: Jakob Korherr
>> > Subject: Re: Use maven-shade-plugin to prevent duplicate code -
xt#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 wrote:
>
> > From: Jakob Korherr
> > Subject: Re: Use maven-shade-plugin to preven
makes it pretty hard to
work OSGi.
LieGrue,
strub
--- On Fri, 7/8/11, Jakob Korherr wrote:
> From: Jakob Korherr
> Subject: Re: Use maven-shade-plugin to prevent duplicate code - revisited
> To: "MyFaces Development"
> Date: Friday, July 8, 2011, 1:09 PM
> Hi Leo,
>
i agree with jakob.
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 Jakob Korherr
> Hi Leo,
>
> Yes, I remember that you did some work related to this stuff. Some
> com
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
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 a
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
> Hi guys,
>
> I committed a working draft to the branch at [1]. However, there ar
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.
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 c
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 configura
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 sha
Hi
2010/11/8 David Jencks
> If you don't need a "shaded" source jar, have you guys experimented with
> the bundle plugin for generating this jar?
>
>
I have never tried it. Maybe someone else? But in this case have a "shaded"
source jar could be important.
regards,
Leonardo Uribe
> thanks
>
If you don't need a "shaded" source jar, have you guys experimented with the
bundle plugin for generating this jar?
thanks
david jencks
On Nov 8, 2010, at 2:15 PM, Leonardo Uribe wrote:
> Hi
>
> No, I understand well, but maybe we are talking about many possible
> enhancements at the same tim
Hi
No, I understand well, but maybe we are talking about many possible
enhancements at the same time.
I know how shade plugin works, after all, I did the necessary changes to use
it on implee6. That's the reason why I know well the problems involved. I
tried
to use it in myfaces-test but the conc
Hi
Leo, you are getting this all wrong. Please take a look at the
shade-branch, which I created, and then we can continue this
discussion.
Thanks.
Regards,
Jakob
2010/11/8 Leonardo Uribe :
> Hi
>
> 2010/11/8 Gerhard
>>
>> hi,
>> i didn't talk about copying the code to the impl. module. it woul
Hi
2010/11/8 Gerhard
> hi,
>
> i didn't talk about copying the code to the impl. module. it would be a
> normal module (similar to the shared module) which gets shadded into the
> impl. module.
> actually both approaches are very similar. so you have the same advantages
> (compared to the shared
hi,
i didn't talk about copying the code to the impl. module. it would be a
normal module (similar to the shared module) which gets shadded into the
impl. module.
actually both approaches are very similar. so you have the same advantages
(compared to the shared module) and it's easier to handle du
Hi
2010/11/8 Gerhard
> again - i agree with jakob!
>
> such an >additional< all-in-one dist won't change the situation for osgi
> users. (for now) they just have to stick with the current jar files.
>
> @shared:
> the classes of the shared module would be in the impl. module, if we don’t
> (have
Hi
2010/11/8 Jakob Korherr
> Hi,
>
> IMHO shared code ist just as private as myfaces-impl code. Not more, not
> less.
>
>
Yes, in theory, but in practice that rule is not maintained. To keep
backward
compatibility we can't change the package of DelegateServlet (maybe just
add it with that packag
again - i agree with jakob!
such an >additional< all-in-one dist won't change the situation for osgi
users. (for now) they just have to stick with the current jar files.
@shared:
the classes of the shared module would be in the impl. module, if we don’t
(have to) share them with other myfaces sub
Hi,
IMHO shared code ist just as private as myfaces-impl code. Not more, not less.
Adding the all-in-one-jar is not a change, but an improvement. It is
just an additional (non-OSGi-ready) distribution form of MyFaces code
and thus does not affect the problems we're having with myfaces-shared
and
Hi
2010/11/8 Jakob Korherr
> 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 branc
i agree with jakob.
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 Jakob Korherr
> Hi,
>
> Last week I created a branch (see [1]) to test the shade module
> integrati
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 sh
Hi
2010/11/8 Gerhard
> 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 n
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.
@osgi:
if there are restrictions, we should improve the shade plugin.
(for now: osgi users just
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
wn
>>> module.
>>>
>>> This sounds easy but isn't always doable. But it might be worth
a try.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>> >
>>> >From: J
>>
> >> 2010/7/26 Mark Struberg
> >>>
> >>> I think you are both right. I can understand that copying code is
> really
> >>> ugly,
> >>> but otoh Leos argument is also pretty strong.
> >>>
> >>
otoh Leos argument is also pretty strong.
>>>
>>> There is a solution for this. Cut off the shared parts and move it into
>>> an own
>>> module.
>>>
>>> This sounds easy but isn't always doable. But it might be worth a try.
>>>
>>&
it into an own
> module.
>
> This sounds easy but isn't always doable. But it might be worth a try.
>
> LieGrue,
> strub
>
>
> >
> >From: Jakob Korherr
> >To: MyFaces Development
> >Sent: Mon, July 26, 2010 10:32:31 PM
> >Subject
> own
>> module.
>>
>> This sounds easy but isn't always doable. But it might be worth a try.
>>
>> LieGrue,
>> strub
>>
>>
>> >
>> >From: Jakob Korherr
>> >To: MyFaces Development
>> >Sent: Mon, July 26, 2010 10:32:31 PM
b Korherr
> >To: MyFaces Development
> >Sent: Mon, July 26, 2010 10:32:31 PM
> >Subject: Re: Use maven-shade-plugin to prevent duplicate code
> >
> >Why would you like to have any duplicate code? This should not be anyone's
> >target in my opinion...
> >
eGrue,
strub
>
>From: Jakob Korherr
>To: MyFaces Development
>Sent: Mon, July 26, 2010 10:32:31 PM
>Subject: Re: Use maven-shade-plugin to prevent duplicate code
>
>Why would you like to have any duplicate code? This should not be anyone's
>target in my opinion.
Hi
The code that is duplicated on myfaces-test is code that is used for
implement a mock object (in this case MockExternalContext). This code is
just some wrappers and it is not expected this will change in the future. So
the question is why bother us in this case? In this case use
maven-shade-plu
Why would you like to have any duplicate code? This should not be anyone's
target in my opinion...
2010/7/26 Leonardo Uribe
> Hi
>
> Yes, it is true, that myfaces-test is used for testing myfaces core, but in
> theory, myfaces-test should be used to test jsf stuff without rely on a
> specific j
Hi
Yes, it is true, that myfaces-test is used for testing myfaces core, but in
theory, myfaces-test should be used to test jsf stuff without rely on a
specific jsf implementation.
In this case I think (and it is my personal opinion) it is better to have
some duplicate code and keep things simple.
+1 for the maven shade plugin
I have used it quite extensively in ext-scripting works really well.
You just can bundle the classes or do a full namespace refactoring with
it on binary level.
Am 26.07.10 20:56, schrieb Jakob Korherr:
Hi guys,
Working on the tests for FlashImpl, I ran into a p
for sure i vote: +1!
(way more than just 10 :) )
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/7/26 Jakob Korherr
> Hehe, yeah I maybe forgot 10 "many".
>
> I can provide
Actually this already is the case: MyFaces-test is used for testing MyFaces
core.
Regards,
Jakob
2010/7/26 Rudy De Busscher
> Hi Jakob,
>
> So it was never the idea that MyFaces Test (and maybe the GSOC testing
> effort) will be used to supply the test infrastructure for MyFaces Core?
>
> In th
Hi Jakob,
So it was never the idea that MyFaces Test (and maybe the GSOC testing
effort) will be used to supply the test infrastructure for MyFaces Core?
In that case : MyFaces Core can supply code.
Regards
Rudy.
On 26 July 2010 22:01, Jakob Korherr wrote:
> Hi Rudy,
>
> Yes we totally have t
Hi Rudy,
Yes we totally have to be careful with circular dependencies, but it should
not be that big problem.
Actually I think that the opposite is true. MyFaces core is the JSF
implementation and MyFaces test provides the Mock classes for JSF, and for
implementing these Mock classes it can reuse
Hi all,
I agree, duplicated code has to be avoided and when the maven-shade-plugin
can help, the better.
but I think we have to define which project supplies code for which other
project (so that we don't get a spaghetti (using the tomatoes ;) or get
circular dependencies.). I know that MyFaces
On Mon, Jul 26, 2010 at 9:30 PM, Jakob Korherr wrote:
> Hehe, yeah I maybe forgot 10 "many".
>
> I can provide a wiki page for the general idea and the approach used on
> myfaces-test.
+1
> Then everyone can adopt this idea and see how it works.
great. I have that on my agenda as well, for Trin
Hehe, yeah I maybe forgot 10 "many".
I can provide a wiki page for the general idea and the approach used on
myfaces-test. Then everyone can adopt this idea and see how it works.
"RIP _shared? :)"
--> yes!
Regards,
Jakob
2010/7/26 Matthias Wessendorf
> On Mon, Jul 26, 2010 at 8:56 PM, Jakob K
On Mon, Jul 26, 2010 at 8:56 PM, Jakob Korherr wrote:
> Hi guys,
>
> Working on the tests for FlashImpl, I ran into a problem with the
> AbstractAttributeMap (MYFACES-2840). After fixing it, I needed to copy my
> changes over to myfaces-test to be able to use the new version in the test
> case (MY
Yes, this is one of my goals :)
2010/7/26 Jan-Kees van Andel
> If it helps to make Shared obsolete you have my +1! :-)
>
> /JK
>
>
> 2010/7/26 Jakob Korherr
>
> Hi guys,
>>
>> Working on the tests for FlashImpl, I ran into a problem with the
>> AbstractAttributeMap (MYFACES-2840). After fixing
If it helps to make Shared obsolete you have my +1! :-)
/JK
2010/7/26 Jakob Korherr
> Hi guys,
>
> Working on the tests for FlashImpl, I ran into a problem with the
> AbstractAttributeMap (MYFACES-2840). After fixing it, I needed to copy my
> changes over to myfaces-test to be able to use the
Hi guys,
Working on the tests for FlashImpl, I ran into a problem with the
AbstractAttributeMap (MYFACES-2840). After fixing it, I needed to copy my
changes over to myfaces-test to be able to use the new version in the test
case (MYFACESTEST-21). And this copying really sucks...
If you think abou
67 matches
Mail list logo
