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:[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
