Yeah, the geoserver build uses a custom plugin to copy over a data directory
into the webapp. Its pretty outdated as it seems. A full blown plug-in is
not really need for that, and actually it just complicates the build. Some
inline ant with the antrun plugin in the web/app pom should do the same and
be easier to maintain. So I attached a patch to GEOS-4652 that does just
that.
With that and a few other minor tweaks I was able to build geoserver with
maven 3. However I did not not run with tests, getting late here :) So if
the other devs could give the patch a spin that would be great. Regardless
it should be a decent starting point.
-Justin
On Tue, Jun 28, 2011 at 9:45 PM, Ben Caradoc-Davies
<ben.caradoc-dav...@csiro.au> wrote:
> OK, I have attached a new patch to GEOT-3615; with this GeoTools trunk
> build with -Dall:
> https://jira.codehaus.org/**browse/GEOT-3615<https://jira.codehaus.org/browse/GEOT-3615>
>
> Unfortunately, GeoServer does not build with Maven 3. It will be a gigantic
> PITA to have to use Maven 3 for one and Maven 2 for another. I could not
> find an existing Geoserver Jira issue, so here is the one I created:
> https://jira.codehaus.org/**browse/GEOS-4652<https://jira.codehaus.org/browse/GEOS-4652>
>
> Need a maven plugin guru to fix this mojo. Justin? Andrea?
>
> Is it possible to get this to build on Maven 3 with breaking Maven 2?
>
>
> On 29/06/11 10:10, Ben Caradoc-Davies wrote:
>
>> I've added +1 on the proposal.
>>
>> I'm still seeing build failures with maven3. Please see the issue.
>>
>> On 28/06/11 19:49, Jody Garnett wrote:
>>
>>> I should point out that we should be able to go ahead with the patch and
>>> proposal. At this point we have a couple of +1 votes...
>>>
>>> - Andrea you indicated enthusiasm but did not vote? Anything to add...
>>> - Ben how are you set to go on this?
>>>
>>>
>>> --
>>> Jody Garnett
>>>
>>>
>>> On Tuesday, 28 June 2011 at 9:02 PM, Michael Bedward wrote:
>>>
>>> I guess it has to be experiment.
>>>
>>> When Hudson runs a deploy job, time-stamped jars will end up in the
>>> OSGeo repo. We only need to keep the most recent ones since this is
>>> effectively what we were doing with non-timestamped jars.
>>>
>>> As far as I understand from the stackoverflow discussion, the problem,
>>> if it still exists, affects the local repos of those using an eclipse
>>> plugin (?). Supposedly, command line maven and (superior) NetBeans
>>> users won't end up with multiple snapshots in their local repo... but
>>> there's only one way to find out.
>>>
>>> Michael
>>>
>>>
>>> On 28 June 2011 20:39, Jody Garnett<jody.garn...@gmail.com**<mailto:
>>> jody.garn...@gmail.com**>> wrote:
>>> So Java 6 has gone out; meaning we can take up with maven 3 again.
>>> So far the interesting question has been with respect to the handling of
>>> SNAPSHOTS:
>>> a) Justin will need to ask maven to clear out snapshots after a bit?
>>> b) Developers should only have one snapshot jar; but there is some
>>> discussion on if this feature is broken in maven 3 or not
>>> Comments? Feedback? Experimentation?
>>> Jody
>>>
>>> On Thu, Jun 23, 2011 at 4:41 PM, Severin (aka Cliff)<djseve...@gmail.com
>>> <**mailto:djseve...@gmail.com>>
>>> wrote:
>>>
>>> Hi People,
>>>
>>> I've written up a proposal on the wiki with regard to updating the
>>> GeoTools build process to work under both Maven 2 and 3.
>>> Justin: jgarnett suggested I open a dialogue with you to see if you have
>>> any interest in updating the build box to use Maven 3 yet.
>>> Proposal is
>>> at
>>> http://docs.codehaus.org/**display/GEOTOOLS/Update+to+**use+Maven+3<http://docs.codehaus.org/display/GEOTOOLS/Update+to+use+Maven+3>for
>>> review.
>>>
>>> Cheers,
>>> Cliff
>>> --
>>> "We are dreamers, shapers, singers and makers..."
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ------------------
>>> Simplify data backup and recovery for your virtual environment with
>>> vRanger.
>>> Installation's a snap, and flexible recovery options mean your data is
>>> safe,
>>> secure and there when you need it. Data protection magic?
>>> Nope - It's vRanger. Get your free trial download today.
>>> http://p.sf.net/sfu/quest-**sfdev2dev<http://p.sf.net/sfu/quest-sfdev2dev>
>>> ______________________________**_________________
>>> Geotools-devel mailing list
>>> Geotools-devel@lists.**sourceforge.net<Geotools-devel@lists.sourceforge.net>
>>> <mailto:Geotool**s-de...@lists.sourceforge.net<Geotools-devel@lists.sourceforge.net>
>>> >
>>> https://lists.sourceforge.net/**lists/listinfo/geotools-devel<https://lists.sourceforge.net/lists/listinfo/geotools-devel>
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ------------------
>>> All of the data generated in your IT infrastructure is seriously
>>> valuable.
>>> Why? It contains a definitive record of application performance, security
>>> threats, fraudulent activity, and more. Splunk takes this data and makes
>>> sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-**d2d-c2 <http://p.sf.net/sfu/splunk-d2d-c2>
>>> ______________________________**_________________
>>> Geotools-devel mailing list
>>> Geotools-devel@lists.**sourceforge.net<Geotools-devel@lists.sourceforge.net>
>>> <mailto:Geotool**s-de...@lists.sourceforge.net<Geotools-devel@lists.sourceforge.net>
>>> >
>>> https://lists.sourceforge.net/**lists/listinfo/geotools-devel<https://lists.sourceforge.net/lists/listinfo/geotools-devel>
>>>
>>>
>>
> --
> Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au>
> Software Engineering Team Leader
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
