Re: [proposal] myfaces-core.jar
2005/11/30, Sean Schofield [EMAIL PROTECTED]: I wanted to resurrect one of our favorite threads ... Should the shared code be in its own jar? The reason why I bring this up now is that I'm starting to experiment with an M2 build for MyFaces. In addition to some of the arguments made earlier we can now add Maven to the list of reasons why we might want to consider this. From my early exploration of Maven it seems like the shared stuff can be handled best by making the impl and tomahawk subprojects have a dependency on the share project. In the past I have not been too wild about the shared jar idea but I think Maven may be able to help keep us and our users informed as to the exact dependencies when using MyFaces or Tomahawk. First off, I would suggest we call it *core* instead of share. I think core helps to imply that it is mandatory. They already know they need api and impl (if they have read the JSF spec.) The core wording will let them know they need this also. Maven has some cool stuff for maintaining and documenting dependencies. The tomahawk page of the website can automatically be updated so that for each new release of tomahawk, the dependency list will be updated. Its also possible that we can have tomahawk depend on an earlier version of the core then the impl. So we can compile against older versions that might be in the third party J2EE distros (like JBoss). Anyways, the point is that Maven may finally provide the best solution to this problem so far. This confirms my feelings that I always had. Although I nearly know nothing about Maven I start to like it ;-) My definite +1 on having a separate jar with all the stuff from the share dir Regarding the name: I agree that share might not be the best of all names for the end user jar. Although - from a source code view - this name perfectly describes what it stands for and how the code is used. Having said that I'm not too happy with core as an alternative name. -0.5 on core, because: As I understand it, the core of a software product is the part where all strings are tied up and the basic processing is done. The core of MyFaces sits in Impl and API. FacesServlet, UIComponentBase and UIComponentTag are those classes that come to my mind when I think of the core. The shared classes are a loosely coupled set of utilities, helpers and convenient base classes. Think of it as kind of commons classes for JSF. Not having doublechecked this yet, I have the feeling that most classes of our shared code are even compatible to foreign implementations (RI). So, why not give it a life of its own and head for that commons direction? So, my proposal is to call it myfaces-commons.jar in the meantime while heading for commons-jsf.jar in the long run - after having coordinated this with Apache Jakarta Commons guys, of course. We already have some good connections to the Jakarta team, right? Yes, sure, comparing our code to Jakarta Commons quality (javadoc in particular), this might be a long and cumbersome path... ;-) What do you think? Manfred
Re: [proposal] myfaces-core.jar
I'm ok with commons (myfaces-commons.jar). -1 for moving it to jakarta commons (at least for now.) sean On 11/30/05, Bill Dudney [EMAIL PROTECTED] wrote: +1 on the structural change +0 on name change either way - An argument can be made for any of the 3 proposed names (share, core or commons) so I'm open to any of them and let those with passion on one of the 3 sort it out ;-) TTFN, -bd- On Nov 30, 2005, at 1:10 AM, Manfred Geiler wrote: 2005/11/30, Sean Schofield [EMAIL PROTECTED]: I wanted to resurrect one of our favorite threads ... Should the shared code be in its own jar? The reason why I bring this up now is that I'm starting to experiment with an M2 build for MyFaces. In addition to some of the arguments made earlier we can now add Maven to the list of reasons why we might want to consider this. From my early exploration of Maven it seems like the shared stuff can be handled best by making the impl and tomahawk subprojects have a dependency on the share project. In the past I have not been too wild about the shared jar idea but I think Maven may be able to help keep us and our users informed as to the exact dependencies when using MyFaces or Tomahawk. First off, I would suggest we call it *core* instead of share. I think core helps to imply that it is mandatory. They already know they need api and impl (if they have read the JSF spec.) The core wording will let them know they need this also. Maven has some cool stuff for maintaining and documenting dependencies. The tomahawk page of the website can automatically be updated so that for each new release of tomahawk, the dependency list will be updated. Its also possible that we can have tomahawk depend on an earlier version of the core then the impl. So we can compile against older versions that might be in the third party J2EE distros (like JBoss). Anyways, the point is that Maven may finally provide the best solution to this problem so far. This confirms my feelings that I always had. Although I nearly know nothing about Maven I start to like it ;-) My definite +1 on having a separate jar with all the stuff from the share dir Regarding the name: I agree that share might not be the best of all names for the end user jar. Although - from a source code view - this name perfectly describes what it stands for and how the code is used. Having said that I'm not too happy with core as an alternative name. -0.5 on core, because: As I understand it, the core of a software product is the part where all strings are tied up and the basic processing is done. The core of MyFaces sits in Impl and API. FacesServlet, UIComponentBase and UIComponentTag are those classes that come to my mind when I think of the core. The shared classes are a loosely coupled set of utilities, helpers and convenient base classes. Think of it as kind of commons classes for JSF. Not having doublechecked this yet, I have the feeling that most classes of our shared code are even compatible to foreign implementations (RI). So, why not give it a life of its own and head for that commons direction? So, my proposal is to call it myfaces-commons.jar in the meantime while heading for commons-jsf.jar in the long run - after having coordinated this with Apache Jakarta Commons guys, of course. We already have some good connections to the Jakarta team, right? Yes, sure, comparing our code to Jakarta Commons quality (javadoc in particular), this might be a long and cumbersome path... ;-) What do you think? Manfred
Re: [proposal] myfaces-core.jar
Hi, in my oppinion a jar for the shared files is the best way, but before fixing a name: I think there could be a need for another jar. There are some components in towmahawk.jar which also could be usefull in combination with tobago. E.g. i don't like depend on towmahawk.jar just to use t:saveState or t:aliasBean. Because of differend renderkid ids it is not possible to mix tobago and towmahawk components. But i like the option to use render independend components also with tobago. Could we put those components into the 'core', or however, jar ? Or should we create a own artifact for those components? If so we should think about this name here also. Regards Volker Bill Dudney wrote: +1 on the structural change +0 on name change either way - An argument can be made for any of the 3 proposed names (share, core or commons) so I'm open to any of them and let those with passion on one of the 3 sort it out ;-) TTFN, -bd- On Nov 30, 2005, at 1:10 AM, Manfred Geiler wrote: 2005/11/30, Sean Schofield [EMAIL PROTECTED]: I wanted to resurrect one of our favorite threads ... Should the shared code be in its own jar? The reason why I bring this up now is that I'm starting to experiment with an M2 build for MyFaces. In addition to some of the arguments made earlier we can now add Maven to the list of reasons why we might want to consider this. From my early exploration of Maven it seems like the shared stuff can be handled best by making the impl and tomahawk subprojects have a dependency on the share project. In the past I have not been too wild about the shared jar idea but I think Maven may be able to help keep us and our users informed as to the exact dependencies when using MyFaces or Tomahawk. First off, I would suggest we call it *core* instead of share. I think core helps to imply that it is mandatory. They already know they need api and impl (if they have read the JSF spec.) The core wording will let them know they need this also. Maven has some cool stuff for maintaining and documenting dependencies. The tomahawk page of the website can automatically be updated so that for each new release of tomahawk, the dependency list will be updated. Its also possible that we can have tomahawk depend on an earlier version of the core then the impl. So we can compile against older versions that might be in the third party J2EE distros (like JBoss). Anyways, the point is that Maven may finally provide the best solution to this problem so far. This confirms my feelings that I always had. Although I nearly know nothing about Maven I start to like it ;-) My definite +1 on having a separate jar with all the stuff from the share dir Regarding the name: I agree that share might not be the best of all names for the end user jar. Although - from a source code view - this name perfectly describes what it stands for and how the code is used. Having said that I'm not too happy with core as an alternative name. -0.5 on core, because: As I understand it, the core of a software product is the part where all strings are tied up and the basic processing is done. The core of MyFaces sits in Impl and API. FacesServlet, UIComponentBase and UIComponentTag are those classes that come to my mind when I think of the core. The shared classes are a loosely coupled set of utilities, helpers and convenient base classes. Think of it as kind of commons classes for JSF. Not having doublechecked this yet, I have the feeling that most classes of our shared code are even compatible to foreign implementations (RI). So, why not give it a life of its own and head for that commons direction? So, my proposal is to call it myfaces-commons.jar in the meantime while heading for commons-jsf.jar in the long run - after having coordinated this with Apache Jakarta Commons guys, of course. We already have some good connections to the Jakarta team, right? Yes, sure, comparing our code to Jakarta Commons quality (javadoc in particular), this might be a long and cumbersome path... ;-) What do you think? Manfred -- Don't answer to From: address! Mail to this account are droped if not recieved via mailinglist. To contact me direct create the mail address by concatenating my forename to my senders domain.
Re: [proposal] myfaces-core.jar
First: my +1 for a separate jar, and myfaces-share or myfaces-commons.jar as name - I don't mind either, I don't like core, though. @Volker: That's an interesting question. We might need to split up the components into two groups, and create a new component pack name for render independent components - I wouldn't put them into core or commons, whatever the name might be. We could be creative again ;) regards, Martin On 11/30/05, Volker Weber [EMAIL PROTECTED] wrote: Hi, in my oppinion a jar for the shared files is the best way, but before fixing a name: I think there could be a need for another jar. There are some components in towmahawk.jar which also could be usefull in combination with tobago. E.g. i don't like depend on towmahawk.jar just to use t:saveState or t:aliasBean. Because of differend renderkid ids it is not possible to mix tobago and towmahawk components. But i like the option to use render independend components also with tobago. Could we put those components into the 'core', or however, jar ? Or should we create a own artifact for those components? If so we should think about this name here also. Regards Volker Bill Dudney wrote: +1 on the structural change +0 on name change either way - An argument can be made for any of the 3 proposed names (share, core or commons) so I'm open to any of them and let those with passion on one of the 3 sort it out ;-) TTFN, -bd- On Nov 30, 2005, at 1:10 AM, Manfred Geiler wrote: 2005/11/30, Sean Schofield [EMAIL PROTECTED]: I wanted to resurrect one of our favorite threads ... Should the shared code be in its own jar? The reason why I bring this up now is that I'm starting to experiment with an M2 build for MyFaces. In addition to some of the arguments made earlier we can now add Maven to the list of reasons why we might want to consider this. From my early exploration of Maven it seems like the shared stuff can be handled best by making the impl and tomahawk subprojects have a dependency on the share project. In the past I have not been too wild about the shared jar idea but I think Maven may be able to help keep us and our users informed as to the exact dependencies when using MyFaces or Tomahawk. First off, I would suggest we call it *core* instead of share. I think core helps to imply that it is mandatory. They already know they need api and impl (if they have read the JSF spec.) The core wording will let them know they need this also. Maven has some cool stuff for maintaining and documenting dependencies. The tomahawk page of the website can automatically be updated so that for each new release of tomahawk, the dependency list will be updated. Its also possible that we can have tomahawk depend on an earlier version of the core then the impl. So we can compile against older versions that might be in the third party J2EE distros (like JBoss). Anyways, the point is that Maven may finally provide the best solution to this problem so far. This confirms my feelings that I always had. Although I nearly know nothing about Maven I start to like it ;-) My definite +1 on having a separate jar with all the stuff from the share dir Regarding the name: I agree that share might not be the best of all names for the end user jar. Although - from a source code view - this name perfectly describes what it stands for and how the code is used. Having said that I'm not too happy with core as an alternative name. -0.5 on core, because: As I understand it, the core of a software product is the part where all strings are tied up and the basic processing is done. The core of MyFaces sits in Impl and API. FacesServlet, UIComponentBase and UIComponentTag are those classes that come to my mind when I think of the core. The shared classes are a loosely coupled set of utilities, helpers and convenient base classes. Think of it as kind of commons classes for JSF. Not having doublechecked this yet, I have the feeling that most classes of our shared code are even compatible to foreign implementations (RI). So, why not give it a life of its own and head for that commons direction? So, my proposal is to call it myfaces-commons.jar in the meantime while heading for commons-jsf.jar in the long run - after having coordinated this with Apache Jakarta Commons guys, of course. We already have some good connections to the Jakarta team, right? Yes, sure, comparing our code to Jakarta Commons quality (javadoc in particular), this might be a long and cumbersome path... ;-) What do you think? Manfred -- Don't answer to From: address! Mail to this account are droped if not recieved via mailinglist. To contact me direct create the mail address by concatenating my forename to my senders domain. -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and
Re: [proposal] myfaces-core.jar
+1 for a separate jar. It's a good point that tomahawk should be split, just like jsf/core and jsf/html are split out. All of the validators, converters, and non-rendering components probably should go into tomahawk-core :) [Guess we probably better not use myfaces-core, but like Bill said, I don't care what name gets used. None of them sound appealing so far). On 11/30/05, Martin Marinschek [EMAIL PROTECTED] wrote: First: my +1 for a separate jar, and myfaces-share or myfaces-commons.jar as name - I don't mind either, I don't like core, though. @Volker: That's an interesting question. We might need to split up the components into two groups, and create a new component pack name for render independent components - I wouldn't put them into core or commons, whatever the name might be. We could be creative again ;) regards, Martin On 11/30/05, Volker Weber [EMAIL PROTECTED] wrote: Hi, in my oppinion a jar for the shared files is the best way, but before fixing a name: I think there could be a need for another jar. There are some components in towmahawk.jar which also could be usefull in combination with tobago. E.g. i don't like depend on towmahawk.jar just to use t:saveState or t:aliasBean. Because of differend renderkid ids it is not possible to mix tobago and towmahawk components. But i like the option to use render independend components also with tobago. Could we put those components into the 'core', or however, jar ? Or should we create a own artifact for those components? If so we should think about this name here also. Regards Volker Bill Dudney wrote: +1 on the structural change +0 on name change either way - An argument can be made for any of the 3 proposed names (share, core or commons) so I'm open to any of them and let those with passion on one of the 3 sort it out ;-) TTFN, -bd- On Nov 30, 2005, at 1:10 AM, Manfred Geiler wrote: 2005/11/30, Sean Schofield [EMAIL PROTECTED]: I wanted to resurrect one of our favorite threads ... Should the shared code be in its own jar? The reason why I bring this up now is that I'm starting to experiment with an M2 build for MyFaces. In addition to some of the arguments made earlier we can now add Maven to the list of reasons why we might want to consider this. From my early exploration of Maven it seems like the shared stuff can be handled best by making the impl and tomahawk subprojects have a dependency on the share project. In the past I have not been too wild about the shared jar idea but I think Maven may be able to help keep us and our users informed as to the exact dependencies when using MyFaces or Tomahawk. First off, I would suggest we call it *core* instead of share. I think core helps to imply that it is mandatory. They already know they need api and impl (if they have read the JSF spec.) The core wording will let them know they need this also. Maven has some cool stuff for maintaining and documenting dependencies. The tomahawk page of the website can automatically be updated so that for each new release of tomahawk, the dependency list will be updated. Its also possible that we can have tomahawk depend on an earlier version of the core then the impl. So we can compile against older versions that might be in the third party J2EE distros (like JBoss). Anyways, the point is that Maven may finally provide the best solution to this problem so far. This confirms my feelings that I always had. Although I nearly know nothing about Maven I start to like it ;-) My definite +1 on having a separate jar with all the stuff from the share dir Regarding the name: I agree that share might not be the best of all names for the end user jar. Although - from a source code view - this name perfectly describes what it stands for and how the code is used. Having said that I'm not too happy with core as an alternative name. -0.5 on core, because: As I understand it, the core of a software product is the part where all strings are tied up and the basic processing is done. The core of MyFaces sits in Impl and API. FacesServlet, UIComponentBase and UIComponentTag are those classes that come to my mind when I think of the core. The shared classes are a loosely coupled set of utilities, helpers and convenient base classes. Think of it as kind of commons classes for JSF. Not having doublechecked this yet, I have the feeling that most classes of our shared code are even compatible to foreign implementations (RI). So, why not give it a life of its own and head for that commons direction? So, my proposal is to call it myfaces-commons.jar in the meantime while heading for commons-jsf.jar in the long run - after having coordinated this with Apache Jakarta Commons guys, of course. We already have some
Re: [proposal] myfaces-core.jar
If we split the components, we will need another prefix for
myfaces-core ('ft', 'f' from the standard core and 't' from tomahawk)?
I see many decisions in this thread now :-) So I also think that we
should avoid the name myfaces-core.
Regards,
Bruno
2005/11/30, Mike Kienenberger [EMAIL PROTECTED]:
+1 for a separate jar.
It's a good point that tomahawk should be split, just like jsf/core
and jsf/html are split out. All of the validators, converters, and
non-rendering components probably should go into tomahawk-core :)
[Guess we probably better not use myfaces-core, but like Bill said, I
don't care what name gets used. None of them sound appealing so
far).
On 11/30/05, Martin Marinschek [EMAIL PROTECTED] wrote:
First:
my +1 for a separate jar, and myfaces-share or myfaces-commons.jar as
name - I don't mind either, I don't like core, though.
@Volker:
That's an interesting question.
We might need to split up the components into two groups, and create a
new component pack name for render independent components - I wouldn't
put them into core or commons, whatever the name might be. We could be
creative again ;)
regards,
Martin
On 11/30/05, Volker Weber [EMAIL PROTECTED] wrote:
Hi,
in my oppinion a jar for the shared files is the best way, but before
fixing a name: I think there could be a need for another jar.
There are some components in towmahawk.jar which also could be usefull
in combination with tobago. E.g. i don't like depend on towmahawk.jar
just to use t:saveState or t:aliasBean. Because of differend renderkid
ids it is not possible to mix tobago and towmahawk components. But i
like the option to use render independend components also with tobago.
Could we put those components into the 'core', or however, jar ? Or
should we create a own artifact for those components? If so we should
think about this name here also.
Regards
Volker
Bill Dudney wrote:
+1 on the structural change
+0 on name change either way - An argument can be made for any of the
3 proposed names (share, core or commons) so I'm open to any of them
and let those with passion on one of the 3 sort it out ;-)
TTFN,
-bd-
On Nov 30, 2005, at 1:10 AM, Manfred Geiler wrote:
2005/11/30, Sean Schofield [EMAIL PROTECTED]:
I wanted to resurrect one of our favorite threads ... Should the
shared code be in its own jar?
The reason why I bring this up now is that I'm starting to experiment
with an M2 build for MyFaces. In addition to some of the arguments
made earlier we can now add Maven to the list of reasons why we might
want to consider this.
From my early exploration of Maven it seems like the shared stuff can
be handled best by making the impl and tomahawk subprojects have a
dependency on the share project. In the past I have not been too
wild
about the shared jar idea but I think Maven may be able to help keep
us and our users informed as to the exact dependencies when using
MyFaces or Tomahawk.
First off, I would suggest we call it *core* instead of share. I
think core helps to imply that it is mandatory. They already know
they need api and impl (if they have read the JSF spec.) The core
wording will let them know they need this also.
Maven has some cool stuff for maintaining and documenting
dependencies. The tomahawk page of the website can automatically be
updated so that for each new release of tomahawk, the dependency list
will be updated. Its also possible that we can have tomahawk depend
on an earlier version of the core then the impl. So we can compile
against older versions that might be in the third party J2EE distros
(like JBoss). Anyways, the point is that Maven may finally provide
the best solution to this problem so far.
This confirms my feelings that I always had. Although I nearly know
nothing about Maven I start to like it ;-)
My definite
+1 on having a separate jar with all the stuff from the share dir
Regarding the name: I agree that share might not be the best of all
names for the end user jar. Although - from a source code view - this
name perfectly describes what it stands for and how the code is used.
Having said that I'm not too happy with core as an alternative name.
-0.5 on core, because:
As I understand it, the core of a software product is the part where
all strings are tied up and the basic processing is done. The core of
MyFaces sits in Impl and API. FacesServlet, UIComponentBase and
UIComponentTag are those classes that come to my mind when I think of
the core.
The shared classes are a loosely coupled set of utilities, helpers and
convenient base classes. Think of it as kind of commons classes for
JSF. Not having doublechecked this
Re: [proposal] myfaces-core.jar
On 11/30/05, Bruno Aranda [EMAIL PROTECTED] wrote:
If we split the components, we will need another prefix for
myfaces-core ('ft', 'f' from the standard core and 't' from tomahawk)?
I see many decisions in this thread now :-) So I also think that we
should avoid the name myfaces-core.
I'd suggest tf and th to parallel f and h
It's gonna be ugly no matter how we go, though :)
Re: [proposal] myfaces-core.jar
OK lets agree to drop core then since most don't like it ;-)
I think we have enough +1's for myfaces-commons.jar. If anyone wants
to express a -1 for this please do so in the next few days. For now
we'll assume this new jar in the maven builds.
I have some preliminary work done on the m2 scripts. I wrote my own
since nobody came forward with their efforts. I'm borrowing ideas
from the tobago and struts scripts. I have to say that I'm pretty
impressed with m2 so far. There is more to learn but its quite nice.
Within the next few days I hope to have something on the *test* SVN
server for us to experiment with. That way everyone can start
contributing patches and test and we can all be on the same page.
I've been thinking about Manfred's idea of commons-jsf. There might
be some merit to that idea but I still think we should wait. Lets
tackle reorg, maven and a 1.1.2 release first.
As for breaking up tomahawk, again I think there is some value to this
proposal but I think we're better off putting out a 1.1.2 release with
Maven (and reworking the website) first. That will take enough time
and energy. Then I think we can turn our attention to how we
integrate tobago and move it out of the incubator.
sean
On 11/30/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 11/30/05, Bruno Aranda [EMAIL PROTECTED] wrote:
If we split the components, we will need another prefix for
myfaces-core ('ft', 'f' from the standard core and 't' from tomahawk)?
I see many decisions in this thread now :-) So I also think that we
should avoid the name myfaces-core.
I'd suggest tf and th to parallel f and h
It's gonna be ugly no matter how we go, though :)
Re: [proposal] myfaces-core.jar
Sean Schofield wrote: I wanted to resurrect one of our favorite threads ... Should the shared code be in its own jar? The reason why I bring this up now is that I'm starting to experiment with an M2 build for MyFaces. In addition to some of the arguments made earlier we can now add Maven to the list of reasons why we might want to consider this. From my early exploration of Maven it seems like the shared stuff can be handled best by making the impl and tomahawk subprojects have a dependency on the share project. In the past I have not been too wild about the shared jar idea but I think Maven may be able to help keep us and our users informed as to the exact dependencies when using MyFaces or Tomahawk. First off, I would suggest we call it *core* instead of share. I think core helps to imply that it is mandatory. They already know they need api and impl (if they have read the JSF spec.) The core wording will let them know they need this also. Maven has some cool stuff for maintaining and documenting dependencies. The tomahawk page of the website can automatically be updated so that for each new release of tomahawk, the dependency list will be updated. Its also possible that we can have tomahawk depend on an earlier version of the core then the impl. So we can compile against older versions that might be in the third party J2EE distros (like JBoss). Anyways, the point is that Maven may finally provide the best solution to this problem so far. How about the idea of moving the few external dependencies myfaces nowadays has into their own namespace to avoid conflicts between versions of those libraries used by myfaces and those used by the application servers/webapps (I am talking about stuff like apache commons, which could be moved into their own respective namespaces, like dependency.org.apache) This way we could get rid of most if not all version conflicts which could arise between the collaboration of myfaces and various app servers.
[proposal] myfaces-core.jar
I wanted to resurrect one of our favorite threads ... Should the shared code be in its own jar? The reason why I bring this up now is that I'm starting to experiment with an M2 build for MyFaces. In addition to some of the arguments made earlier we can now add Maven to the list of reasons why we might want to consider this. From my early exploration of Maven it seems like the shared stuff can be handled best by making the impl and tomahawk subprojects have a dependency on the share project. In the past I have not been too wild about the shared jar idea but I think Maven may be able to help keep us and our users informed as to the exact dependencies when using MyFaces or Tomahawk. First off, I would suggest we call it *core* instead of share. I think core helps to imply that it is mandatory. They already know they need api and impl (if they have read the JSF spec.) The core wording will let them know they need this also. Maven has some cool stuff for maintaining and documenting dependencies. The tomahawk page of the website can automatically be updated so that for each new release of tomahawk, the dependency list will be updated. Its also possible that we can have tomahawk depend on an earlier version of the core then the impl. So we can compile against older versions that might be in the third party J2EE distros (like JBoss). Anyways, the point is that Maven may finally provide the best solution to this problem so far. Thoughts? sean
Re: [proposal] myfaces-core.jar
I think that's an excellent idea, since drawing those lines in the codebase would hopefully encourage levels of separation and increase compatability of your JSF implementation with other frameworks and components. Sean Schofield wrote: I wanted to resurrect one of our favorite threads ... Should the shared code be in its own jar? The reason why I bring this up now is that I'm starting to experiment with an M2 build for MyFaces. In addition to some of the arguments made earlier we can now add Maven to the list of reasons why we might want to consider this. From my early exploration of Maven it seems like the shared stuff can be handled best by making the impl and tomahawk subprojects have a dependency on the share project. In the past I have not been too wild about the shared jar idea but I think Maven may be able to help keep us and our users informed as to the exact dependencies when using MyFaces or Tomahawk. First off, I would suggest we call it *core* instead of share. I think core helps to imply that it is mandatory. They already know they need api and impl (if they have read the JSF spec.) The core wording will let them know they need this also. Maven has some cool stuff for maintaining and documenting dependencies. The tomahawk page of the website can automatically be updated so that for each new release of tomahawk, the dependency list will be updated. Its also possible that we can have tomahawk depend on an earlier version of the core then the impl. So we can compile against older versions that might be in the third party J2EE distros (like JBoss). Anyways, the point is that Maven may finally provide the best solution to this problem so far. Thoughts? sean -- Jacob Hookom - Minneapolis -- http://hookom.blogspot.com
Re: [proposal] myfaces-core.jar
I also wasn't fond of yet another myfaces.jar, but I think the advantages of releasing different versions of Tomahawk and Impl make up for it. At some point, Impl should become stable and mature, but hopefully tomahawk is going to constantly change and grow. I don't think Impl and Tomahawk should have the same release cycles indefinitely. As an end-user I also like having the ability to upgrade either one separately. On 11/29/05, Sean Schofield [EMAIL PROTECTED] wrote: I wanted to resurrect one of our favorite threads ... Should the shared code be in its own jar? The reason why I bring this up now is that I'm starting to experiment with an M2 build for MyFaces. In addition to some of the arguments made earlier we can now add Maven to the list of reasons why we might want to consider this. From my early exploration of Maven it seems like the shared stuff can be handled best by making the impl and tomahawk subprojects have a dependency on the share project. In the past I have not been too wild about the shared jar idea but I think Maven may be able to help keep us and our users informed as to the exact dependencies when using MyFaces or Tomahawk. First off, I would suggest we call it *core* instead of share. I think core helps to imply that it is mandatory. They already know they need api and impl (if they have read the JSF spec.) The core wording will let them know they need this also. Maven has some cool stuff for maintaining and documenting dependencies. The tomahawk page of the website can automatically be updated so that for each new release of tomahawk, the dependency list will be updated. Its also possible that we can have tomahawk depend on an earlier version of the core then the impl. So we can compile against older versions that might be in the third party J2EE distros (like JBoss). Anyways, the point is that Maven may finally provide the best solution to this problem so far. Thoughts? sean
