On Sat, Jun 30, 2012 at 6:04 PM, Justin Deoliveira <jdeol...@opengeo.org>wrote:
> Hi all,
>
> With the switch to git i have removed the execution of the svn revision
> plugin since it will now fail. Now, this leaves the question of what to
> replace it with. The obvious choice is what we tried before:
>
> https://github.com/ktoso/maven-git-commit-id-plugin
>
> Which works fairly well for the most part but we did have some issues with
> it before. Doing some digging the issue is indeed a bug in maven 2. The
> failures occur actually only during the execution that generates out the
> source jar for a project, the main execution runs fine. The plugin seems to
> work pretty flawlessly on maven 3. But that is indeed still a problem as i
> don't think we are ready to so you must build with maven 3? Maybe, maybe
> not.
>
The current trunk (almost the new stable branch) should be buildable with
Maven 3, right? And the new trunk as well.
What's keeping us at bay is, I guess, the 2.7.x series, which is probably
going to live a bit longer (I guess another
release, gt2.7.6/gs2.1.5?)
If we're looking at a month long coexistence between maven 3 and 2 on some
core developers, it does not
look like a tragedy.
Don't know about others, for me I have setup some shell scripts that I
source so that they setup mvn2 or 3,
and setup each so that they use different on disk repos.
The residual issue is M2_REPO in Eclipse, afaik that cannot be renamed, so
I guess one has to setup
two different Eclipse workspaces for the 2.7.x seris and the new one.
Annoying for sure, but maybe not a tragedy?
>
> There is also the issue of building from a source snapshot, like what we
> generate out for releases. In its current state the plugin will fail.
>
> Other users of the plugin have made a request for a flag to control
> whether a failure in the plugin should cause a build failure. I have added
> by voice to this:
>
> https://github.com/ktoso/maven-git-commit-id-plugin/issues/25
>
> And also issues a pull request to implement it:
>
> https://github.com/ktoso/maven-git-commit-id-plugin/pull/26
>
> With this new parameter the plugin should work pretty seamlessly for us.
> But, that leaves the question of what do in the short term. I see a few
> options.
>
> 1) do nothing and wait until a new version of the plugin that addresses
> this issue is available
> 2) host our own copy of the plugin for now until (1) becomes a reality
> 3) use the plugin as is and folks using maven 2 (or trying to build from
> a source snapshot) will be out of luck until (1) is resolved
> 4) use the plugin as is and turn off source jar generation for now
>
> Thoughts? I guess we can wait it out for a bit and hopefully the pull
> request gets merged in sooner rather than later. It shouldn't really be an
> issue until we decide to do the next release.
>
I guess it's a matter of "how short is short". The combined gt/gs release
procedure relies on the CITE tests
being able to report the revision at which gt2 and gs were built, if we
don't have them we're toast.
Which reminds me, we'll need to update the release scripts 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/
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
