[Pljava-dev] Source code move to Git

Yep. Incremental rules. Will get something to y'all soon.

Thx.

Sent from my Tricorder

On Jan 13, 2013, at 10:20 AM, Thomas Hallgren <thomas at tada.se> wrote:

> On 2013-01-13 18:10, Hal Hildebrand wrote:
>> So, seems like I have to apply all the transforms again to get this in the form I current have it. Thus....
>>
>> Is Maven still desirable?
>
> Yes, absolutely! And I think that later on, we should strive to make the Maven Central the main distribution point for PL/Java.
>
>> What group id do you want to use?
>
> I searched Maven Central. The standard PostgreSQL jdbc driver uses the group id 'postgresql'. Incidentally, that's also what I used the first time a pljava jar was published (pljava-public). So lets stick with that. I can't find any other groupid that is used for Postgres and I think that creating additional ones will just lead to confusion.
>
>> Is the break out of the maven modules acceptable?
>
> Yes, although I'd prefer if the module named 'jdbc' was named 'plugin' or 'module' since it contains the complete module to be installed into the backend server. It's more than just jdbc. Other name suggestions are of course welcome. I'd also like the current src/C directory to also end up in this sub-project under src/main/c (C becomes smallcaps c) and src/main/include. Reason being that I think that the maven-nar-plugin http://duns.github.com/maven-nar-plugin/ looks like a good candidate for building it and I'd prefer to use it's default layout. Does that sound agreeable to you?
>
>> Was the code formatting desirable?
> Yes, although it's a bit hard to see what's really changed in a commit that massive so please don't mix the reformatting with any other type of change.
>
> I'm not sure what formatting rules you are using. Is it Eclipse built-in rules? One thing that often annoys me with that is that 80 characters is very narrow nowadays. I usually increase that to at least 120. What's your opinion about that?
>
>> Let me know the answers above and I'll have a pull request for your review soon.
>>
>> Also, too, y'all should know that git doesn't keep track of the refactoring of individual file movement. It tries to do some stuff, but I'm not sure how much history is maintained. So if I refactor the project to the maven modules that I currently have in my repository, then some history information will likely be lost.
> Git is usually very good in finding what has been moved if you are careful not to change the content of the files in the same commit. So be careful to have one commit where you only move files without changing any of their content.
>
> In order to accomplish all of this, and also to be able to keep good track of what has happened, I think it would be ideal if pull-requests are very distinct. That means that you'll need to submit more than one. I would suggest the following:
>
> 1. A pull request that creates the Maven structure and adds the pom's. This pull request must not change the content of any file. Just move them. In addition to what you did earlier, I think the C-code needs to move into a separate sub-project as well (with it's own src/main/c
>
> 2. A pull request that takes care of the formatting. Given the magnitude of the change, I think it's essential that this pull request only deals with formatting. It must not change any logic whatsoever since that change would be come completely impossible to find later on.
>
> 3. Other pull requests that change logic. Ideally, those requests should be preceded by an issue (bug or enhancement request) where other interested parties (like myself) has had a chance to discuss the nature of the change.
>
>>
>> I think the maven refactoring is a good thing, personally. But I don't know if it's worth (potentially) losing the history in your valuation.
> I agree that the refactoring is a good thing. And as I wrote, I suspect that the history will be retained in full if it's done right.
>
> I'm looking forward to your submissions.
>
> Thanks and Regards,
> Thomas Hallgren
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20130113/f2916cfc/attachment-0001.html>