jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Castagna <castagna.li...@googlemail.com>
Subject Re: Maven build instructions need a bit of work
Date Thu, 03 Nov 2011 11:13:21 GMT
Hi Andy,
I am moving the conversation to jena-dev, since it's not really interesting
for jena-users.

Andy Seaborne wrote:
> On 03/11/11 10:14, Paolo Castagna wrote:
>> Hi Andy
>>
>> Andy Seaborne wrote:
>>> On 03/11/11 09:18, Paolo Castagna wrote:
>>>> Richard Cyganiak wrote:
>>>>> Hi Jena team,
>>>>>
>>>>> I tried to build Jena and ARQ using the instructions here:
>>>>> http://incubator.apache.org/jena/download/maven.html#build_and_install_artifacts_in_your_local_maven_repository

>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The instructions didn't work for me.
>>>>>
>>>>> I had to run this first:
>>>>>
>>>>> svn co
>>>>> https://svn.apache.org/repos/asf/incubator/jena/Jena2/JenaTop/trunk
>>>>> JenaTop
>>>>>
>>>>> and then check out Jena and ARQ into directories on the same level as
>>>>> JenaTop.
>>>>>
>>>>> You may want to update the information on that page accordingly.
>>>>>
>>>>> I guess this section should be updated too:
>>>>> http://incubator.apache.org/jena/getting_involved/index.html#subversion_repository

>>>>>
>>>>>
>>>>>
>>>>
>>>> Hi Richard,
>>>> thanks for the feedback.
>>>>
>>>> Getting involved page changed [1] and visibile in staging [2].
>>>>
>>>> As Damian and Andy said, this will improve as soon as JenaTop makes it
>>>> to the
>>>> Maven central repository. Things are changing on the building front,
>>>> therefore
>>>> some problems are natural and expected.
>>>
>>> Don't we just need to remove the <relativePath>?
>>>
>>> It is published now - <relativePath> is a maven hack to allow multiple
>>> artifact publishing.
>>
>> JenaTop is not published in Maven central. Is it?
> 
> Nor are any of the other artifacts at the moment.

True.

> 
> You can't build ARQ without jena-core and jena-core is only in Apache 
> snapshots.

True.

But, once Maven download the parent of a module it will find that the
parent specifies the Apache snapshot repository and therefore it will
find the other artifacts.

> 
>>
>>> You have to have the Apache snapshot repos on your maven path anyway.
>>
>> Yes, but the <repositories> bit is currently defined in the JenaTop's
>> pom.xml which uses the Apache parent pom (all this as it should be).
>> However, ARQ's pom.xml file does not specify <repositories>:
>> http://svn.apache.org/repos/asf/incubator/jena/Jena2/ARQ/trunk/pom.xml
>> therefore Maven searches for the ARQ parent pom (i.e. JenaTop's pom.xml
>> file) in Maven central: http://repo1.maven.org/maven2/org/apache/jena
> 
> Then the "maven" page on the website needs to say what to put in 
> settings.xml?

No.

I do not think is a good idea to require users to change their settings.xml
just to compile a project.

A not ideal but better approach is to instruct users to publish JenaTop in
their local Maven repository instead (but I do not see this an improvement
in comparison to have <relativePath> and the need of checkout JenaTop).

> 
>> Three options:
>>
>> 1) Keep <relativePath> and checkout JenaTop until we release
>> 2) Release JenaTop only so that it gets to Maven central
>> 3) Add, temporarily, <repositories> to all the Jena modules pom.xml files
> 
> Temporary?  Don't you meanadding snapshot location permanently?

3) would be temporary = until Apache Jena is released and JenaTop is present
in the Maven central repository. At that point in time, all the Jena modules
can specify JenaTop as their parent pom and Maven will find it in the Maven
central repository.

I do not expect the JenaTop parent pom.xml to change frequently, but if this
is not the case, option 3) becomes more valuable.

> 4) put documentation about setting repos in the documentation.
> 
> Doubly so for the development text from SVN.  The page does not mention 
> repo setting and it is essential when using SVN.

What do you mean with "repo setting"?

  a) specifying <repositories> in a pom.xml file
  b) specifying repositories in their Maven settings.xml file

If it's a) we should do it for them. I can help with this if you want.
If it's b), as I said above, I do not think it's a good idea or a good practice.
Indeed, I would argue it's a bad practice and likely to unnecessarily annoying 
users if we ask them to change their settings.xml just to compile one of the
Apache Jena projects.

5) eliminate JenaTop and point directly to the Apache parent pom.xml file.

This goes again the DRY principle and there will be duplicate things in all the
Jena pom.xml files. However, those duplicate things should not change often.

Option 5) is something I do not recommend, but it's another option on the table.

Paolo

> (it will probably get worse for multi-module)
> 
>> I do not have strong preferences for any of these.
>> 2) is the one I like the least.
>>
>> I can help with 3) if you want.
>>
>>>
>>> I don't see that changing the documentation helps much because it will
>>> go out of date.
>>
>> I'll change it back when having JenaTop alongside a Jena module is not
>> necessary.
> 
> 
> 
>>
>> Paolo
>>
>>>
>>> Andy
>>>
>>>>
>>>> Paolo
>>>>
>>>> [1] http://svn.apache.org/viewvc?view=revision&revision=1197008
>>>> [2] http://jena.staging.apache.org/jena/getting_involved/
>>>>
>>>>>
>>>>> Best,
>>>>> Richard
>>>>
>>>
>>
> 


Mime
View raw message