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 <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
