You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Ate Douma <at...@douma.nu> on 2007/07/18 13:24:55 UTC
Re: Further Jetspeed-2 development plans
David Jencks wrote:
> 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)
So lets get that out of the way first.
>
> 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.
That's not what I said or intended, and neither what I think will be even remotely possible.
But we need to deliver clear documentation and instructions how an existing m1 or m2 based custom portal project can be migrated to our new solution.
And maybe even provide tooling and/or scripting support for it if possible.
> 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.
Definitely, but we can't ignore our current community and users and their "legacy" build environments, so supporting them is very important too.
Regards,
Ate
>
> 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: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Further Jetspeed-2 development plans
Posted by Ate Douma <at...@douma.nu>.
Timony, Michael wrote:
> What version of Maven2 are you planning on targeting to use for
> building?
As the plan is to start from scratch, I see no reason not to use the latest release 2.0.7, unless someone must have knowledge of some blocking issues with it.
Ate
>
> I've noticed that versions of M2 require different artifacts in the
> user's local repository. Such as Maven 2.0.7 looking for
> plexus-utils-1.1.jar which Maven 2.0.4 doesn't require. So it might make
> the build process easier to debug if you standardise on a version of
> Maven 2 to use.
>
> Mick Timony
>
> -----Original Message-----
> From: Ate Douma [mailto:ate@douma.nu]
> Sent: Wednesday, July 18, 2007 7:25 AM
> To: Jetspeed Developers List
> Subject: Re: Further Jetspeed-2 development plans
>
> David Jencks wrote:
>> 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)
> So lets get that out of the way first.
>
>> 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.
> That's not what I said or intended, and neither what I think will be
> even remotely possible.
>
> But we need to deliver clear documentation and instructions how an
> existing m1 or m2 based custom portal project can be migrated to our new
> solution.
> And maybe even provide tooling and/or scripting support for it if
> possible.
>
>> 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.
> Definitely, but we can't ignore our current community and users and
> their "legacy" build environments, so supporting them is very important
> too.
>
> Regards,
>
> Ate
>
>> 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: jetspeed-dev-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
RE: Further Jetspeed-2 development plans
Posted by "Timony, Michael" <Mi...@FMR.COM>.
What version of Maven2 are you planning on targeting to use for
building?
I've noticed that versions of M2 require different artifacts in the
user's local repository. Such as Maven 2.0.7 looking for
plexus-utils-1.1.jar which Maven 2.0.4 doesn't require. So it might make
the build process easier to debug if you standardise on a version of
Maven 2 to use.
Mick Timony
-----Original Message-----
From: Ate Douma [mailto:ate@douma.nu]
Sent: Wednesday, July 18, 2007 7:25 AM
To: Jetspeed Developers List
Subject: Re: Further Jetspeed-2 development plans
David Jencks wrote:
> 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)
So lets get that out of the way first.
>
> 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.
That's not what I said or intended, and neither what I think will be
even remotely possible.
But we need to deliver clear documentation and instructions how an
existing m1 or m2 based custom portal project can be migrated to our new
solution.
And maybe even provide tooling and/or scripting support for it if
possible.
> 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.
Definitely, but we can't ignore our current community and users and
their "legacy" build environments, so supporting them is very important
too.
Regards,
Ate
>
> 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: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org