ng4j-namedgraphs — Discussion of Named Graphs in RDF

Re: [namedgraphs] NG4J project wiki

[Tim P. <tim...@ou...>]

On Tuesday 09 June 2009 23:26:13 Jennifer Cormier wrote:
> 
> The initial reason for the wiki is that it was getting too complicated to
> track the changes planned for upcoming releases.  Now there's a page for the
> next release - Post 0.9 Release Plans - accessible from the wiki's Main
> Page.

This all looks good, and not a lot to actually fix, much of it seems to already be done, 
or to be the sort of thing which it is quicker to do than to document. 

Lets get this one out of the door so that we can focus on catching up with current jena. 

cheers
Tim

Re: [namedgraphs] [feedback-crypto] Bouncy Castle Jars

[Tim P. <tim...@ou...>]

David, 

Thanks for this. 
It will save a lot of people a lot of time.

yours
Tim

On Wednesday 10 June 2009 04:15:43 David Hook wrote:
> 
> Hi,
> 
> I think we now have a correctly setup repository that can be synced
> with. I've added a jira issue:
> 
> http://jira.codehaus.org/browse/MAVENUPLOAD-2479
> 
> For it to be tried out.
> 
> At the moment the repository just has the 1.43 provider jars in it, once
> I've confirmed that's working and fixed an errors we might find, I will
> start adding the other jars people have requested.
> 
> Regards,
> 
> David
> 
> On Sun, 2009-06-07 at 01:17 +0100, Tim Pizey wrote:
> > Hi,
> > 
> > I have asked the Bouncy Castle guys if they will push to a Maven Repository and they 
> > replied that they publish only to http://www.bouncycastle.org/latest_releases.html
> > 
> > So could someone at the Maven end ensure that all those jars are synched with?
> > 
> > thanks
> > Tim
> > 
> > 
> 
> 

[namedgraphs] NG4J project wiki

[Jennifer C. <jen...@at...>]

Hello all,

