On Nov 15, 2006, at 2:34 PM, Marnie McCormack wrote:
IIRC when Steve initially proposed introducing maven to the project
we had
some debate, but it seems like there might be limitations/constraints
imposed that we didn't understand (as a group).
As the other email thread on maven has already mentioned, these
limitations exist regardless of maven, I believe. Maven simply
enforces them.
I can also see, from Daniel's posts, that other projects who use
maven would
like us to follow suit as it'll make their lives easier.
Very much so.
So, there are pros & cons. What I think would be very helpful
though (as
others have indicated) is a list of the things we can't do with
maven (that
might impact us) ? We can then agree a way round/accept the
limitation/other
as appropriate.
I know there have been a few items discussed in previous threads,
and I'm
not very clear on where these things are at e.g. resolved, tricky but
fixable or really not possible.
So, for example, javadoc inclusion, mina snapshot, etc.
Javadoc is not an issue for maven, i.e., it can easily be done. I
didn't include it yet because I question its value as we currently
implement it. Simply javadoc'ing every class is pointless. What needs
to be javadoc'ed are the classes that users actually use. Tuscany,
CXF, and Yoko do this by building an API jar, which they then javadoc.
The mina snapshot is an issue, as the other email thread is currently
exploring. There is no mina 1.1.0-SNAPSHOT available in the maven
repositories anymore, but I don't know the reason for that. Only the
mina team does. But as I've said, 1.0.0 works for us, and that's the
dependency the mvn branch poms specify.
None of the issues Martin raised are a big deal at all with respect
to maven. I was prepared to fix them all yesterday, in fact.
One way to do make where we are with maven clear would be to raise
JIRAs for
the outstanding items. That way we can all see where we are, and
discuss
anything truly significant.
Can do, but I don't think it makes sense to do that unless it's on
trunk.
It may be that you've already been able to resolve the items on
Martin's
list Steve ? No time pressure from my perspective, just a sense
that we're
perhaps a bit muddy at the moment.
Well, yesterday I spent most of the day arguing in email. Once I saw
the writing on the wall regarding maven and M1, I backed off
aggressively working on it so I could catch up on other stuff.
Also Steve - if you could still do with a hand, JIRAs would be a
good way to
get others involved now that M1 is pretty much done ?
Yep, as soon as maven is on trunk. I guess I should just merge it.
--steve
Regards,
Marnie
On 11/15/06, Martin Ritchie <[EMAIL PROTECTED]> wrote:
I really hope that we don't have to rely on publicly available
releases. What if a bug in one of our dependencies prevents us
releasing because we have to wait for them despite there being a well
used patch available? Do other OS projects just wait for their
dependent projects to release? Does this approach foster a greater
community as you have to help out projects you are dependent on?
Fixing problems and release so that you can focus on your own
projects.
Such a limitation of maven which would have been good to know up
front
before we embarked on maven-ization. I'm really struggling to see
what
maven brings to the table.
On 15/11/06, Steven Shaw <[EMAIL PROTECTED]> wrote:
> I'm sure you can do some kind of artifact:install in order to
put jars
> into your local repository (from your workspace). We could do that
> with MINA and perhaps filecontext.
>
> See the following link under "Installing and Deploying Your Own
Artifacts":
>
> http://maven.apache.org/ant-tasks.html
>
> The Maven experts will need to verify though!
>
> Steve.
>
--
Martin Ritchie
