portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Further Jetspeed-2 development plans
Date Wed, 18 Jul 2007 00:54:41 GMT
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...

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.

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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message