The "bad metadata" problem..... sigh........ crap in -> crap out
Seriously, remote resources does have the ability to use a supplements file to provide supplemental information to the dependencies to fill in the gaps that are missing. Ideally, all the poms would be perfect and it wouldn't be needed, but that's not likely to happen soon. :-( That said, the more work that goes into maintaining a supplements file, the less value the remote-resources has unless the supplements can be shared across projects as well. As an example, in CXF, we keep the supplements in a special jar that contains a bunch of build tools things (checkstyle rules, pmd rules, couple other minor things, etc...): http://svn.apache.org/repos/asf/incubator/cxf/trunk/buildtools/src/main/resources/ The parent pom for all our "jar" projects has: <plugin> <artifactId>maven-remote-resources-plugin</artifactId> <version>1.0-beta-2</version> <dependencies> <dependency> <groupId>org.apache.cxf</groupId> <artifactId>cxf-buildtools</artifactId> <version>${project.version}</version> </dependency> </dependencies> <executions> <execution> <goals> <goal>process</goal> </goals> <configuration> <resourceBundles> <resourceBundle>org.apache:apache-incubator-disclaimer-resource-bundle:1.1</resourceBundle> <resourceBundle>org.apache:apache-jar-resource-bundle:1.3</resourceBundle> </resourceBundles> <supplementalModels> <supplementalModel>notice-supplements.xml</supplementalModel> </supplementalModels> <properties> <addLicense>true</addLicense> <addArtifact>true</addArtifact> <projectName>Apache CXF</projectName> </properties> </configuration> </execution> </executions> </plugin> Thus, all the 40+ jar projects get the notice-supplements to fill in all the unknowns. Maybe we need a "supplements" jar in central that contains supplements for ALL the crap in central that is broken so everyone could use it. Could be a huge jar though. Dan On Monday 14 January 2008, Rahul Akolkar wrote: > <snip/> > > That might be a reasonable segue into the operational side of things > and the practical difficulties in using the tool. > > My first experiences produced less-than-desired results, some of that > is captured in my earlier comments on COMMONSSITE-21 [1] (it may be > possible to read through without following the pointer). > > The fact that the content generated is a function of various artifacts > (primarily poms IIUC) in the repository(ies) has some tedious > side-effects. > > For example, in the generated notice attached to that JIRA issue > (credits to Niall, IIRC) we get: > > <notice-snippet> > > This product includes/uses software(s) developed by 'an unknown > organization' - Unnamed - > commons-beanutils:commons-beanutils:jar:1.7.0 > - Unnamed - oro:oro:jar:2.0.8 > > </notice-snippet> > > As a RM, that generates a queasy feeling. The specifics of this > generation are uninteresting (we know why beanutils shows up the way > it does, what it will take to fix it etc.). > > Heres a very incomplete list of other "metadata" problems: > * The organization {name, uri} pairs are frequently inconsistent. > This results in vacuous groupings. > * Some of the URIs have expressions (see maven-jar-plugin v2.2 that > triggered this thread -- it has ${pom.artifactId.substring(8)} > percolating into the notice). > > These are bad practices showing through, but the fact remains that if > any of these show up in the generated content, it could be a > significant detour to get that corrected the right way. The need to > beat other / dependency artifacts into shape becomes a hurdle. > > IOW, while asymptotically the tool will gravitate to producing good > results as more of these things get fixed, ATM there are > above-mentioned difficulties. I am interested in knowing what thought > has gone into this, since others may have mulled over this for longer. > > -Rahul > > [1] http://issues.apache.org/jira/browse/COMMONSSITE-21 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
