commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [all][discuss] redundant assembly descriptors
Date Thu, 22 Sep 2011 19:17:11 GMT
for the components I've been touching, they create the same assemblies:

 * bin = LICENSE + NOTICE + RELEASE-NOTES + jar (+ dependencies) + javadoc
 * src = LICENSE + NOTICE + RELEASE-NOTES + src + pom

wouldn't be wiser having a "least common multiple" - and override it
where needed, like daemon for example - instead of having
redundancies?
Just my 2cents,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Thu, Sep 22, 2011 at 8:58 PM, sebb <sebbaz@gmail.com> wrote:
> On 22 September 2011 19:44, Simone Tripodi <simonetripodi@apache.org> wrote:
>> Hi Seb,
>> you got me, we distribute assemblies descriptors as jar, then define a
>> default assembly-plugin configuration in the parent - components that
>> need define their own assemblies, are still free to do it.
>> If you don't see any blocking issue, I could start working on it.
>
> I don't see any point in creating the jar; most components use the
> same decriptor file names, but do they use the same descriptor file
> contents?
> I suspect many (most?) components will have to override the setting.
>
> Also, as Phil has pointed out, it's going to be hard to know what's in
> the descriptor files if they are buried in a jar.
>
>> Just let me know, have a nice day!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Thu, Sep 22, 2011 at 7:46 PM, sebb <sebbaz@gmail.com> wrote:
>>> On 22 September 2011 18:21, Phil Steitz <phil.steitz@gmail.com> wrote:
>>>> On 9/22/11 7:17 AM, Simone Tripodi wrote:
>>>>> Hi all guys,
>>>>> al the components I have been touching (digester, discovery, chain,
>>>>> functor, dbutils, pool2, graph, meiyo) have exactly the same assembly
>>>>> descriptors and assembly plugin configuration.
>>>>>
>>>>> I honestly think that we could do a little step of improvement and
>>>>> remove that redundancy.
>>>>>
>>>>> My proposal is using the 'sharing assembly descriptors'[1] technique,
>>>>> creating a new component containing the -bin and -src descriptors,
>>>>> then configuring the assembly plugin in the parent in the way it
>>>>> reuses the shared descriptors.
>>>>> Components that need a different configuration, they just override the
>>>>> assembly plugin configuration to get custom assembly descriptors as
>>>>> input.
>>>>
>>>> For [pool], I would prefer to keep the descriptors in the project.
>>>> Duplication is less concerning to me personally than the need to
>>>> look at the parent to figure out what is going on or to control
>>>> which files exactly go into the distributions.
>>>
>>> Perhaps we could define standard descriptor names in the parent pom
>>> (bin.xml, src.xml).
>>> Each component would then have to provide bin.xml and src.xml as now,
>>> but would not need to configure the assembly plugin.
>>>
>>> Components that have additional assembly descriptors would of course
>>> need to configure the assembly plugin locally.
>>>
>>>> Phil
>>>>>
>>>>> I feel comfortable with that approach having experienced it in
>>>>> MyBatis[2] (formerly Apache iBATIS)
>>>>>
>>>>> WDYT?
>>>>> It would help us on saving both (even if trivial) space and time
>>>>> (configured once, reused everywhere).
>>>>>
>>>>> Please just let me know, I can take care of it!
>>>>> All the best, have a nice day,
>>>>> Simo
>>>>>
>>>>> [1] http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html
>>>>> [2] http://code.google.com/p/mybatis/source/browse/#svn%2Fsub-projects%2Fbase-bundle-descriptor%2Ftrunk
>>>>>
>>>>> http://people.apache.org/~simonetripodi/
>>>>> http://www.99soft.org/
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message