directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [distributions] patch submitted for dist:multiproject
Date Fri, 14 Jan 2005 02:25:07 GMT
Hey I got another good idea for the dist plugin.  Instead of manually 
putting a navigation.xml link for the combined apidocs on multiprojects 
we can have dist:multiproject add it as a report.  Don't know if this 
can be done since reports are usually plugins themselves and it would be 
weird doing a maven-dist-plugin report.  Hmmm this is way out there for 
me.  Any advice from maven folks?

Alex Karasulu wrote:

> Phil Steitz wrote:
>> Alex Karasulu wrote:
>>> Phil,
>>> I submitted the patch for the dist plugin that does mutliproject 
>>> distros.  You can download and apply the patch to trunk and install 
>>> to test.  I have modified naming and will checkin shortly to make 
>>> the dist:mp work. Give it a try.
>>> Cheers,
>>> Alex
>> Works like a charm!
>> I do have a couple of comments. I will summarize this to the ticket, 
>> but want to talk about it here a little, because its partly a 
>> question of what goes in the patch vs our maven.xml.
>> 1) The bit to copy LICENSE, disclaimer, etc. is *really* important to 
>> us, but probably does not belong in the plugin, at least as it is.  
>> The behavior should be the same as the normal (non-multi) plugin.  
> Looks as though the normal plugin does hardcode copying things like 
> LICENSE.txt, README.txt etc.
>> Could be the best thing to do is to expose a property (also for the 
>> normal dist plugin) that is a list of files to pull in the top level 
>> (or alternatively, to exclude with the default to pull everything).  
>> Or omit it altogether but rig it so it is easy to do in maven.xml.
> Much better approach definately than hard coding these copies.  I 
> think we can still include some default things though or have this 
> includes property set to certain values within the 
> file.  What do you think Brett?
>> 2) The consolidated javadoc script includes the classpath element 
>> that I had, which does not really work unless you have - sic - 
>> executed an ant build first to load all of the dependent jars.  It 
>> doesn't make any difference to the javadoc generated in naming, so I 
>> did not really fuss with it; but it might be worth figuring out for 
>> the plugin.  The "right" way would be to somehow make maven's 
>> internal classpath available, or I guess the union of the subproject 
>> classpaths.  I have no idea how to do this.
> Hmmm I don't either perhaps Brett can chime in.
>> Thanks again for doing this.
> Np but I couldn't have done it without Brett answering my questions 
> mainly about Jelly.
> Cheers,
> Alex

View raw message