OK, one more idea :-)
Jetspeed could have an expressive schema for its spring configuration
file(s) using xbean-spring. Activemq and servicemix are the main
users of this today. What you do is:
-- annotate your spring "beans" with javadoc style psuedo-annotations
-- run the maven xbean spring plugin to generate one or more schemas
for the configuration (plus some other configuration metadata files,
and documentation).
-- write the spring configuration in the language defined by the schema
-- change one line in the spring startup stuff.
Here's a link...
http://geronimo.apache.org/xbean/custom-xml.html
This is pretty easy to do. I converted the apache directory spring
config file to xbean spring in a couple of days, including figuring
out how xbean spring works and extending it to deal with lots of
source modules.
this does pretty much depend on a working (i.e. maven 2) build :-)
(sorry, couldn't resist)
As far as the m2 build goes....
I'm not sure that it's a good idea to insist that current portal m1
and m2 customization procedures continue to work unmodified. I would
prefer to have as a goal that they are easier to understand and use
and are less coupled to the actual jetspeed build.
thanks
david jencks
On Jul 17, 2007, at 4:31 PM, Ate Douma wrote:
Edgar, David,
First of all, both thanks a lot for your input and offer to join in.
I've included both your responses and added some additional
comments inline further below.
I'd like to propose we start discussing and designing possible
solutions before hacking away at the code.
Some of these features potentially are going to have big impact
throughout the code base (like moving to JPA as David proposed),
and I think for those type of changes we need full support from
everyone involved and a clear planning who is going to do what,
when and with which intended result.
Probably the biggest step to take though is rewriting our current
build environment to a new and clean maven-2 only based setup.
Already more than a year ago, David also brought this up but at
that time we were not ready yet for several reasons.
I really think now is the time though to do this and also that we
should do it now before starting anything else.
Earlier this year I started out trying to create a new m2 build
environment in the J2-M2-REDUX branch based on the 2.1 release.
Because of lack of time, I haven't been able to complete my mission
to build a complete portal, provide separate assemblies for
different custom configurations and setups, and a migration path
for our large (and often paying customers) community which still
run maven-1 based custom portal projects.
I started from scratch, throwing out everything from our current
build environment, and building it up again bit by bit.
I have no real intention to go back to that branch though now. The
current code base already is too far ahead of the base line for
that branch to even consider merging it back in.
But I invite anyone interested to look at what I've done there so
far and review if its feasible to redo it and expand on as the
bases for our new maven-2 only build environment in the trunk.
Which brings me back to a comment I made above.
I will send out a separate email to this list describing my
intended solution for the J2-M2-REDUX branch, the problems I
encountered as well as how I tried to solve them. This maybe can
use as starting point for properly discussing how to provide a
proper m2 build environment.
Repeating and continuing the solution I started, or going at it a
completely different way, I don't mind. As long as we end up with a
feasible solution which covers important goals like a migration
path for our current m1 and m2 users.
So, I propose we proceed with discussing and designing this major
step on the list first, and do the same for the other big features/
changes we would like to do.
This way, our whole community will be able to chime in and join the
effort if they are interested and we'll be much better ensured
we're on the right track.
I initially thought maybe we should use the Wiki for this. But my
feeling is that the Wiki is great for providing and linking
information bits, but less so for discussion and design tasks. Yet,
if anyone feels better at using the Wiki (too), by all means, go
ahead.
I also propose we follow 2 simple guidelines for our list based
design discussions:
- use a subject clearly indicating which feature is under
discussion, like: [M2 build design] <optional sub topic>
- keep the design thread on topic: don't hijack a thread for a
different/new subject, open a new thread if needed instead
Tomorrow evening I'll try to kick start the [M2 build design]
thread, but if someone has a dying need to beat me to it, be my
guest ;)
Regards,
Ate
p.s. I'll be away for a 3 week summer holiday starting this
Saturday. So although I'd like to help kick start the [M2 build
design], I'll be 100% offline from Saturday until Aug. 9th. Would
be great to come back and see a lot has happened already by then ;)
<giant snip>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
