Maybe having them externalized would be better?
Not completely sure how much they are re-usable for different GeoServer
versions.
Did not understood if we plan to create automation for GeoServer only or
for GeoTools too.
Regards,
Alessio.
-------------------------------------------------------
Ing. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: (+39) 0584 96.23.13
fax: (+39) 0584 96.23.13
mobile:(+39) 331 62.33.686
http://www.geo-solutions.it
http://geo-solutions.blogspot.com
http://www.linkedin.com/in/alessiofabiani
https://twitter.com/alfa7961
http://twitter.com/geosolutions_it
-------------------------------------------------------
On Mon, May 14, 2012 at 7:23 PM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Mon, May 14, 2012 at 6:53 PM, Justin Deoliveira <jdeol...@opengeo.org>
> wrote:
> > Hi folks,
> >
> > I wanted to do a quick poll of where people think the build and release
> > scripts should go. I can see three options.
> >
> > 1. Under the src tree. Maybe in a directory called "build". We could
> throw
> > them under "maven" which is where some current build stuff lives... or
> maybe
> > even rename that directory to "build"
> >
> > 2. Outside of the main source tree parallel to doc, data, and src in a
> > folder called "build"
> >
> > 3. In a separate github repo.
> >
> > A bit more info about what the contents of this folder will be. At first
> it
> > should be some release scripts, something like files named:
> >
> > release.sh -> build the release and prep all the artifacts, putting them
> to
> > some staging ground
> > release_publish.sh -> upload the artifacts to final destination, and do
> any
> > other meta tasks
> >
> > Eventually I would like to put all the scripts currently living in hudson
> > config in this same directory. So eventually there should be stuff like:
> >
> > build.sh -> main build script
> > build_nightly.sh -> nightly build script
> > build_deploy.sh -> deployment script
> >
> > And so on.
> >
> > Thoughts?
>
> How about:
> doc/
> src/
> hudson/
>
> The scripts would be part of the build, yes, but they would also be
> hudson specific
> and may end up referring something particular about that build machine
> (though we should probably externalize that in such case)
>
> Just thinking out loud, any of the solutions you proposed is fine to me as
> well
>
> Cheers
> Andrea
>
>
> --
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax: +39 0584 962313
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
