Hi,
given that github provides a zip and tar.gz of each tag already, why do we even bother
building them with maven?
It is also error prone, the src.xml has been missing the kml module for all the 2.4.x life,
and in 2.5.x, due to the gs- prefix rename, it was missing pretty much everything
Can’t we have the release scripts tag, download the zip, and then push it to sourceforge
instead?
Agreed, +1 on just grabbing the source zip directly from github. The only difference would be that the github zip would contain absolutely everything. But I don’t see that as an issue.
Hi,
given that github provides a zip and tar.gz of each tag already, why do we even bother
building them with maven?
It is also error prone, the src.xml has been missing the kml module for all the 2.4.x life,
and in 2.5.x, due to the gs- prefix rename, it was missing pretty much everything
Can’t we have the release scripts tag, download the zip, and then push it to sourceforge
instead?
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
A number of IDE will automatically download the source module from the maven repos for listed dependencies. This is extremely useful people who need to quickly debug an issue who are unfamiliar with the geoserver code base. I was in this position often as I came up to speed with GeoServer.
I would advocate keeping it.
What is so fragile with bundling source? Of all maven release operations I would think this is the simplest…
Agreed, +1 on just grabbing the source zip directly from github. The only difference would be that the github zip would contain absolutely everything. But I don’t see that as an issue.
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
Hi,
given that github provides a zip and tar.gz of each tag already, why do we even bother
building them with maven?
It is also error prone, the src.xml has been missing the kml module for all the 2.4.x life,
and in 2.5.x, due to the gs- prefix rename, it was missing pretty much everything
Can’t we have the release scripts tag, download the zip, and then push it to sourceforge
instead?
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
On Mon, Jan 20, 2014 at 6:59 PM, Tom Kunicki <tkunicki@anonymised.com>wrote:
A number of IDE will automatically download the source module from the
maven repos for listed dependencies. This is extremely useful people who
need to quickly debug an issue who are unfamiliar with the geoserver code
base. I was in this position often as I came up to speed with GeoServer.
I would advocate keeping it.
What is so fragile with bundling source? Of all maven release operations
I would think this is the simplest...
I believe you're misunderstanding which src zip we are talking about. The
src zip for each jar is going to be kept.
Here we are talking about the zip of all the sources, it's one of the
release artifacts we upload to sourceforge , and can be only downloaded
from there
A number of IDE will automatically download the source module from the maven repos for listed dependencies. This is extremely useful people who need to quickly debug an issue who are unfamiliar with the geoserver code base. I was in this position often as I came up to speed with GeoServer.
I would advocate keeping it.
What is so fragile with bundling source? Of all maven release operations I would think this is the simplest…
I believe you’re misunderstanding which src zip we are talking about. The src zip for each jar is going to be kept.
Here we are talking about the zip of all the sources, it’s one of the release artifacts we upload to sourceforge , and can be only downloaded from there
It is also error prone, the src.xml has been missing the kml module for
all the 2.4.x life,
and in 2.5.x, due to the gs- prefix rename, it was missing pretty much
everything
And it is also huge if you run assembly:attached in a workspace where geoserver was built, as all target directories are included: https://jira.codehaus.org/browse/GEOS-6168
Kind regards,
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
Hi,
given that github provides a zip and tar.gz of each tag already, why do we even bother
building them with maven?
It is also error prone, the src.xml has been missing the kml module for all the 2.4.x life,
and in 2.5.x, due to the gs- prefix rename, it was missing pretty much everything
Can’t we have the release scripts tag, download the zip, and then push it to sourceforge
instead?
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk