Re: Maven changes to EXPath Packaging and EXPath HTTP Client for Java

Adam, thanks for the documentation! That was welcome.  I wasn't 
successful in getting the project to build in Eclipse (I use the m2e 
plugin, and it works very well with my other maven projects :) -- I 
think the problem is lack of support for multi-module projects).

I do recommend using Maven for your projects.  If you can stand 
conforming to some basic conventions, you get a lot for free.  You don't 
have to ship other people's libraries with your source code, for 
example, which I think is a huge benefit.

I posted something along the same lines for the expath http-client 
project.  It's a little different from (simpler than) what Adam did for 
the pkg project, but the httpclient project is much simpler, too.  I 
didn't move any of the files: just added two pom.xml files.  But to 
build, you have to build them both separately.

Florent, you'll have to decide on a naming and numbering convention for 
Maven artifacts; I wasn't very thoughtful in what I posted, but the 
constraints/recommendations I have would be:

the "group id" has to start with a domain name you control in order to 
be registered w/Maven central (so org.expath or org.expath.whatever).  
It's simplest to use the same group id for all of your expath artifacts 
probably?

the "artifact id" can be whatever you want (distinct for each jar), but 
I strongly recommend something descriptive that doesn't rely on the 
group id for context (ie repeat "expath" in the name), because you'll 
often see it listed without the group id.

There is a convention (semver, not really maven per se) about having 
three-digit numbers for versions that I like where the last digit is 
reserved for backwards-compatible changes.

cheers

-Mike

On 10/27/2013 9:19 AM, Adam Retter wrote:
> Hi Florent,
>
> So I guess some documentation would of been a good idea! So... here it
> is - https://github.com/fgeorges/expath-pkg-java/pull/2
>
> At the moment I have only written it for the EXPath PKG project, 99%
> of it would be the same for the EXPath http-client project. As such I
> think you should create a 3rd, "expath" repo which is just for holding
> common stuff, e.g. the parent "expath-parent/pom.xml" and the common
> doc.
>
> Also I have rather assumed that "fgeorges/expath-pkg-java" will be
> moved to "expath/expath-pkg" ;-)
>
> Cheers Adam
>
> On 23 October 2013 11:23, Florent Georges <fgeorges@fgeorges.org> wrote:
>>    Hi,
>>
>>    Thanks to Adam, we have now some support for Maven in the EXPath
>> Packaging and HTTP Client implementations for Java.  This also adds
>> some streaming facility to the HTTP Client:
>>
>>      https://github.com/fgeorges/expath-pkg-java/
>>      https://github.com/fgeorges/expath-http-client-java/
>>
>>    Unfortunately, those changes were so huge and about so different
>> things (moving to Maven, adding streaming, changing lots of files
>> without any functional changes except formatting the code differently,
>> etc.), that it was very hard to merge them and resolve the conflicts.
>> So I pushed them in their own branch (resp. "maven" and "maven-and-
>> streaming"), can I then ask anyone involved in those projects to test
>> and review them before merging to master?
>>
>>    The Maven part is also not documented.  Can anyone have a look at it
>> and suggets changes to the following files (that I have created, but
>> as I don't know anything about Maven, I can't fill the blanks myself):
>>
>>      https://github.com/fgeorges/expath-pkg-java/blob/maven/doc/development.md
>>      https://github.com/fgeorges/expath-http-client-java/blob/maven-and-streaming/doc/development.md
>>
>>    Regards,
>>
>> --
>> Florent Georges
>> http://fgeorges.org/
>> http://h2oconsulting.be/
>>
>
>

Received on Monday, 28 October 2013 00:09:31 UTC