That sounds be a case that the component needs to override the assembly-plugin configuration and define its own assembly descriptors
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Sep 22, 2011 at 10:12 PM, sebb <seb...@gmail.com> wrote: > On 22 September 2011 20:17, Simone Tripodi <simonetrip...@apache.org> wrote: >> 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? > > As Phil points out, if the descriptors are hidden away, then it's much > harder to work out what's happening when the archives don't contain > what you expect. > >> Just my 2cents, >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Thu, Sep 22, 2011 at 8:58 PM, sebb <seb...@gmail.com> wrote: >>> On 22 September 2011 19:44, Simone Tripodi <simonetrip...@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 <seb...@gmail.com> wrote: >>>>> On 22 September 2011 18:21, Phil Steitz <phil.ste...@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-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
