After ripping out my hair for a few days I can still not get a release to
go.
Release is now gone
Javadoc seems to be completley broken.
Agreed, I got a null pointer exception from our magic plug-in. I have updated the release instructions to *not* include javadoc generation until such time as it works.
problems with the following
modules:
plugin/epsg-hsql
did not find a problem.
ext/widgets-spring
did not find a problem.
ext/go
did not find a problem.
ext/shape
Was missing an svn:ignore on a generated index file.
And there could be more, I gave up after 4 errors. So we are stuck without
javadocs, and if we want a release we have to manually do everything,
which is a pain.
Ended up reading the release:perform instructions, by default this goal does "deploy" and "site-deploy". The wiki has been updated
with an example showing how to get it to do only "deploy".
I will not have any more time to put toward this until next week. I should
also note that GeoServer is not making it project policy to release
against official geotools releases due to the overhead of releasing
geotools and not having a working release process.
Please make use of yesterdays release, geotools needs to (and will fix) the overhead of making a release. I would like to set things up so
projects like uDig and GeoServer can ask for a release given one weeks notice and expect to see results.
With respect to the "larger" problem of why the release process was broken.
- QA tools added to the build chain, and only tested for maven install (rather then full release process)
- files left on the 2.2.x branch that were needed for assembly of release artifacts
- focus on javadocs destracted from real need to produce results
- lack of communication (both wiki instructions and email on release progress)
I am sure we can do better next time
Jody
PS. I am working on a steering document that I will try and share with the list shortly, feedback from the geoserver community in terms of expectations is important and needed.
Thanks for helping out jody, your qa on the build system was excellent
and very much needed. Sometimes I get so involved in battling with maven
that I forget to keep my head above water
However, I think its time for some clean up on the build system. While
this workaround gets us a release its not really acceptable. Adrian has
volunteered to help us with releases, but because he is not a maven
expert he cant.
-Justin
Jody Garnett wrote:
Justin Deoliveira wrote:
Hi all,
After ripping out my hair for a few days I can still not get a release to
go.
Release is now gone
Javadoc seems to be completley broken.
Agreed, I got a null pointer exception from our magic plug-in. I have
updated the release instructions to *not* include javadoc generation
until such time as it works.
problems with the following
modules:
plugin/epsg-hsql
did not find a problem.
ext/widgets-spring
did not find a problem.
ext/go
did not find a problem.
ext/shape
Was missing an svn:ignore on a generated index file.
And there could be more, I gave up after 4 errors. So we are stuck without
javadocs, and if we want a release we have to manually do everything,
which is a pain.
Ended up reading the release:perform instructions, by default this goal
does "deploy" and "site-deploy". The wiki has been updated
with an example showing how to get it to do only "deploy".
I will not have any more time to put toward this until next week. I should
also note that GeoServer is not making it project policy to release
against official geotools releases due to the overhead of releasing
geotools and not having a working release process.
Please make use of yesterdays release, geotools needs to (and will fix)
the overhead of making a release. I would like to set things up so
projects like uDig and GeoServer can ask for a release given one weeks
notice and expect to see results.
With respect to the "larger" problem of why the release process was broken.
- QA tools added to the build chain, and only tested for maven install
(rather then full release process)
- files left on the 2.2.x branch that were needed for assembly of
release artifacts
- focus on javadocs destracted from real need to produce results
- lack of communication (both wiki instructions and email on release
progress)
I am sure we can do better next time
Jody
PS. I am working on a steering document that I will try and share with
the list shortly, feedback from the geoserver community in terms of
expectations is important and needed.
Thanks for helping out jody, your qa on the build system was excellent
and very much needed. Sometimes I get so involved in battling with maven
that I forget to keep my head above water
Heh, please send more email - it took me an hour just to figure out where you had gotten stuck.
However, I think its time for some clean up on the build system. While
this workaround gets us a release its not really acceptable. Adrian has
volunteered to help us with releases, but because he is not a maven
expert he cant.
I was asking Richard about this, apparently the maven "release" plugin is *so* close to what we used to do by
hand that he is in favour of using it. The part that failed was javadoc generation, something I am happy to skip
until it is ready (and even then we only *really* need it for major releases).
So I think the current release process (now that we have rescued it from the 2.2.x branch) is fine, and javadocs
can wait on volunteer time.
Jody
-Justin
Jody Garnett wrote:
Justin Deoliveira wrote:
Hi all,
After ripping out my hair for a few days I can still not get a release to
go.
Release is now gone
Javadoc seems to be completley broken.
Agreed, I got a null pointer exception from our magic plug-in. I have updated the release instructions to *not* include javadoc generation until such time as it works.
problems with the following
modules:
plugin/epsg-hsql
did not find a problem.
ext/widgets-spring
did not find a problem.
ext/go
did not find a problem.
ext/shape
Was missing an svn:ignore on a generated index file.
And there could be more, I gave up after 4 errors. So we are stuck without
javadocs, and if we want a release we have to manually do everything,
which is a pain.
Ended up reading the release:perform instructions, by default this goal does "deploy" and "site-deploy". The wiki has been updated
with an example showing how to get it to do only "deploy".
I will not have any more time to put toward this until next week. I should
also note that GeoServer is not making it project policy to release
against official geotools releases due to the overhead of releasing
geotools and not having a working release process.
Please make use of yesterdays release, geotools needs to (and will fix) the overhead of making a release. I would like to set things up so
projects like uDig and GeoServer can ask for a release given one weeks notice and expect to see results.
With respect to the "larger" problem of why the release process was broken.
- QA tools added to the build chain, and only tested for maven install (rather then full release process)
- files left on the 2.2.x branch that were needed for assembly of release artifacts
- focus on javadocs destracted from real need to produce results
- lack of communication (both wiki instructions and email on release progress)
I am sure we can do better next time
Jody
PS. I am working on a steering document that I will try and share with the list shortly, feedback from the geoserver community in terms of expectations is important and needed.
Thanks for helping out jody, your qa on the build system was excellent
and very much needed. Sometimes I get so involved in battling with maven
that I forget to keep my head above water
Heh, please send more email - it took me an hour just to figure out
where you had gotten stuck.
I thought not being able to run 'mvn javadoc:javadoc' on the modules I
spoke of was clear, my bad.
However, I think its time for some clean up on the build system. While
this workaround gets us a release its not really acceptable. Adrian has
volunteered to help us with releases, but because he is not a maven
expert he cant.
I was asking Richard about this, apparently the maven "release" plugin
is *so* close to what we used to do by
hand that he is in favour of using it. The part that failed was javadoc
generation, something I am happy to skip
until it is ready (and even then we only *really* need it for major
releases).
So I think the current release process (now that we have rescued it from
the 2.2.x branch) is fine, and javadocs
can wait on volunteer time.
I more meant more of all the other stuff in our build system that hasn't
been tested to release: code coverage, formatting, etc...
And so this means that we just keep doing milestone releases on 2.3.x
branch until someone gets around to fixing the build system?
-Justin
Jody
-Justin
Jody Garnett wrote:
Justin Deoliveira wrote:
Hi all,
After ripping out my hair for a few days I can still not get a release to
go.
Release is now gone
Javadoc seems to be completley broken.
Agreed, I got a null pointer exception from our magic plug-in. I have
updated the release instructions to *not* include javadoc generation
until such time as it works.
problems with the following
modules:
plugin/epsg-hsql
did not find a problem.
ext/widgets-spring
did not find a problem.
ext/go
did not find a problem.
ext/shape
Was missing an svn:ignore on a generated index file.
And there could be more, I gave up after 4 errors. So we are stuck without
javadocs, and if we want a release we have to manually do everything,
which is a pain.
Ended up reading the release:perform instructions, by default this goal
does "deploy" and "site-deploy". The wiki has been updated
with an example showing how to get it to do only "deploy".
I will not have any more time to put toward this until next week. I should
also note that GeoServer is not making it project policy to release
against official geotools releases due to the overhead of releasing
geotools and not having a working release process.
Please make use of yesterdays release, geotools needs to (and will fix)
the overhead of making a release. I would like to set things up so
projects like uDig and GeoServer can ask for a release given one weeks
notice and expect to see results.
With respect to the "larger" problem of why the release process was broken.
- QA tools added to the build chain, and only tested for maven install
(rather then full release process)
- files left on the 2.2.x branch that were needed for assembly of
release artifacts
- focus on javadocs destracted from real need to produce results
- lack of communication (both wiki instructions and email on release
progress)
I am sure we can do better next time
Jody
PS. I am working on a steering document that I will try and share with
the list shortly, feedback from the geoserver community in terms of
expectations is important and needed.
Heh, please send more email - it took me an hour just to figure out where you had gotten stuck.
I thought not being able to run 'mvn javadoc:javadoc' on the modules I
spoke of was clear, my bad.
I read the instructions not on the wiki
So I think the current release process (now that we have rescued it from the 2.2.x branch) is fine, and javadocs
can wait on volunteer time.
I more meant more of all the other stuff in our build system that hasn't
been tested to release: code coverage, formatting, etc...
Since it was in the way of the list it is out of there, if Andrea can produce a solution that still works with our release process that is fine.
And so this means that we just keep doing milestone releases on 2.3.x
branch until someone gets around to fixing the build system?
Nope I think we are good to go? Andrea can let us know when formatting and coverage checks are avaialble again and we can issue a point release or something.
Jody
So I think the current release process (now that we have rescued it from the 2.2.x branch) is fine, and javadocs
can wait on volunteer time.
I more meant more of all the other stuff in our build system that hasn't
been tested to release: code coverage, formatting, etc...
Since it was in the way of the list it is out of there, if Andrea can produce a solution that still works with our release process that is fine.
And so this means that we just keep doing milestone releases on 2.3.x
branch until someone gets around to fixing the build system?
Nope I think we are good to go? Andrea can let us know when formatting and coverage checks are avaialble again and we can issue a point release or something.
Jody
Hem... I have to reiterate my yesterdays question: is there a way to make sure a plugin
you add does not break the build without chaning svn? Does anyone know?
