10:59am
]
balunasj
:
Hi all
[
11:00am
]
balunasj
:
The agenda for todays meeting is here - https://community.jboss.org/wiki/RichFacesTeamMeetingAgenda5-4-2010
[
11:00am
]
abelevich
:
hi
[
11:00am
]
alexsmirnov joined the chat room.
[
11:00am
]
balunasj
:
We'll get started in just a minute to give people some time to join?
[
11:01am
]
balunasj
:
alexsmirnov: Hi - agenda is here https://community.jboss.org/wiki/RichFacesTeamMeetingAgenda5-4-2010
[
11:03am
]
balunasj
:
ok lets get started
[
11:03am
]
rruss joined the chat room.
[
11:04am
]
balunasj
:
I really want to spend the majority of the meeting discussing the build and structure
[
11:04am
]
balunasj
:
but first an update on the maven repo updates
[
11:04am
]
balunasj
:
as you ca see from the agenda - We are in good shape
[
11:04am
]
balunasj
:
Konstantin2: is there anything else that you want to do or can you resolve your issue?
[
11:05am
]
amarkhel joined the chat room.
[
11:05am
]
balunasj
:
amarkhel: discussing repo updates and related jiras
[
11:05am
]
balunasj
:
amarkhel: is there anything else that you want to do or can you resolve your issue?
[
11:06am
]
amarkhel
:
no, anything else
[
11:06am
]
prabhatjha
:
hello
[
11:06am
]
balunasj
:
prabhatjha: hi
[
11:06am
]
amarkhel
:
I mean I am going to resolve
[
11:06am
]
balunasj
:
amarkhel: ok thanks
[
11:06am
]
balunasj
:
Konstantin2: and you?
[
11:07am
]
balunasj
:
I updated the hudson builds and made some tweaks to get them working - so they are mostly all set
[
11:07am
]
balunasj
:
the 3.3. build has failed but for other reasons - memory, and network problem
[
11:08am
]
balunasj
:
prabhatjha: there are some test builds that need some updates
[
11:08am
]
ilya_shaikovsky joined the chat room.
[
11:08am
]
balunasj
:
prabhatjha: but they should be minor changes I think
[
11:08am
]
ilya_shaikovsky
:
hello all! sorry for being some late
[
[
11:08am
]
prabhatjha
:
balunasj: ok
[
11:08am
]
balunasj
:
ilya_shaikovsky: Hi - heard your new laptop is giving you a problem
[
11:09am
]
balunasj
:
ilya_shaikovsky: talking about maven updates before moving to build
[
11:10am
]
ilya_shaikovsky
:
the firrst time
[
11:10am
]
ilya_shaikovsky
:
yup.. saw the agenda
[
11:10am
]
balunasj
:
ilya_shaikovsky: can you given me the status on the wiki updates
[
11:10am
]
balunasj
:
?
[
11:10am
]
Konstantin2
:
balunasj: I have resolved issue.
[
11:11am
]
balunasj
:
Konstantin2: ok
[
11:11am
]
ilya_shaikovsky
:
I not started write-up's while Kostya worked under new maven repo usage.. I planned to check the results this week and make write up
[
11:12am
]
balunasj
:
ilya_shaikovsky: ok - I'll keep an eye out and review when your done - then we can close this out
[
11:12am
]
balunasj
:
now the that hudson builds are back and running
[
11:13am
]
balunasj
:
I would like us all to watch if a build breaks after we make a commit.
[
11:13am
]
ilya_shaikovsky
:
balunasj, sure
[
11:13am
]
balunasj
:
also I encourage all developers to use the JBoss developer settings
[
11:14am
]
balunasj
:
this will help catch repo issues early, and also I like it because it pulls everything from one repo once updates are made
[
11:15am
]
balunasj
:
ok so on to 4.0
[
11:15am
]
•
balunasj
 
thinking wow - no 3.3.3 topics !!!
[
11:15am
]
balunasj
:
so we need to make a big push and get A2 out the door as soon as possible
[
11:16am
]
balunasj
:
looking at jira we are still at 123 issues in RF
[
11:16am
]
balunasj
:
and several large issues in RFPL
[
11:17am
]
balunasj
:
I would like everyone that is assigned issues to review, and then post to a dev topic that I will create with a updates
[
11:17am
]
balunasj
:
status, concerns etc...
[
11:17am
]
balunasj
:
we don't have time in this meeting for that.
[
11:17am
]
balunasj
:
I'll start off that topic today.
[
11:17am
]
balunasj
:
any questions or comments on that?
[
11:18am
]
nbelaevski
:
nope
[
11:18am
]
balunasj
:
ok great
[
11:18am
]
balunasj
:
so lets shift to the build discussion
[
11:19am
]
balunasj
:
As I sent in email I created http://community.jboss.org/wiki/RichFaces40BuildDirectoryStructure
[
11:19am
]
balunasj
:
based on various discussions
[
11:19am
]
balunasj
:
We have some open questions
[
11:20am
]
balunasj
:
and I would like to get these resolved today so that Alex K, Nick, and myself can start breaking this down.
[
11:20am
]
balunasj
:
so lets start with the first one from the agenda
[
11:20am
]
balunasj
:
when nbelaevski and I talked about this orginally we were going to have core
[
11:21am
]
balunasj
:
have /api/t/b/t
[
11:21am
]
balunasj
:
/impl/t/b/t
[
11:21am
]
balunasj
:
and dist t/b/t
[
11:21am
]
balunasj
:
I changed it to just one /t/b/t for all of core.
[
11:22am
]
balunasj
:
I think there are pros and cons to each, but following our
[
11:22am
]
balunasj
:
structure in other places I am leaning towards nbelaevski
[
11:22am
]
balunasj
:
and putting back the t/b/t for api, imp, and dist
[
11:22am
]
balunasj
:
thoughts, comments?
[
11:24am
]
alexsmirnov
:
balunasj:  Why separate tags and branches would be needed for a api/impl ?
[
11:25am
]
balunasj
:
alexsmirnov: The primary reason is to allow for point releases without releasing all three
[
11:26am
]
balunasj
:
might not be as important for api/impl
[
11:26am
]
balunasj
:
Another is to make the separation very obvious
[
11:26am
]
balunasj
:
and keeping as clean a dependency graph as possible.
[
11:27am
]
balunasj
:
the cons - are more maintence
[
11:27am
]
balunasj
:
but that depends on effectiveness of automated releases
[
11:28am
]
echelog joined the chat room.
[
11:29am
]
balunasj
:
nbelaevski: anything else?  thoughts?
[
11:30am
]
alexsmirnov
:
balunasj:  We have never be able to use different api objects with different implementations, they always were changed together. So, having separate api/impl releases sems never possible, so they should be in the same trunk.
[
11:30am
]
nbelaevski
:
I'm thinking about the primary reason you've already mentioned
[
11:31am
]
balunasj
:
alexsmirnov: that was my thinking as well with the structure in the wiki, but I think it is important to consider both sides.
[
11:31am
]
nbelaevski
:
alexsmirnov: maybe the separation between API & impl wasn't clear enough in 3.x?
[
11:31am
]
balunasj
:
nbelaevski: fair point I thinkn
[
11:32am
]
balunasj
:
alexsmirnov: with them in separate trunks there is definable lines of dependencies
[
11:32am
]
nbelaevski
:
we can also consider split of API into component API & fwk API
[
11:32am
]
nbelaevski
:
at least at packaging level
[
11:32am
]
balunasj
:
nbelaevski: that is fair to be considered as well
[
11:33am
]
balunasj
:
take a look at seam's module structure
[
11:33am
]
balunasj
:
each one has API/core
[
11:33am
]
balunasj
:
api/impl
[
11:33am
]
balunasj
:
http://seamframework.org/Seam3/ModuleAnatomy
[
11:33am
]
balunasj
:
although I think most of seams are under a single t/b/t
[
11:34am
]
alexsmirnov
:
Sure, Seam keeps api/impl in the same branch.
[
11:35am
]
nbelaevski
:
from the point of view of different API modules, it seems logical to create t/b/t for each component API
[
11:35am
]
nbelaevski
:
this can be considered as addition to cons
[
11:36am
]
balunasj
:
nbelaevski: lets hold off on the component API part for right now
[
11:36am
]
nbelaevski
:
balunasj: ok, sorry
[
11:36am
]
balunasj
:
I want to make sure we finish talking about core
[
11:36am
]
balunasj
:
nbelaevski: np
[
11:36am
]
balunasj
:
I do not feel 100% either way
[
11:36am
]
balunasj
:
so let me ask this question -
[
11:36am
]
balunasj
:
which is the easier to change to/from the other?
[
11:37am
]
balunasj
:
i.e if we start with combined t/b/t then need to shift to separate t/b/t
[
11:37am
]
balunasj
:
which is easier.
[
11:38am
]
nbelaevski
:
imo shift to separate t/b/t is easier
[
11:38am
]
•
balunasj
 
thinking that the core api/impl might be aspecifal case worth having separate api/impl for like weld did
[
11:39am
]
balunasj
:
nbelaevski: so starting out with combined might be the best stratagy for now
[
11:39am
]
balunasj
:
then if we need to we can shift to separate.
[
11:39am
]
alexsmirnov
:
nbelaevski: agree. I also does not like a lot of trunks/brunches because it really duplicates svn merging capabilities. Especially if Jboss going to upgrade svn structure
[
11:40am
]
nbelaevski
:
alexsmirnov: scripting can save us
[
11:40am
]
balunasj
:
that is part of the reason seam/weld rely so heavily on release plugin
[
11:40am
]
alexsmirnov
:
using baranch/merge/reintegrate instead of tags/branches/trunk
[
11:41am
]
balunasj
:
alexsmirnov: t/b/t has other purposes though
[
11:41am
]
nbelaevski
:
I'm ok for integral t/b/t for core API & impl
[
11:41am
]
nbelaevski
:
with the possibility of split in the future
[
11:41am
]
alexsmirnov
:
nbelaevski: I'm too.
[
11:41am
]
nbelaevski
:
e.g. at Mx version when API is stable
[
11:42am
]
balunasj
:
good
[
11:42am
]
balunasj
:
nbelaevski: yup - or if we start to see some cross dependency issues.
[
11:42am
]
nbelaevski
:
balunasj: yes
[
11:42am
]
balunasj
:
ok so lets move on to the next question
[
11:43am
]
balunasj
:
nbelaevski: lets hold off on the separate
[
11:43am
]
balunasj
:
api for components until we discuss UI break up
[
11:44am
]
balunasj
:
so next I wanted to discuss the comments and discussion that Alex and I had last night.
[
11:44am
]
nbelaevski
:
balunasj: ok
[
11:44am
]
balunasj
:
For the most part I think alexsmirnov and I were agreeing
[
11:44am
]
balunasj
:
the structure I defined was for high project wide
[
11:44am
]
balunasj
:
while the comments that alexsmirnov made break that down to module specific
[
11:45am
]
balunasj
:
they are both similar, but scope is a bit diff
[
11:45am
]
balunasj
:
alexsmirnov: would you agree?
[
11:46am
]
balunasj
:
For each module ( lets define that as each t/b/t )
[
11:46am
]
balunasj
:
we need define its requirements
[
11:46am
]
alexsmirnov
:
balunasj: The only one difference with your structure: I suggest to put aggregation on the top level directory and have "parent" project with build configuration.
[
11:47am
]
balunasj
:
alexsmirnov: just to be clear - when you say aggregation - do you mean assembler/dist responsibility?
[
11:47am
]
balunasj
:
or just module build aggregation?
[
11:47am
]
alexsmirnov
:
Yes, this is about "dist"
[
11:48am
]
balunasj
:
ok then yes - this is where we disagree
[
11:48am
]
nbelaevski
:
we've discussed this with Alex_Kolonitsky yesterday
[
11:48am
]
balunasj
:
my concern is that is the base directory pom.xml is responsible for assembler/dist it will clutter
[
11:48am
]
balunasj
:
the base dir like what happened to /root
[
11:48am
]
alexsmirnov
:
Just due to the Maven architecture, putting "dist" out of the top project is complicated.
[
11:49am
]
nbelaevski
:
there were some issues with installation of BoM file without the structure that Alex described
[
11:49am
]
balunasj
:
nbelaevski: You mean the issue with the pom parent and the distribution management
[
11:49am
]
balunasj
:
?
[
11:49am
]
lfryc left the chat room. (Quit: Leaving)
[
11:50am
]
balunasj
:
nbelaevski: that would be handled by the BOM inheriting from the main project parent pom.xml
[
11:50am
]
balunasj
:
alexsmirnov: can you describe the problems that creates?
[
11:51am
]
nbelaevski
:
balunasj: no, when parent inherits from BoM and is at the top of the t/b/t structure, then we can point to BoM file, but it won't be installed into local repository
[
11:52am
]
alexsmirnov
:
balunasj: A lot of Maven plugins, such as assembly, reporting etc. treat multi-module project in the special way. These plugins run in the special aggregation mode.
[
11:52am
]
balunasj
:
nbelaevski: this sounds very similar to the issue with deploying the bom from CDK to snapshots
[
11:53am
]
alexsmirnov
:
so, aggregator project has to have all dependent modules in the <modules> sections, same as the top-level has. I wish to avoid such duplication.
[
11:53am
]
balunasj
:
nbelaevski: the bom needed to have some inheritance elements from the project parent
[
11:54am
]
nbelaevski
:
balunasj: right
[
11:54am
]
balunasj
:
alexsmirnov: hmm - there must be a way to organize the the resources that the assembler needs though
[
11:55am
]
alexsmirnov
:
nbelaevski: Have you read my comments ? Jay talks about single project-wide parent that holds all meta information.
[
11:55am
]
balunasj
:
alexsmirnov: I really don't like them cluttering the various module roots
[
11:55am
]
balunasj
:
alexsmirnov: right that is the one in /build/parent
[
11:57am
]
nbelaevski
:
alexsmirnov: yes I read them, but I'm talking about another issue with BoM files
[
11:57am
]
balunasj
:
nbelaevski: oh I'm sorry I must have misunderstoon
[
11:57am
]
balunasj
:
misunderstood
[
11:58am
]
nbelaevski
:
the point was about where to place parent project pom & the necessity of aggregator
[
11:58am
]
nbelaevski
:
aggregator = pom that refers to module, not assembler
[
12:00pm
]
nbelaevski
:
alexsmirnov: we can consider assembly build as two separate build processes
[
12:00pm
]
nbelaevski
:
alexsmirnov: imho, this changes aggregation mode, because there will be different contents of reactor
[
12:01pm
]
balunasj
:
nbelaevski: if you mean considering building the module, and assembling a release artifact - I 100% agree
[
12:01pm
]
nbelaevski
:
balunasj: yes
[
12:01pm
]
alexsmirnov
:
nbelaevski: why ? For me, build/assembly are only different goal from the same set.
[
12:01pm
]
balunasj
:
nbelaevski: yes - imo building a packaged zip should be separate from building the module for development.
[
12:02pm
]
nbelaevski
:
alexsmirnov: we have a choice of single assembler for all project modules vs separation of assemblers
[
12:02pm
]
balunasj
:
alexsmirnov: I think that creating a dist can become complex, and can make the pom.xml hard to read
[
12:03pm
]
alexsmirnov
:
balunasj: the difference is only the target goal. You run mvn install for development, and mvn assembly:assembly for dist.
[
12:03pm
]
balunasj
:
alexsmirnov: I want someone who just looks at the module /pom.xml to easily understand it and build the project
[
12:03pm
]
nbelaevski
:
alexsmirnov: we've discussed that with Jay and came to agreement that separation of assemblers' concern is easier
[
12:03pm
]
nbelaevski
:
so that we have simple assembler at top level + assemblers for each project module that know how to deal with it
[
12:03pm
]
balunasj
:
alexsmirnov: my concern is that the resources, scripts, and customizations can make this clutters
[
12:04pm
]
balunasj
:
just building a project for development tends to be clean ( or at least cleaner ) than the assembler
[
12:04pm
]
rafaelliu left the chat room. (Quit: Leaving)
[
12:06pm
]
alexsmirnov
:
balunasj: First, assembly projects can have their own inheritance, so most of aspects can be configured in the single place.
[
12:06pm
]
balunasj
:
alexsmirnov: The aggregrator pom.xml would still be able to assemble, but it would do it by calling module build in /dist
[
12:07pm
]
balunasj
:
alexsmirnov: would this be project wide?  is that possible since many modules have different needs?
[
12:08pm
]
alexsmirnov
:
balunasj: Common configuration could be in the root/pom.xml, any subproject can ovreeride it if needed.
[
12:09pm
]
alexsmirnov
:
balunasj: My concern about separate "dist" project that we have to maintain the same modules list in two places.
[
12:09pm
]
balunasj
:
alexsmirnov: if we did something like that ( not sure yet ) that would likely be in /root/build or /root/dist
[
12:10pm
]
balunasj
:
alexsmirnov: thinking about module list comment
[
12:10pm
]
•
balunasj
 
looking here http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/index.html
[
12:11pm
]
alexsmirnov
:
balunasj: Really, in most cases  top directory pom and "dist" project will be just identical.
[
12:13pm
]
balunasj
:
alexsmirnov: if we went that way is there a way to "hide" the assembler resources, perhaps in /dist?
[
12:14pm
]
•
balunasj
 
I could see us using shared assembly descriptors like this - http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html
[
12:15pm
]
alexsmirnov
:
balunasj: These projects has "skip deployment" setting, so they are used as build scripts only and never go to public repository.
[
12:16pm
]
balunasj
:
alexsmirnov: are you talking about the "hiding" or about the projects in the links I gave?
[
12:18pm
]
alexsmirnov
:
I talking about settings like this:
[
12:18pm
]
alexsmirnov
:
<artifactId>maven-deploy-plugin</artifactId>
[
12:18pm
]
alexsmirnov
:
            <inherited>false</inherited>
[
12:18pm
]
alexsmirnov
:
            <configuration>
[
12:18pm
]
alexsmirnov
:
              <skip>true</skip>
[
12:18pm
]
alexsmirnov
:
            </configuration>
[
12:19pm
]
balunasj
:
So this would make resources in the /dist not be deployed - correct?
[
12:20pm
]
alexsmirnov
:
Yes
[
12:20pm
]
balunasj
:
ok
[
12:20pm
]
balunasj
:
since we seem to be at an impass
[
12:20pm
]
balunasj
:
I suggest this
[
12:21pm
]
balunasj
:
we go with alex's Idea of the base dir pom.xml
[
12:21pm
]
balunasj
:
managing both the assembly and module build
[
12:21pm
]
balunasj
:
with these requirements
[
12:21pm
]
balunasj
:
1) assembly resources are not in base dir
[
12:22pm
]
balunasj
:
2) module pom.xml does not get too cluttered with assembly config
[
12:22pm
]
balunasj
:
2.1) i.e. using assembly.xml
[
12:22pm
]
balunasj
:
3) we still have /bom and /parent
[
12:23pm
]
balunasj
:
/bom for runtime dependencies
[
12:23pm
]
balunasj
:
/parent for module metadata
[
12:23pm
]
balunasj
:
alexsmirnov: nbelaevski : sound good to get us started?
[
12:24pm
]
nbelaevski
:
balunasj: will there be separate module for assembly resources?
[
12:24pm
]
balunasj
:
nbelaevski: you mean t/b/t?
[
12:24pm
]
nbelaevski
:
or just src/main/assembly?
[
12:25pm
]
nbelaevski
:
balunasj: no
[
12:25pm
]
•
balunasj
 
