qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Vinoski <vino...@iona.com>
Subject Re: svn commit: r475297 - /incubator/qpid/trunk/qpid/java/broker/src/org/apache/qpid/server/Main.java
Date Wed, 15 Nov 2006 21:01:03 GMT
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  

> 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.


> Regards,
> Marnie
> On 11/15/06, Martin Ritchie <ritchiem@apache.org> 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 <steshaw@gmail.com> 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

View raw message