ok for me is enough to stop the discussion here, no needs to continue http://people.apache.org/~simonetripodi/ http://www.99soft.org/
On Thu, Sep 22, 2011 at 10:40 PM, sebb <seb...@gmail.com> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