just got very stormy at my house
[
12:26pm
]
balunasj
:
This is one problem I see
[
12:26pm
]
balunasj
:
each t/b/t would need its own assembly
[
12:27pm
]
balunasj
:
but then how would you handle something like UI
[
12:27pm
]
balunasj
:
or the root assembler to create the whole project dist
[
12:28pm
]
balunasj
:
These are things we might not be able to answer, until
[
12:28pm
]
balunasj
:
we start working
[
12:30pm
]
nbelaevski
:
ok, to be sure about the structure, can please someone update the article today?
[
12:30pm
]
balunasj
:
if we are going to go with a combined approach I think we should model after seam
[
12:30pm
]
balunasj
:
thttp://seamframework.org/Seam3/ModuleAnatomy
[
12:30pm
]
balunasj
:
nbelaevski: yes I will update today
[
12:30pm
]
nbelaevski
:
balunasj: good thanks
[
12:30pm
]
balunasj
:
based on what we figure out
[
12:31pm
]
balunasj
:
alexsmirnov: nbelaevski : lets move on to some of the other questions
[
12:31pm
]
balunasj
:
and we can talk more later
[
12:32pm
]
balunasj
:
alexsmirnov: back to the wiki article
[
12:32pm
]
balunasj
:
alexsmirnov: why are you placing dependencies in plugin management?
[
12:32pm
]
jbossbot left the chat room. (Remote host closed the connection)
[
12:33pm
]
balunasj
:
or is that something for CDK only?
[
12:33pm
]
jbossbot joined the chat room.
[
12:33pm
]
alexsmirnov
:
balunasj: Sorry, I did away from discussion. Ui assembler is same as http://maven.apache.org/plugins/maven-shade-plugin/
[
12:34pm
]
alexsmirnov
:
with additional feature that merges faces-config.xml and taglib.xml
[
12:34pm
]
alexsmirnov
:
balunasj: Where do you see dependencies in the plugin management ?
[
12:35pm
]
balunasj
:
All subproject dependencies are defined in the <pluginManagement> section of the bom ( Bill Of Materials ) pom. I also put maven-cdk-plugin in the <pluginManagement> section there while it's not clear wether it will be imported ( seems that Maven 2.2.1 does )
[
12:35pm
]
balunasj
:
from your wiki comments, and my question http://community.jboss.org/wiki/RichFaces40BuildDirectoryStructure#comment-3268
[
12:36pm
]
alexsmirnov
:
This is typo error Of course, there should be <dependencyManagement>
[
12:36pm
]
balunasj
:
alexsmirnov: lol
[
12:36pm
]
balunasj
:
alexsmirnov: ok good!!  - I thought I missed something very big
[
12:36pm
]
balunasj
:
Alex_Kolonitsky: you still here?
[
12:37pm
]
Alex_Kolonitsky
:
yes
[
12:37pm
]
balunasj
:
Alex_Kolonitsky: great, lets talk about your questions
[
12:37pm
]
balunasj
:
then we talk about ui component structure
[
12:37pm
]
balunasj
:
Where will be checkstyle module?
[
12:38pm
]
balunasj
:
this would go in /build
[
12:38pm
]
balunasj
:
either in /resources or on its own
[
12:38pm
]
balunasj
:
( as its own module )
[
12:39pm
]
balunasj
:
Alex_Kolonitsky: make sense?
[
12:39pm
]
Alex_Kolonitsky
:
I think build/checkstyle is better place
[
12:39pm
]
balunasj
:
/build is for anything that the builds requires
[
12:39pm
]
nbelaevski
:
balunasj: we need its own module because of different packaging
[
12:40pm
]
balunasj
:
Alex_Kolonitsky: if it needs its own releases then yes that likely makes sense
[
12:40pm
]
balunasj
:
nbelaevski: ok
[
12:40pm
]
abelevich left the chat room.
[
12:40pm
]
balunasj
:
alexsmirnov: have you seen Alex_Kolonitsky comment on CDK structure
[
12:42pm
]
nbelaevski
:
Alex_Kolonitsky: wdyt - /build/resources/(t|b|t)/checkstyle ?
[
12:42pm
]
balunasj
:
nbelaevski: that would work for me
[
12:42pm
]
Alex_Kolonitsky
:
I agree
[
12:42pm
]
nbelaevski
:
good
[
12:42pm
]
balunasj
:
Alex_Kolonitsky: regarding - Move all archetypes to the "root/archetypes" project.
[
12:43pm
]
balunasj
:
Alex_Kolonitsky: yes - except for the ones from CDK that are specific to CDK
[
12:43pm
]
alexsmirnov
:
Yes, I saw. The only concern that I now can build maven plugins by single command in the "plugins" folder, but That would be fine if we going to move archetypes out from cdk.
[
12:43pm
]
balunasj
:
alexsmirnov: what are your planned archetypes?
[
12:44pm
]
nbelaevski
:
balunasj: afaik, archetypes don't use code from CDK, they just add dependency to it in the generated pom.xml files
[
12:44pm
]
alexsmirnov
:
balunasj: May be build/t/t/b[checkstyle,assembly,archetypes] ?
[
12:44pm
]
balunasj
:
alexsmirnov: since we have talked about CDK having its own distribution - I think it should self contain its own archetypes
[
12:45pm
]
balunasj
:
alexsmirnov: regarding - May be build/t/t/b[checkstyle,assembly,archetypes] ? - the archetypes are end user consumable, and shoud not be in /build
[
12:45pm
]
alexsmirnov
:
Ok, got it.
[
12:46pm
]
balunasj
:
alexsmirnov: but assembly core, or template - yes
[
12:46pm
]
alexsmirnov
:
So CDK should contain component project archetypes, and UI ones for web projects.
[
12:46pm
]
balunasj
:
alexsmirnov: yes to component project archetyes
[
12:47pm
]
alexsmirnov
:
Seems good.
[
12:47pm
]
balunasj
:
alexsmirnov: example "UI ones for web projects" a bit more
[
12:47pm
]
balunasj
:
please/
[
12:47pm
]
balunasj
:
please ?
[
12:47pm
]
alexsmirnov
:
we already have archetypes that create war with RichFaces library.
[
12:48pm
]
nbelaevski
:
themes, plug-n-skin can be example
[
12:48pm
]
balunasj
:
alexsmirnov: those are the ones I mean for /archetype
[
12:49pm
]
balunasj
:
Alex_Kolonitsky: regarding We have a core/dist module for building core-api and core-impl. Should we create separate assembler for each module?
[
12:49pm
]
balunasj
:
I think we covered that above as well
[
12:50pm
]
Alex_Kolonitsky
:
yes
[
12:50pm
]
balunasj
:
nbelaevski: lets talk about the ui components and the API ideas you started above
[
12:51pm
]
nbelaevski
:
balunasj: ok
[
12:51pm
]
balunasj
:
nbelaevski: can you outline what you are thinking while I take a bio break
[
12:51pm
]
nbelaevski
:
sure
[
12:52pm
]
nbelaevski
:
we have component-related API and framework-related API in the project
[
12:52pm
]
nbelaevski
:
example of the first can be Event/Listener pair
[
12:52pm
]
nbelaevski
:
so, in order to keep our API more stable, we may want to split this into .jar files
[
12:53pm
]
nbelaevski
:
richfaces-api & richfaces-components-api
[
12:54pm
]
pyaschenko left the chat room. (Quit: Leaving.)
[
12:54pm
]
nbelaevski
:
also separation of components code into API & ui code should be considered as requirement for assembler
[
12:55pm
]
nbelaevski
:
that's all for now
[
12:55pm
]
balunasj
:
nbelaevski: richfaces-api.jar is required
[
12:55pm
]
balunasj
:
richfaces-component-api I think is a good idea
[
12:56pm
]
balunasj
:
and follows with the idea from seam that every module has a well defined API
[
12:56pm
]
alexsmirnov
:
nbelaevski: the only think: I prefer not to multiply the number of jars in distribution. components-api seems our internal build trick.
[
12:56pm
]
balunasj
:
this is actually a requirement from JBoss
[
12:57pm
]
balunasj
:
alexsmirnov: iirc we also discussed times when the API might be needed in different location in the EAR correct?
[
12:57pm
]
nbelaevski
:
alexsmirnov: there are pros and cons
[
12:57pm
]
balunasj
:
alexsmirnov: I asked pete and lincoln about this
[
12:57pm
]
nbelaevski
:
3rd-party developers does not need to depend on components API like TreeNode or TreeDataModel
[
12:57pm
]
balunasj
:
and they prefer to have more jars - but that is also what the project wide bom can help with
[
12:58pm
]
nbelaevski
:
but they can reuse our interfaces or annotations like AjaxOutput, so from this point of view it's good to have extra module
[
12:59pm
]
nbelaevski
:
plus this gives better isolation of changes between framework & ui
[
12:59pm
]
balunasj
:
nbelaevski: so at what level would you break this down
[
12:59pm
]
balunasj
:
nbelaevski: each component, or each t/b/t by type?
[
1:00pm
]
nbelaevski
:
I like t/b/t by type more
[
1:00pm
]
balunasj
:
nbelaevski: ok - that might also help identify common api that can be used across
[
1:00pm
]
nbelaevski
:
balunasj: yes
[
1:01pm
]
balunasj
:
so there would be a richfaces-ui-input-api.jar
[
1:01pm
]
balunasj
:
richfaces-ui-input-impl.jar
[
1:01pm
]
balunasj
:
right?
[
1:01pm
]
balunasj
:
that could be "shaded" into a single one for large releases
[
1:01pm
]
balunasj
:
or consumes separately?
[
1:02pm
]
nbelaevski
:
yes, "shaded" for large releases
[
1:02pm
]
nbelaevski
:
but with ability to consume separately
[
1:02pm
]
balunasj
:
that is what I think we need
[
1:03pm
]
balunasj
:
ok - any other comments, or questions ?  I think 2 hours for a meeting is long enough
[
1:03pm
]
balunasj
:
I'll update the wiki page based on all of this
[
1:04pm
]
balunasj
:
although I may breakup into project structure, and module structure
[
1:05pm
]
nbelaevski
:
good, thanks
[
1:06pm
]
balunasj
:
ok guys thanks - I think we covered alot today