You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Vladimir Sitnikov <si...@gmail.com> on 2020/02/16 18:03:14 UTC

A case for having pom.xml files: GitHub dependency graph

Hi,

GitHub has a dependency graph feature (see [1]) which can show dependency
information right at the GitHub page.
However, the only way they support Java dependencies is via pom.xml files
(see "Supported package ecosystems" in [1]).

Sample output: https://github.com/javacc/javacc/network/dependencies

It looks like they discover pom.xml by their names only, so the files do
not have to be linked via <modules> or whatever.
Just a bunch of pom.xml would do.

Do you think it is worth committing pom.xml files to the repository?
That is there might be a Gradle task to update pom.xml files which we run
from time to time to update xml files.
I guess it would be fine to have release versions always.

I've committed a couple of pom.xml for fun purposes here:
https://github.com/vlsi/calcite/network/dependencies


[1]:
https://help.github.com/en/github/visualizing-repository-data-with-graphs/listing-the-packages-that-a-repository-depends-on

Vladimir

Re: A case for having pom.xml files: GitHub dependency graph

Posted by Michael Mior <mm...@apache.org>.
I agree with Julian that this will likely just create confusion. It
seems likely that over time GitHub will support other build systems
and this will resolve itself.
--
Michael Mior
mmior@apache.org

Le dim. 16 févr. 2020 à 13:12, Julian Hyde <jh...@gmail.com> a écrit :
>
> No, I think we should single-source. Checking in Pom.xml files will cause confusion whether we are a maven or gradle project.
>
> Julian
>
> > On Feb 16, 2020, at 10:03 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
> >
> > Hi,
> >
> > GitHub has a dependency graph feature (see [1]) which can show dependency
> > information right at the GitHub page.
> > However, the only way they support Java dependencies is via pom.xml files
> > (see "Supported package ecosystems" in [1]).
> >
> > Sample output: https://github.com/javacc/javacc/network/dependencies
> >
> > It looks like they discover pom.xml by their names only, so the files do
> > not have to be linked via <modules> or whatever.
> > Just a bunch of pom.xml would do.
> >
> > Do you think it is worth committing pom.xml files to the repository?
> > That is there might be a Gradle task to update pom.xml files which we run
> > from time to time to update xml files.
> > I guess it would be fine to have release versions always.
> >
> > I've committed a couple of pom.xml for fun purposes here:
> > https://github.com/vlsi/calcite/network/dependencies
> >
> >
> > [1]:
> > https://help.github.com/en/github/visualizing-repository-data-with-graphs/listing-the-packages-that-a-repository-depends-on
> >
> > Vladimir

Re: A case for having pom.xml files: GitHub dependency graph

Posted by Julian Hyde <jh...@gmail.com>.
No, I think we should single-source. Checking in Pom.xml files will cause confusion whether we are a maven or gradle project. 

Julian

> On Feb 16, 2020, at 10:03 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
> 
> Hi,
> 
> GitHub has a dependency graph feature (see [1]) which can show dependency
> information right at the GitHub page.
> However, the only way they support Java dependencies is via pom.xml files
> (see "Supported package ecosystems" in [1]).
> 
> Sample output: https://github.com/javacc/javacc/network/dependencies
> 
> It looks like they discover pom.xml by their names only, so the files do
> not have to be linked via <modules> or whatever.
> Just a bunch of pom.xml would do.
> 
> Do you think it is worth committing pom.xml files to the repository?
> That is there might be a Gradle task to update pom.xml files which we run
> from time to time to update xml files.
> I guess it would be fine to have release versions always.
> 
> I've committed a couple of pom.xml for fun purposes here:
> https://github.com/vlsi/calcite/network/dependencies
> 
> 
> [1]:
> https://help.github.com/en/github/visualizing-repository-data-with-graphs/listing-the-packages-that-a-repository-depends-on
> 
> Vladimir