2) Multi-project
JCI uses the maven2 multi-project feature for modularity. Now this
makes it the first multi-project release in commons and question is
how we should handle versioning and voting procedure. In theory it
would be good to be able to have individual releases of the modules.
Suggestions are welcome.
Attributes had 2 jars - and a build that was irritating because of it.
ie) you didn't just go 'lah! build' in the standard way.
Jelly has a bajillion jars. I assume it's an m1 multiproject.
BeanUtils has a couple of jars; but the optional one is more of a
thick-child-project. I seem to recall it being a pain to build.
So not the first.
Well ...but the first one with a maven2 build - no? :)
Rahul's point on keeping versions in sync is well made.
3) Site
Another thing that comes with the multi-module is that
(unfortunately) maven's multi-project reporting facilities still
suck! At the moment this still means that some of reports are just
empty. The only other option would be to have a sub-site for each
individual model - but for JCI that would be just overkill. Please
just have a look what needs to be changed for a release.
http://jakarta.apache.org/commons/sandbox/jci/
Seems pretty bad - no information about the N different subcomponents,
and the dependency page claims there are no deps (really?). I guess
you've not written the site itself yet? :)
Well, the problem is that the sub project are basically just a few
classes. Having a complete site for every sub-project feels more
confusing to me than aggregating it on the main site. BUT as you can
see aggregation does not work for all reports and e.g. the
dependencies are listed for the parent pom - not the core or the sub
projects. And therefor are empty.
I can put a site online with all the sub projects. And then you guys
can let me know if you prefer that.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
