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
