qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Vinoski <vino...@iona.com>
Subject Re: maven
Date Fri, 08 Sep 2006 06:16:15 GMT
On Sep 7, 2006, at 8:36 PM, Carl Trieloff wrote:

> Steve Vinoski wrote:
>> Not to start a protracted Maven war, but the benefits of Maven are  
>> many. In no particular order:
> (I would not classify my last mail as an anti Maven mail)

You said Maven doesn't help us at this stage. In response gave 10  
good reasons why it does.

>>
>> 1. Using it shows us as good Apache community citizens, as many  
>> new projects around here use it.
> Ant is also Apache

Yes, and if it were truly sufficient, I bet Apache wouldn't host  
Maven as well.

>> 2. Using the regular Maven directory structure enables new  
>> contributors to easily get up to speed.
>> 3. It easily allows us to manage dependencies, which granted we  
>> currently have few of (though more than I initially thought), but  
>> that number will grow, for example as new persistence solutions  
>> are introduced.
> Not for all our stuff today - issues around things like Mina

Not a problem at all. The version of mina we use is currently checked  
into svn, so populating your local m2 repository with a copy of it is  
a single simple maven command. And given that it's Apache, we can  
probably get their snapshot of what we use into the Apache m2  
repository, if it's not already there. In fact, if they also use  
Maven, getting it there would literally take them only a minute or two.

>> 4. It enables us to easily produce snapshots and releases into the  
>> Apache repository so that other projects can be based on us.
>> 5. It gives us simple set up for Eclipse and IntelliJ workspaces.
>> 6. It gives us code coverage.
> Not true, PMD, CheckStyle, etc integrations give us this

And how does that differ in substance from what I said? Yes, I know  
that such capabilities are delivered by plugins -- indeed, the fact  
that plugins deliver such capabilities for maven is another plus, as  
it means the system is highly flexible and extensible.

>> 7. It gives us the ability to turn on code style checking at build  
>> time, assuming we want that someday (it's definitely got my vote).
> Not a maven exclusive

Again, not sure why you would even argue this. I never said it was an  
exclusive. I would point out, though, that such things are generally  
easier with maven than anything else I've seen.

>> 8. We can easily pick up Maven plugins and use them at will,  
>> without having to write Ant targets or import specialized Ant task  
>> classes.
>> 9. It makes creating distributions dead easy.
>> 10. It's much faster and more scalable than Ant.
>>
>> I can come up with more good reasons if you like.
>>
>> Not to mention that the sooner we move to it, the less work it  
>> will be. If we wait, the code base will grow and just make it that  
>> much harder to move to a new build system and directory structure.
>>
>> IONA has a number of projects, both open source and company- 
>> internal, using Maven, and it's been working great for all of  
>> them. Given my long history and experience with software  
>> configuration management and build systems, I am generally  
>> skeptical of tools like Maven that come along and make lots of  
>> promises. However, my hat is definitely off to the Maven guys,  
>> it's a great system that delivers the goods.
>
> I can point out that I introduced Maven to IONA,

And this is relevant how?

> so yes I know the benefits of Maven and I like it a LOT. So Steve I  
> don't see this mail as a war, just the practicalities of what I  
> have to do to make the code donation and move the project to  
> Apache. I would like to complete this
> process so that I can know the apache svn is correctly imported and  
> we can create a baseline build and make sure all is good. If we go
> to Maven I want us to discuss the issues, and how we want it set up  
> and make sure that works for all.

You seem to think that I'm charging off and I'm going to commit a  
Maven system without consulting anyone. I thought I already made it  
clear I would wait until the move to Apache, and in general I would  
never commit anything like this that the group doesn't approve, so I  
don't know why you keep bringing this up. I'll write up and share the  
report as I already promised, but meanwhile, spreading such FUD isn't  
helpful.

Frankly, neither the current build system nor the Maven-based one I'm  
working on is all that complicated. I've written build systems for  
much more complicated and significantly larger systems than this one.  
I understand and completely agree with the desire to keep it all  
stable, and of course will do all I can to help ensure that  
stability, but let's please not exaggerate the size or complexity of  
this build system in an attempt to make this task appear harder than  
it really is.

> For example, I want to see the impact on the dir structure and look  
> if we want to make the C++ make structure match for example,want to  
> know what we are going to do with Mina, etc... I don't think Maven  
> is going to solve all the issues, and want us to make sure the ones  
> that is does not we know how we are going to solve them.

Just to be clear, Maven will not solve anything for C++ or other  
languages, just as Ant does nothing for them today either. C++ uses  
make, while Ruby and Python don't really need such things. I'd say it  
doesn't make sense to have C++ mimic the Java directory structure, as  
C++ has no need for the deep package directories that Java forces.  
All four languages mentioned have their own conventions, and we  
should follow them for each language.

--steve

>
> Regards
> Carl.
>
>
>>
>> More details will be forthcoming as I progress my Maven work for  
>> Qpid.
>>
>> --steve
>>
>> On Sep 7, 2006, at 5:40 PM, Carl Trieloff wrote:
>>
>>>
>>> Would like to park the maven discussion until Steve comes back  
>>> with something that we can concretely
>>> discuss. My view is Maven does not help us any at this stage, and  
>>> there are better uses of time right
>>> now on the code base, (but that is my view) and I might change it  
>>> after Steve comes back with his
>>> research.
>>>
>>> Regards
>>> Carl.
>>>
>>> steven.x.shaw@jpmorgan.com wrote:
>>>> Could be wonderful. Maven makes alot of promises. I really like  
>>>> he IDE file generation. Maven seem popular at Apache.
>>>>
>>>> I did spent a while trying to get Maven 2.0.2 and then 2.0.4  
>>>> working to build Mina here at JPMC. It just wouldn't work. I  
>>>> configured my http proxy. It couldn't download the maven- 
>>>> compiler-plugin I think. At home it worked fine :). I figure  
>>>> that I was having some kind of firewall issue but the error  
>>>> messages leave alot to be desired! I ended up building mina-core  
>>>> with a very short shell script...
>>>>
>>>> Steve.
>>>>
>>>> This communication is for informational purposes only. It is not  
>>>> intended as an offer or solicitation for the purchase or sale of  
>>>> any financial instrument or as an official confirmation of any  
>>>> transaction. All market prices, data and other information are  
>>>> not warranted as to completeness or accuracy and are subject to  
>>>> change without notice. Any comments or statements made herein do  
>>>> not necessarily reflect those of JPMorgan Chase & Co., its  
>>>> subsidiaries and affiliates.
>>>>
>>>> This transmission may contain information that is privileged,  
>>>> confidential, legally privileged, and/or exempt from disclosure  
>>>> under applicable law. If you are not the intended recipient, you  
>>>> are hereby notified that any disclosure, copying, distribution,  
>>>> or use of the information contained herein (including any  
>>>> reliance thereon) is STRICTLY PROHIBITED. Although this  
>>>> transmission and any attachments are believed to be free of any  
>>>> virus or other defect that might affect any computer system into  
>>>> which it is received and opened, it is the responsibility of the  
>>>> recipient to ensure that it is virus free and no responsibility  
>>>> is accepted by JPMorgan Chase & Co., its subsidiaries and  
>>>> affiliates, as applicable, for any loss or damage arising in any  
>>>> way from its use. If you received this transmission in error,  
>>>> please immediately contact the sender and destroy the material  
>>>> in its entirety, whether in electronic or hard copy format.  
>>>> Thank you.
>>>>
>>>
>>>
>>
>


Mime
View raw message