Thanks to Olaf the NG4J project now has a wiki.  To access it, go to the
NG4J site at sourceforge (http://sourceforge.net/projects/ng4j/) and choose
MediaWiki from the Hosted Apps drop-down.  (The direct link will be changing
in a few weeks when SourceForge makes updates to hosted applications, so I
have not provided that link here.)

The initial reason for the wiki is that it was getting too complicated to
track the changes planned for upcoming releases.  Now there's a page for the
next release - Post 0.9 Release Plans - accessible from the wiki's Main
Page.

Note: I have already downloaded most of the newer jars, and could commit
them, but I don't have a way to test the semantic web client library beyond
the project's junit tests.  If it would help I could commit the newer
versions of GRDDL and associated libraries, but wait for testing to be
completed before removing the older versions.

If there's no objection I could upgrade axis.jar since that's not used by
the semwebclient code.

Regards,

Jennifer

Re: [namedgraphs] Use of Grddl

[Jennifer C. <jen...@at...>]

Good catch, Tim.  This should be fixed, possibly by making the 2nd "if" an
"else if" instead.  But let's leave that to the keeper of the semantic web
code, Olaf.


This and similar issues can also be detected by Eclipse and shown as
warnings.  Another useful plug-in to detect even more possible problems is
FindBugs.

I am hopeful that as part of the port to the newer version of Jena and
taking full advantage of Java 5 capabilities, we will be able to greatly
reduce the number of warnings -- and more easily recognize and fix the
"real" problems.  (Not that we don't want to fix whatever we can now - we
definitely do.)


Jennifer
 

-----Original Message-----
From: Tim Pizey [mailto:tim...@ou...] 
Sent: Saturday, June 06, 2009 3:59 PM
To: ng4...@li...
Subject: [namedgraphs] Use of Grddl

Hi, 

Just to see what happens I removed grddl.jar 

The only place it is used is in DereferencerThread

	private DereferencingResult parseRdf(DereferencingTask task, String
lang) throws Exception {
		if (lang.equals("default"))
			lang = null;
		if (lang.equals("html") || lang.equals("HTML")){

We can see by inspection that if the lang is "default"  we will get an NPE

The test coverage shows that this code is not excercised by the tests: 
http://paneris.net/ng4j/cobertura/de.fuberlin.wiwiss.ng4j.semwebclient.Deref
erencerThread.html#236


cheers
tim

[namedgraphs] Maven progress

[Tim P. <tim...@ou...>]

Hi Jennifer and all, 

I have been told on the Jena list that there is work to move grddl, 
at least, to Maven. 

Separately I have been told that someone at BouncyCastle.org will 
push their jars out to the Maven Repos. 

So we should be in a much easier position, where everyone is 
using the same system. 

Then all we need is Hudson and we can have continuous integration 
across the whole eco-system. 

cheers
Tim

Re: [namedgraphs] Building with Maven

[Jennifer C. <jen...@at...>]

On Saturday 06 June 2009 4:05 PM Tim Pizey wrote:

> NOTE: Everything compiles and the tests run without the oro jar, so this
looks 
> like it can be removed. 

Hmm.  It appears that way.  That (the jakarta-oro jar) was added on
9/13/2004 because it was necessary to parse RDF/XML.  I wonder if that was
for the TriQL code.  If so we could remove it since we removed TriQL.

* Richard (Cyganiak) - could you confirm?


> NOTE: which Bouncy Castle jar will be used by the ant build is merely
determined by 
> their sort ordering, which I think means that the oldest one will be used.

> This is probably not intended behaviour. Suggest the 141 jars are deleted.


Good point.  Bouncy Castle 1.41 jars - deleted.


> NOTE: de.fuberlin.wiwiss.ng4j.swp.c14n.RDFC14NImpl replies upon a class
defined in 
> jenattest, which is not a production jar but a test jar.

Yes, that is true.  At the time that change was made, according to Jena's
javadoc (for version 2.5.6) the Node.create method being used by the NG4J
code was deprecated and NodeCreateUtils.create should be used instead.
However NodeCreateUtils is in the jenatest library. 

I agree this is unfortunate and we should see whether the calls to
NodeCreateUtils could be replaced by a different node creation method in
Jena.  I'm not sure whether it would be better to do that now or wait until
we upgrade to the latest Jena.


Jennifer 

Re: [namedgraphs] Upgrading the build

[Jennifer C. <jen...@at...>]

On Monday, June 08, 2009 4:34 AM Tim Pizey wrote:

> I think we need to get back into lock step with jena and am happy to help
> to achieve that. 

Yes, I think we're all agreed that NG4J should move to the latest Jena, ARQ,
etc.  We just want to complete this mostly-bug-fix release first.

Moving to the latest Jena will be a relatively large change.  As we do so
we'll also want to take full advantage of Java 5 typing.  That is something
we wanted to do earlier but couldn't until Jena completed this release.

Thanks for your offer to help with the transition!

Jennifer


-----Original Message-----
From: Tim Pizey [mailto:tim...@ou...] 
Sent: Monday, June 08, 2009 4:34 AM
To: Jennifer Cormier
Cc: ng4...@li...
Subject: Re: [namedgraphs] Upgrading the build

On Friday 05 Jun 2009 19:40:19 Jennifer Cormier wrote:
> 
> When you say that Jena only "targets" Java 6, is that based upon 
> something in their build (for Maven)?


I found where I got this impression, a version of the jena2 jars was
published which was incompatible with jdk1.5. 
Andy said on the jena list that he would get around to fixing this when time
permitted. 
I extrapolated beyond what was said.

I have been trying to compile ng4j with the current jena2. 
There was quite a bit of hacking to get it to work. 

I think we need to get back into lock step with jena and am happy to help to
achieve that. 

yours
tim

Re: [namedgraphs] Upgrading the build

[Tim P. <tim...@ou...>]

On Friday 05 Jun 2009 19:40:19 Jennifer Cormier wrote:
> 
> When you say that Jena only "targets" Java 6, is that based upon something
> in their build (for Maven)?


I found where I got this impression, a version of the jena2 jars was published which 
was incompatible with jdk1.5. 
Andy said on the jena list that he would get around to fixing this when time permitted. 
I extrapolated beyond what was said.

I have been trying to compile ng4j with the current jena2. 
There was quite a bit of hacking to get it to work. 

I think we need to get back into lock step with jena and am happy to help to achieve that. 

yours
tim

[namedgraphs] Usage of the jena eco system by a Gaboto servlet

[Tim P. <tim...@ou...>]

Hi, 

In an attempt to further explore the Jena eco-system that Gaboto uses I 
hacked a project together from my existing project by adding to it 
all the code of Gaboto, jena and ng4j, rather than using their respective jars.

The coverage report is given here: 

http://paneris.net/uriinterface/cobertura/index.html

My project is pretty straight forward, it creates a Jena model and queries it. 
See uk.ac.ox.oucs.erewhon.uriinterface.OxPointsQueryServlet

I am not sure exactly what to draw from this, but it took me a long time to produce!

yours
Tim Pizey

Re: [namedgraphs] Building with Maven

[Tim P. <tim...@ou...>]

On Saturday 06 June 2009 21:04:39 Tim Pizey wrote:
> I have updated the recently submitted pom on the tracker 
> http://sourceforge.net/tracker/?func=detail&aid=2801813&group_id=118754&atid=682763
> however I cannot upload it at this moment, as the sourceforge site is down. 
> I attach it, I will use the tracker as well, when it re-appears. 


Uploaded now

Tim

[namedgraphs] Building with Maven

[Tim P. <tim...@ou...>]

Hi, 

I have updated the recently submitted pom on the tracker 
http://sourceforge.net/tracker/?func=detail&aid=2801813&group_id=118754&atid=682763
however I cannot upload it at this moment, as the sourceforge site is down. 
I attach it, I will use the tracker as well, when it re-appears. 

I would like to join this project as a developer, my sourceforge id is timp. 
I promise to restrict commits to maven and javadoc and similar trivia.
I would be happy to remove the sun classes so the build runs without warnings.

I am able to build ng4j using Maven with no configuration.

There are three jars which are not currently in the Maven central repositories: 
grddl, bcprog, bcpg. 
For convenience I have deployed these  jars to http://paneris.net/maven2/
and added that repository to the pom.
(Using following commands: 
 mvn deploy:deploy-file -DgroupId=com.hp.hpl.jena -DartifactId=grddl -Dversion=0.3 -Dpackaging=jar -Dfile=lib/grddl.jar -Durl=scp:melati.org/maven2 -DrepositoryId=melati
 mvn deploy:deploy-file -DgroupId=bouncycastle -DartifactId=bcpg-jdk15 -Dversion=143 -Dpackaging=jar -Dfile=lib/bcpg-jdk15-143.jar -Durl=scp:melati.org/maven2 -DrepositoryId=melati
 mvn deploy:deploy-file -DgroupId=bouncycastle -DartifactId=bcprov-jdk15 -Dversion=143 -Dpackaging=jar -Dfile=lib/bcprov-jdk15-143.jar -Durl=scp:melati.org/maven2 -DrepositoryId=melati
)

The command to build and install locally is 

mvn clean install 

The commands to install the jars in /lib/ to your local repository are, however they should be downloaded  
from the repository above.

mvn install:install-file -DgroupId=com.hp.hpl.jena -DartifactId=grddl -Dversion=0.3 -Dpackaging=jar -Dfile=lib/grddl.jar
mvn install:install-file -DgroupId=bouncycastle -DartifactId=bcprov-jdk15 -Dversion=143 -Dpackaging=jar -Dfile=lib/bcprov-jdk15-143.jar
mvn install:install-file -DgroupId=bouncycastle -DartifactId=bcpg-jdk15 -Dversion=143 -Dpackaging=jar -Dfile=lib/bcpg-jdk15-143.jar

(or you can install the 141 version of bouncy castle jars, also in lib). 

I have added details from the sourceforge site and changed the repository and 
project site to a server I control so that 

mvn clean install deploy site site:deploy 

creates a snapshot and meta website. 
In particular see the dependencies: 
http://paneris.net/ng4j/dependencies.html
and the test coverage: 
http://paneris.net/ng4j/cobertura/index.html

All artefacts (jar, sources, tests can be seen at 
http://paneris.net/maven2/de/fuberlin/wiwss/ng4j/ng4j/0.9-SNAPSHOT/

I do not know where the correct place to put this would be, maybe somewhere off 
http://www4.wiwiss.fu-berlin.de/bizer/ng4j/

I have nagged the bouncy castle guys about pushing to the central maven repos. 

hope this helps, now to get on the grddl guys' case. 
Tim

I have determined the scope of dependencies by removing them and seeing what breaks, 
so the dependencies in the pom do reflect reality. 

NOTE: which Bouncy Castle jar will be used by the ant build is merely determined by their sort ordering, 
which I think means that the oldest one will be used.
This is probably not intended behaviour. Suggest the 141 jars are deleted. 

NOTE: de.fuberlin.wiwiss.ng4j.swp.c14n.RDFC14NImpl replies upon a class defined in jenattest, which is not a production jar but a test jar.

NOTE: Everything compiles and the tests run without the oro jar, so this looks like it can be removed. 
 
NOTE: Axis 1.4 jar is latest and works 

[namedgraphs] Use of Grddl

[Tim P. <tim...@ou...>]

Hi, 

Just to see what happens I removed grddl.jar 

The only place it is used is in DereferencerThread

	private DereferencingResult parseRdf(DereferencingTask task, String lang) throws Exception {
		if (lang.equals("default"))
			lang = null;
		if (lang.equals("html") || lang.equals("HTML")){

We can see by inspection that if the lang is "default"  we will get an NPE

The test coverage shows that this code is not excercised by the tests: 
http://paneris.net/ng4j/cobertura/de.fuberlin.wiwiss.ng4j.semwebclient.DereferencerThread.html#236


cheers
tim

Re: [namedgraphs] Upgrading the build

[Tim P. <tim...@ou...>]

Hi Jennifer, 

On Friday 05 June 2009 19:40:19 Jennifer Cormier wrote:
[snip]
 
> The Semantic Web Publishing capabilities of NG4J are the main reason it
> requires Bouncy Castle.  Those are in use.  My group has made and committed
> several improvements to the SWP code in the last year, fixing things and
> adding capabilities.  No offense taken, but let's not talk about removing
> it, ok? :)

Oops, sorry, no offense intended. 
I am trying to get a feel for the dependency graphs.
It was only after suggesting that Bouncy Castle was a problem that I discovered 
the publishing side of ng4j at all. 

What NG4J gives me is the ability to do temporal reasoning, with contradictory 
facts in separate named graphs. 

Again, I am sure, talking out of turn and out of ignorance, but the name NG4J 
does not necessarily suggest 'using this module commits you to a particular, 
authorisation schema'.

> When you say that Jena only "targets" Java 6, is that based upon something
> in their build (for Maven)?

I can't give you chapter and verse, but I have picked up that impression from 
somewhere. 

> If we use Maven does that mean we would want to have a different build for
> each Java version we support (5 & 6)?  

No, I now realise. 
You do however need to explain that people need to use different BouncyCastle 
jars (I assume) depending upon their jdk version. 
This actually makes the dependency management a bit unpleasant, which is 
what motivated me to suggest ditching BC. 
I would still think that there is a case for factoring out the signing into a separate sub project.

You no longer support java 1.4, was that due to Bouncy Castle or other issues? 

> I'd been working under a
> lowest-common-denominator type assumption and that if we supplied a Java 5
> build, people could use it with Java 6 without problems.

I can't see why that would be wrong, but the fact that Bouncy Castle supply different 
jars for different JDKs suggests that using a 1.5 BouncyCastle with 1.6 is wrong in some way.
So I am afraid that this is something that would need a more informed answer.

> I don't quite follow what's going on re the .classpath setting you
> mentioned.  
> Are you using Maven to create a fresh Eclipse profile, and when
> that is done the extra classpath entry is made?  

Yes, exactly. 

Maven has a plugin which can generate (or regenerate) your .project and .classpath files. 

It can overwrite or modify existing setups. 

So I did 

mvn eclipse:clean eclipse:eclipse 

this deleted the existing eclipse .project file and .classpath files and created new ones. 
The major difference is that the jar files now referenced are not the ones in lib/ but 
the ones the developer has in their own Maven repository. 


It seems as though  the default is to include 'disallow sun jars' in the generated setup. 
If you manually add 
 <classpathentry kind="con"
 path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug
 .ui.launcher.StandardVMType/J2SE-1.5"/>
to your .classpath file you will see what I mean. 


> Is this how we'd want to go
> about things, rather than maintaining the Eclipse profile as a separate,
> unrelated entity?  

This is a bit tough, I am not sure of best practice. 

I like that you have your Eclipse setup in CVS.
It makes checkout work smoothly. 
Whilst you are using Ant, or more correctly whilst you are shipping your own 
copies of your dependencies, then this is correct/best. 

For those of us using the Maven build we can regenerate using the command above. 
Should we move to a Maven only build and lose the contents of /lib then I think we should 
still keep a generated copy of the eclipse setup files in CVS as this enables ease of 
importing the project from CVS. 

> And what would be the "fix" re the classpath entry?

The fix, as I said to Olaf, is to use the Apache Commons Codec 
(http://commons.apache.org/codec/) Base64 encodings. 

 
> Thanks for helping us to understand Maven better and helping to improve the
> NG4J code and builds.

You are very welcome, I am keen to get a smooth, continuously integrated, maven based build 
working. I am also keen not to offend :)

I believe that there is one more issue around upgrade. 
Gaboto too  shipped its own dependencies and requires jdk1.6. 
When I converted it to use Maven and my Maven generated copies of ng4j/jena the code would not compile.
This is because either jena or ng4j import a w3c dom model2 jar, whereas jdk1.6 supplies dom model3 classes, 
(I believe,  do correct me)
I fixed this by downgrading the code in Gaboto. 

yours

Tim

Re: [namedgraphs] Upgrading the build

[Jennifer C. <jen...@at...>]

Tim,

Thanks for creating those requests in the tracker for NG4J on sourceforge!

Yes, NG4J currently requires Java 5, not 6.

The latest version (2.6.0) of Jena requires Java 5.  (The release notes
highlight that: "Codebase converted to Java 5".)  All prior versions,
including the one upon which NG4J depends, require only 1.4, not 5 (1.5).
For this release we do not intend to modify the Jena libraries or increase
the version of Java required.

(Personally I'd be ok with moving to Java 6, but unless there's a real need,
for the sake of other users who may be at Java 5, I wouldn't advocate moving
to Java 6.)

The Semantic Web Publishing capabilities of NG4J are the main reason it
requires Bouncy Castle.  Those are in use.  My group has made and committed
several improvements to the SWP code in the last year, fixing things and
adding capabilities.  No offense taken, but let's not talk about removing
it, ok? :)


When you say that Jena only "targets" Java 6, is that based upon something
in their build (for Maven)?

If we use Maven does that mean we would want to have a different build for
each Java version we support (5 & 6)?  I'd been working under a
lowest-common-denominator type assumption and that if we supplied a Java 5
build, people could use it with Java 6 without problems.

I don't quite follow what's going on re the .classpath setting you
mentioned.  Are you using Maven to create a fresh Eclipse profile, and when
that is done the extra classpath entry is made?  Is this how we'd want to go
about things, rather than maintaining the Eclipse profile as a separate,
unrelated entity?  And what would be the "fix" re the classpath entry?

Thanks for helping us to understand Maven better and helping to improve the
NG4J code and builds.


Jennifer
 

-----Original Message-----
From: Tim Pizey [mailto:tim...@ou...] 
Sent: Friday, June 05, 2009 11:59 AM
To: ng4...@li...
Subject: [namedgraphs] Upgrading the build

Hi, 

I have added the antlr plugin to the maven build. 

ng4j/tests/de/fuberlin/wiwiss/ng4j/trig/TriGParserTest.java
fails to build on linux/maven/jdk6: [198,23] unmappable character for
encoding UTF8





We appear to be only targetting jdk1.5, however Jena is currently only
targetting jdk1.6. 
Bouncy Castle produces one jar per jdk targetted. 

If we intend to continue to use Bouncy Castle then we too should create one
jar per jdk targetted. 

I propose that in the immediate term we push out a new version, so as to get
Olaf's code into a production version. 

Then I suggest we remove the dependency upon the Bouncy Castle jars, so
simplifying the build process and ensuring that we can support both 1.5 and
1.6 jdks.

This  involves removal of OpenPGPUtils and their one use in
SWPNamedGraphSetImpl.actOnGraphsAndIncludeSignature

This would appear to remove the ability to use .asc OpenPGP files, used in
assertGraphsWithSignature assertWithSignature quoteWithSignature

Is this functionality in use?
The CVS history does not imply that this code has been much visited since it
was written. 
I am only looking at these issues very superficially, it may well be that
OpenPGP is crucial functionality, but for my use cases I am surprised to see
it as a dependency at this level. 

I have attached my latest stab at the POM to an issue in the tracker. 

Interestingly when this is used to generate a new eclipse profile then all
the sun packages are highlighted as unaccessible. 
This is due to the addition of
  <classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug
.ui.launcher.StandardVMType/J2SE-1.5"/>
to the .classpath file. 
I would be happy to find these and fix. 


I hope this helps 
Tim





----------------------------------------------------------------------------
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
ng4j-namedgraphs mailing list
ng4...@li...
https://lists.sourceforge.net/lists/listinfo/ng4j-namedgraphs

[namedgraphs] Upgrading the build

[Tim P. <tim...@ou...>]

Hi, 

I have added the antlr plugin to the maven build. 

ng4j/tests/de/fuberlin/wiwiss/ng4j/trig/TriGParserTest.java
fails to build on linux/maven/jdk6: [198,23] unmappable character for encoding UTF8





We appear to be only targetting jdk1.5, however Jena is currently only targetting jdk1.6. 
Bouncy Castle produces one jar per jdk targetted. 

If we intend to continue to use Bouncy Castle then we too should create one jar per jdk targetted. 

I propose that in the immediate term we push out a new version, so as to get Olaf's code into a production version. 

Then I suggest we remove the dependency upon the Bouncy Castle jars, so simplifying the build process and 
ensuring that we can support both 1.5 and 1.6 jdks.

This  involves removal of OpenPGPUtils and their one use in SWPNamedGraphSetImpl.actOnGraphsAndIncludeSignature

This would appear to remove the ability to use .asc OpenPGP files, used in 
assertGraphsWithSignature
assertWithSignature 
quoteWithSignature

Is this functionality in use?
The CVS history does not imply that this code has been much visited since it was written. 
I am only looking at these issues very superficially, it may well be that OpenPGP is crucial functionality, 
but for my use cases I am surprised to see it as a dependency at this level. 

I have attached my latest stab at the POM to an issue in the tracker. 

Interestingly when this is used to generate a new eclipse profile then all the sun packages are highlighted as unaccessible. 
This is due to the addition of 
  <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5"/>
to the .classpath file. 
I would be happy to find these and fix. 


I hope this helps 
Tim

Re: [namedgraphs] new release

[Tim P. <tim...@ou...>]

On Tuesday 02 Jun 2009 14:43:58 Richard Cyganiak wrote:
> 
> On 2 Jun 2009, at 13:41, Olaf Hartig wrote:
> > I'm fine with providing future versions of the NG4J JAR with a name  
> > that
> > reflects the version. Can we automate this or do we have to rename  
> > ng4j.jar
> > manually during the process of preparing a release?
> 
> This can be automated in the Ant build. See here for a buildfile that  
> does this:
> 
> http://d2rq-map.cvs.sourceforge.net/viewvc/d2rq-map/d2rq-map/build.xml?revision=1.13&view=markup
> 
> Look at the jar, tar and zip targets, and how they use variables  
> defined using <property> at the beginning of the file.
> 
> The version number is specified as a <property> near the beginning of  
> the build file.
> 
> Richard

Looking at the build script there are references to javacc, which is not longer in the project. 

I will remove and add version. 

Tim

Re: [namedgraphs] new release

[Tim P. <tim...@ou...>]

On Tuesday 02 Jun 2009 15:53:25 Tim Pizey wrote:
> Hi Olaf,
> On Tuesday 02 Jun 2009 13:41:42 Olaf Hartig wrote:
>
> This has been the subject of previous discussions, which I have not chased
> these down, but my 2p would be that numbers to the right of the first point
> may not exceed 9.

http://www.sonatype.com/books/maven-book/reference/pom-relationships-sect-pom-
syntax.html#pom-reationships-sect-versions

Is the guidance from Maven

Tim

Re: [namedgraphs] new release

[Tim P. <tim...@ou...>]

Hi Olaf, 

On Tuesday 02 Jun 2009 13:41:42 Olaf Hartig wrote:
> Hey,
>
> I'm fine with providing future versions of the NG4J JAR with a name that
> reflects the version. Can we automate this or do we have to rename ng4j.jar
> manually during the process of preparing a release?

This can be automated, Maven does it for you, for the ant build I can change 
build.xml to do it. 


> On Monday 01 June 2009 19:48:47 Jennifer Cormier wrote:
> > Tim,
> >
> > > If the last was 0.9 is this going to be 1.0 ?
> > > I don't think it can become 0.10
> > > Maybe 0.9.2? 1.0-rc1 ?
> >
> > Whether to continue incrementing and have the next release be 1.0 was
> > discussed in February.  I believe the decision was to continue with the
> > same type of versioning and move to 1.0, 1.1, etc.  For NG4J, 1.0 doesn't
> > have special significance.  Refer to the mailing list archives for the
> > discussion.
>
> I don't think we agreed on moving on to 1.0. Tim, what makes you think it
> cannot become 0.10?

You are making me unsure of myself now

This has been the subject of previous discussions, which I have not chased 
these down, but my 2p would be that numbers to the right of the first point may 
not exceed 9. 

For example the following all seem fine 

56.2.0.1 
1.2.3
1.2.3-RC1
1.2.3-SNAPSHOT 


but 0.10.1 seems odd to me. 

> @Jennifer: Thanks for your efforts on discovering the actual versions of
> the JARs. Regarding grddl.jar - I will try to upgrade to v0.3 next week
> when I am back home.

Cool, I will use 0.3 in the POM, which appears to work fine. 

> @Tim: I'm curious. Do we have to have all the JARs in CVS anyway? 

No, Maven does not keep the Jars in CVS, they are kept separately in a 
repository. 
However, at least for now, we want to support both Maven and Ant builds. 

> I am
> wondering whether it is one of the features of Maven to download them on
> demand?

Yes, this is correct. 

cheers
Tim

Re: [namedgraphs] new release

[Richard C. <ri...@cy...>]

On 2 Jun 2009, at 13:41, Olaf Hartig wrote:
> I'm fine with providing future versions of the NG4J JAR with a name  
> that
> reflects the version. Can we automate this or do we have to rename  
> ng4j.jar
> manually during the process of preparing a release?

This can be automated in the Ant build. See here for a buildfile that  
does this:

http://d2rq-map.cvs.sourceforge.net/viewvc/d2rq-map/d2rq-map/build.xml?revision=1.13&view=markup

Look at the jar, tar and zip targets, and how they use variables  
defined using <property> at the beginning of the file.

The version number is specified as a <property> near the beginning of  
the build file.

Richard



>
>
> On Monday 01 June 2009 19:48:47 Jennifer Cormier wrote:
>> Tim,
>>
>>> If the last was 0.9 is this going to be 1.0 ?
>>> I don't think it can become 0.10
>>> Maybe 0.9.2? 1.0-rc1 ?
>>
>> Whether to continue incrementing and have the next release be 1.0 was
>> discussed in February.  I believe the decision was to continue with  
>> the
>> same type of versioning and move to 1.0, 1.1, etc.  For NG4J, 1.0  
>> doesn't
>> have special significance.  Refer to the mailing list archives for  
>> the
>> discussion.
>
> I don't think we agreed on moving on to 1.0. Tim, what makes you  
> think it
> cannot become 0.10?
>
> @Jennifer: Thanks for your efforts on discovering the actual  
> versions of the
> JARs. Regarding grddl.jar - I will try to upgrade to v0.3 next week  
> when I am
> back home.
>
> @Tim: I'm curious. Do we have to have all the JARs in CVS anyway? I am
> wondering whether it is one of the features of Maven to download  
> them on
> demand?
>
> Greetings,
> Olaf
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the  
> latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> ng4j-namedgraphs mailing list
> ng4...@li...
> https://lists.sourceforge.net/lists/listinfo/ng4j-namedgraphs

[namedgraphs] FW: new release

[Jennifer C. <jen...@at...>]

> I don't think we agreed on moving on to 1.0. 

You're right, Olaf.  I misremembered the discussion.  We didn't come to a
final decision.

0.91 is another possibility for the next release version.


Jennifer

Re: [namedgraphs] new release

[Olaf H. <ha...@in...>]

Hey,

I'm fine with providing future versions of the NG4J JAR with a name that 
reflects the version. Can we automate this or do we have to rename ng4j.jar 
manually during the process of preparing a release?

On Monday 01 June 2009 19:48:47 Jennifer Cormier wrote:
> Tim,
>
> > If the last was 0.9 is this going to be 1.0 ?
> > I don't think it can become 0.10
> > Maybe 0.9.2? 1.0-rc1 ?
>
> Whether to continue incrementing and have the next release be 1.0 was
> discussed in February.  I believe the decision was to continue with the
> same type of versioning and move to 1.0, 1.1, etc.  For NG4J, 1.0 doesn't
> have special significance.  Refer to the mailing list archives for the
> discussion.

I don't think we agreed on moving on to 1.0. Tim, what makes you think it 
cannot become 0.10?

@Jennifer: Thanks for your efforts on discovering the actual versions of the 
JARs. Regarding grddl.jar - I will try to upgrade to v0.3 next week when I am 
back home.

@Tim: I'm curious. Do we have to have all the JARs in CVS anyway? I am 
wondering whether it is one of the features of Maven to download them on 
demand?

Greetings,
Olaf

Re: [namedgraphs] new release

[Jennifer C. <jen...@at...>]

Tim,

> If the last was 0.9 is this going to be 1.0 ?
> I don't think it can become 0.10
> Maybe 0.9.2? 1.0-rc1 ?

Whether to continue incrementing and have the next release be 1.0 was
discussed in February.  I believe the decision was to continue with the same
type of versioning and move to 1.0, 1.1, etc.  For NG4J, 1.0 doesn't have
special significance.  Refer to the mailing list archives for the
discussion.

> Do you know where grddl lives?

I'm not sure I completely understand the question.  I do know that the home
page for Jena GRDDL Reader is http://jena.sourceforge.net/grddl/, and that
site has a link to the download page.

> If my previous could be added to CVS I could create a patch, 
> or I can attach to an issue. 

Please go ahead and create an issue.  It looks like we usually make
"Patches" rather than "Bugs" or "Feature Requests", so you could do that.

As far as I'm concerned attaching the entire updated pom.xml is sufficient -
it doesn't need to be an actual patch to the existing pom.xml.


> If we do have a Maven build where should the artifacts be deployed to?

I don't know much about Maven and what having a build would require and what
the implications would be.  Could you provide more information?  Also, how
important is it to have a Maven build vs. simply supplying a pom.xml and
other configuration files (pom.properties?) so that people can build it
themselves?  What sort of artifacts are we talking about?  Is it necessary
to exlude tests that fail and in what file is that done?

My initial (uninformed) thought would be to provide the pom.xml and other
configuration files so that people could build NG4J using Maven.  Just like
we provide a .project file and .classpath file for people who use Eclipse.
That seems like a reasonable goal for this release.  

...

Everyone,

As far as upgrading libraries for this release, I think we should proceed
with caution but consider it.  I will test with the newest bouncycastle
libraries.  I don't use the semantic web client so someone else would need
to test and make a recommendation as to whether we upgrade GRDDL and its
dependent libraries, and to what versions.

One possible advantage to not adding version information to library names
which do not contain it would be to more easily retrieve CVS history
information on the JAR file.  However we definitely want to keep careful
track of versions from now on.


Jennifer

Re: [namedgraphs] new release

[Tim P. <tim...@ou...>]

Hi Jennifer, 

Sterling work. 

On Monday 01 June 2009 18:16:19 Jennifer Cormier wrote:
> More updates to LIBRARIES.txt, just committed.
>
> If a version number isn't part of a jar's name, then what I do to confirm
> the version is to download the library I think it is and check whether it
> is identical.  (This can be very painful when there are a lot of possible
> versions!  But I know of no other way to truly confirm the version.)

Yes, however when in doubt I tend to go for more recent versions and 
see if the tests all pass. 

> The two libraries whose versions I could not discern via available
> downloads were axis.jar and grddl.jar.  Based upon both its commit date and
> the fact that it's not 0.2 or 0.3, GRDDL appears to be pre-0.2.  For axis I
> couldn't download a version of the appropriate age for comparison purposes.

Oh, I thought it was 0.3. 
Everything compiles with 0.3.

I have not investigated the two failing tests.

> (I did not try to determine the version for all libraries.  For example
> jenatest.jar is distributed with Jena and probably does not have a separate
> version number.)

I believe that is correct.
I have submitted a new pom to jena, but they have yet to commit/accept it.

> The updated LIBRARIES.txt file has more version and source information, and
> also a column and key for whether or not to consider upgrading to a more
> recent version.

We need to change our version number every time we change the versions of 
our dependencies. 

Thanks for your time

Tim

Re: [namedgraphs] new release

[Jennifer C. <jen...@at...>]

More updates to LIBRARIES.txt, just committed.

If a version number isn't part of a jar's name, then what I do to confirm
the version is to download the library I think it is and check whether it is
identical.  (This can be very painful when there are a lot of possible
versions!  But I know of no other way to truly confirm the version.)

The two libraries whose versions I could not discern via available downloads
were axis.jar and grddl.jar.  Based upon both its commit date and the fact
that it's not 0.2 or 0.3, GRDDL appears to be pre-0.2.  For axis I couldn't
download a version of the appropriate age for comparison purposes.

(I did not try to determine the version for all libraries.  For example
jenatest.jar is distributed with Jena and probably does not have a separate
version number.)

The updated LIBRARIES.txt file has more version and source information, and
also a column and key for whether or not to consider upgrading to a more
recent version.


I'll reply to Tim's post in a separate message.


Jennifer

Re: [namedgraphs] new release

[Tim P. <tim...@ou...>]

On Friday 29 May 2009 19:35:20 Olaf Hartig wrote:
> On Friday 29 May 2009 19:35:22 Jennifer Cormier wrote:
[...]
> > Let's aim for the following week then for the release.  That will give us
> > more time to sort out the library list, the pom.xml, and upgrading
> > bouncycastle libraries.
>
> Okay.

Can we version our own output jar?

If the last was 0.9 is this going to be 1.0 ?
I don't think it can become 0.10
Maybe 0.9.2? 1.0-rc1 ?


> > Last night I checked in an initial version of LIBRARIES.txt in the /lib
> > directory.  I had versions for some but not all of the libraries included
> > with Jena 2.5.6.  There are some other gaps, too, like grddl.
>
> The log says:
>
> revision 1.1
> date: 2007/03/08 22:54:03;  author: sfakste;  state: Exp;
> Added the jena grddl library(-ies)

Do you know where grddl lives?
It is not in the hp repository, as far as I can see, consequently it is not in 
the main maven repository. 

> Looking at the Packages provided at the SourceForge project page for Jena I
> found grddl-0.3 - added this info to lib/LIBRARIES.txt
>
> > I also included a "source" column with the intent that we'd list the
> > location from which to obtain each library.
>
> Great idea.

Using LIBRARIES.txt  I have updated pom.xml to use the same versions.

If my previous could be added to CVS I could create a patch, or I can attach 
to an issue. 

I have compared the jars created by the ant build and the maven build. 

The Maven meta data files are: 
META-INF/maven/
META-INF/maven/de.fuberlin.wiwss.ng4j/
META-INF/maven/de.fuberlin.wiwss.ng4j/ng4j/
META-INF/maven/de.fuberlin.wiwss.ng4j/ng4j/pom.properties
META-INF/maven/de.fuberlin.wiwss.ng4j/ng4j/pom.xml

The Manifest is maven generated: 
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: timp
Build-Jdk: 1.6.0_13

The current ant build gives the following in MANIFEST.MF: 
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.1
Created-By: 11.3-b02 (Sun Microsystems Inc.)

The Maven generated jar currently contains the following additional files 
de/fuberlin/wiwiss/ng4j/swp/vocabulary/swp-3.rdf

de/fuberlin/wiwiss/ng4j/trig/parser/TriGAntlrParserTokenTypes.txt
de/fuberlin/wiwiss/ng4j/trig/parser/trig.g

I can exclude these.

If we do have a Maven build where should the artifacts be deployed to?
One option is to deploy to source forge.
Some while ago I did this for webmacro: 
http://webmacro.sourceforge.net/maven2/

I have explicitly excluded the two failing tests. 
        <exclude>**/*SWPSignatureUtilitiesTest.java</exclude>
        <exclude>**/*SWPNamedGraphSetTest.java</exclude>


I hope this helps. 

Tim