On 22 September 2011 21:29, Simone Tripodi <simonetrip...@apache.org> wrote: > That sounds be a case that the component needs to override the > assembly-plugin configuration and define its own assembly descriptors
No. I see no benefit in hiding the assembly descriptor contents in a jar. They are not sufficiently standard or obvious that it makes sense to do so. There is potentially some benefit in defining the standard descriptor file *names* in the parent, because just about all Commons components use them. We already define the assembly plugin in Commons Parent. > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
