Re: Fixes to the schemagen plugin
On Fri, Jun 27, 2014 at 10:47 AM, Ian Dickinson wrote: > On Fri, Jun 27, 2014 at 3:31 PM, Benson Margulies > wrote: >> On Fri, Jun 27, 2014 at 10:05 AM, Ian Dickinson >> wrote: >>> Actually, now that I've reviewed it, there's a conflict between this >>> patch and the current behaviour. At the moment, the way to set the >>> output directory to something other than target/generated-sources is >>> to set the output configuration parameter. If this is a directory, >>> generated files go into that directory. If that option is set in the >>> defaults section of the schemagen config, it affects all of the >>> generated files. Tl;dr: there is already a mechanism for changing the >>> default output directory for all generated files. >>> >>> Voting to reject this patch until it's clearer why users need two >>> mechanisms for achieving the same end. >> >> So, I'll remove the redundancy, but have I convinced you about the >> problem of it not getting compiled? > Yes, absolutely. I'm not using the plugin day-by-day (I rarely do Java > dev these days, in fact), so direct experience by someone using the > tool definitely takes precedence. > > I'm actually not sure what the right solution here is. With the > current mechanism, the output directory can be specified on an > vocabulary-by-vocabulary basis. Any of those locations might already > be in the source tree already (e.g. we support the scenario where > someone generates the .java file directly under src/main/java, so that > the translated file can be kept under source control). So I'm not sure > - and you are in a better position to advise on this - that just > calling addCompileSourceRoot() on each output directory would be > correct. > > Perhaps the answer is that the location of the output files should > remain with the current configuration process, but there should be an > additional means, via the pom.xml, to add one or more directories to > the sources root. That could have a default value, so *if* the default > default output is left as target/generated-sources/jena, and *if* the > user doesn't change anything in the pom, then the output Java files > will still compile. To do exactly what you suggest, all we need to do is revert my change; the build-helper-maven-plugin is already a way to add a directory to the source roots via pom config. However, I have a more complex idea to offer you: Maybe redundancy is not redundancy. We tell users: If you want to just produce sources to include in the build, you use my new top-level property as the single source root, and we will add it to the build, and all will be well. If you want to do something more complex, you can use the older scheme, and it's up to you to arrange for it to compile, perhaps using the build-helper-maven-plugin. To make this really painless, we'd need one more boolean property: useOutputDirectory. Default is false, preserving old behavior. Set to true, gets new behavior, respecting new property. WDYT? > > With respect to changing the default, if writing to > target/generated-sources simply doesn't work with Maven 3, then the > change of default will be less intrusive, because presumably people > are not doing that at the moment. I still think it would be worth > raising on users@, to see if anyone would be impacted. > > There's enough complexity here that it's probably worth extending the > current set of integration tests to cover this new scenario. > agreed: > Ian
Re: Fixes to the schemagen plugin
On Fri, Jun 27, 2014 at 3:31 PM, Benson Margulies wrote: > On Fri, Jun 27, 2014 at 10:05 AM, Ian Dickinson > wrote: >> Actually, now that I've reviewed it, there's a conflict between this >> patch and the current behaviour. At the moment, the way to set the >> output directory to something other than target/generated-sources is >> to set the output configuration parameter. If this is a directory, >> generated files go into that directory. If that option is set in the >> defaults section of the schemagen config, it affects all of the >> generated files. Tl;dr: there is already a mechanism for changing the >> default output directory for all generated files. >> >> Voting to reject this patch until it's clearer why users need two >> mechanisms for achieving the same end. > > So, I'll remove the redundancy, but have I convinced you about the > problem of it not getting compiled? Yes, absolutely. I'm not using the plugin day-by-day (I rarely do Java dev these days, in fact), so direct experience by someone using the tool definitely takes precedence. I'm actually not sure what the right solution here is. With the current mechanism, the output directory can be specified on an vocabulary-by-vocabulary basis. Any of those locations might already be in the source tree already (e.g. we support the scenario where someone generates the .java file directly under src/main/java, so that the translated file can be kept under source control). So I'm not sure - and you are in a better position to advise on this - that just calling addCompileSourceRoot() on each output directory would be correct. Perhaps the answer is that the location of the output files should remain with the current configuration process, but there should be an additional means, via the pom.xml, to add one or more directories to the sources root. That could have a default value, so *if* the default default output is left as target/generated-sources/jena, and *if* the user doesn't change anything in the pom, then the output Java files will still compile. With respect to changing the default, if writing to target/generated-sources simply doesn't work with Maven 3, then the change of default will be less intrusive, because presumably people are not doing that at the moment. I still think it would be worth raising on users@, to see if anyone would be impacted. There's enough complexity here that it's probably worth extending the current set of integration tests to cover this new scenario. Ian
Re: Fixes to the schemagen plugin
On Fri, Jun 27, 2014 at 10:05 AM, Ian Dickinson wrote: > Actually, now that I've reviewed it, there's a conflict between this > patch and the current behaviour. At the moment, the way to set the > output directory to something other than target/generated-sources is > to set the output configuration parameter. If this is a directory, > generated files go into that directory. If that option is set in the > defaults section of the schemagen config, it affects all of the > generated files. Tl;dr: there is already a mechanism for changing the > default output directory for all generated files. > > Voting to reject this patch until it's clearer why users need two > mechanisms for achieving the same end. So, I'll remove the redundancy, but have I convinced you about the problem of it not getting compiled? > > Ian
Re: Fixes to the schemagen plugin
On Fri, Jun 27, 2014 at 2:21 PM, Benson Margulies wrote: > Once you all are comfy with the changes from last night In addition, as I said in the Jira comment, I'm *un*comfy with changing default output locations with zero notice. I can easily see this breaking automated builds or other workflows. At the very least, we should consult with users@ before making this change. Ian
Re: Fixes to the schemagen plugin
Actually, now that I've reviewed it, there's a conflict between this patch and the current behaviour. At the moment, the way to set the output directory to something other than target/generated-sources is to set the output configuration parameter. If this is a directory, generated files go into that directory. If that option is set in the defaults section of the schemagen config, it affects all of the generated files. Tl;dr: there is already a mechanism for changing the default output directory for all generated files. Voting to reject this patch until it's clearer why users need two mechanisms for achieving the same end. Ian
[jira] [Commented] (JENA-731) schemagen does not add the generated source directory to the source roots
[ https://issues.apache.org/jira/browse/JENA-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045941#comment-14045941 ] Benson Margulies commented on JENA-731: --- It is a bug. When you run maven 3.0.4 with the current version, those sources do not get compiled; no class files appear. I've read or modified a large number of plugins that generate sources, and none just put the packages directly in there. Yes, it's incompatible; since it's configurable we could put the default back as it was, or we can make noise at the next release. > schemagen does not add the generated source directory to the source roots > - > > Key: JENA-731 > URL: https://issues.apache.org/jira/browse/JENA-731 > Project: Apache Jena > Issue Type: Bug > Components: Cmd line tools >Affects Versions: Jena 2.11.2 >Reporter: Benson Margulies > Fix For: Jena 2.12.0 > > > The plugin neglects to add a source root. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Fixes to the schemagen plugin
Once you all are comfy with the changes from last night and this morning, I'll attempt a bit of housecleaning of that form. On Fri, Jun 27, 2014 at 8:55 AM, Ian Dickinson wrote: > On Fri, Jun 27, 2014 at 12:35 PM, Benson Margulies > wrote: >> I wonder why the POM has apache repositories in it, since you >> presumably have the Apache uber-parent at the top that provides them. > Probably an artefact of the plugin being developed outside of Apache > and then donated and integrated into the project. If you think they > can be be removed, I'm happy with that. > > Ian
Re: Fixes to the schemagen plugin
On Fri, Jun 27, 2014 at 12:35 PM, Benson Margulies wrote: > I wonder why the POM has apache repositories in it, since you > presumably have the Apache uber-parent at the top that provides them. Probably an artefact of the plugin being developed outside of Apache and then donated and integrated into the project. If you think they can be be removed, I'm happy with that. Ian
[jira] [Commented] (JENA-731) schemagen does not add the generated source directory to the source roots
[ https://issues.apache.org/jira/browse/JENA-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045909#comment-14045909 ] Ian Dickinson commented on JENA-731: I think this is an improvement, not a bug. As I understood it the previous default, target/generated-sources, is already a source root by default. I'm concerned that changing the *default* output directory with no warning could break users' builds, if they have other tools that use the current output location. At the very least, this change should be documented in the changelog. > schemagen does not add the generated source directory to the source roots > - > > Key: JENA-731 > URL: https://issues.apache.org/jira/browse/JENA-731 > Project: Apache Jena > Issue Type: Bug > Components: Cmd line tools >Affects Versions: Jena 2.11.2 >Reporter: Benson Margulies > Fix For: Jena 2.12.0 > > > The plugin neglects to add a source root. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Fixes to the schemagen plugin
I've fixed the enforcer complaints. Generally, people building maven plugins don't enable that check, because maven's internal compatibility invariants make it unhelpful. But I sorted out the versions and exclusions to make it happy. In the version front, I assert that people want to be able to correlate versions in JIRA with the they specify for a plugin. I wonder why the POM has apache repositories in it, since you presumably have the Apache uber-parent at the top that provides them. On Fri, Jun 27, 2014 at 6:47 AM, Andy Seaborne wrote: > On 27/06/14 11:12, Benson Margulies wrote: >> >> Shall I make the plugin have that version number, too? > > > If you leave the for the moment, we can discuss the long term > policy. > > >> >> I'll fix the enforcer glitch. > > > Thanks - the solution didn't jump straight out at me. > > Andy > > >> >> On Fri, Jun 27, 2014 at 4:00 AM, Andy Seaborne wrote: >>> >>> On 27/06/14 03:35, Benson Margulies wrote: OK, got into JIRA, created two jiras, committed, marked them resolved. >>> >>> >>> >>> Great - there's a build problem as noted because the enforcer enforces. >>> >>> Andy, could you please add a component for the jena-maven-tools and a version for 0.5 and 0.6 and I'll spruce them up further. >>> >>> >>> >>> Component "Maven Tool" added to JIRA. >>> >>> I don't what everyone else thinks but you might as well use the Jena >>> version >>> number. >>> >>> It is part of the main build/release cycle now and releases are what >>> affect >>> users. It's also what people seem to use for labels on reports. >>> >>> TDB's (internal) version reflects disk format, but nowadays such a >>> chanage >>> is going to be a Jena change. I've just removed the active JIRA version. >>> >>> Andy >>> >>> On Thu, Jun 26, 2014 at 9:42 PM, Benson Margulies wrote: > > > Hi folks. > > I'm temporarily locked out of JIRA. I have some fixes to the maven > plugin. > > If infra unsticks me, I'll make a JIRA, but if not, would anyone be > disturbed if I made a jira-less commit? > > The fixes are: > > 1: make the default output generated-sources/jena. Using > generated-sources tangles up with 'annotations'. > > 2: make the output directory configurable. > > 3: add the output directory to the source roots. > > --benson >>> >>> >>> >
[jira] [Commented] (JENA-731) schemagen does not add the generated source directory to the source roots
[ https://issues.apache.org/jira/browse/JENA-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045838#comment-14045838 ] ASF subversion and git services commented on JENA-731: -- Commit 1606036 from [~bmargulies] in branch 'jena/trunk' [ https://svn.apache.org/r1606036 ] JENA-731: deal with dependency convergence. > schemagen does not add the generated source directory to the source roots > - > > Key: JENA-731 > URL: https://issues.apache.org/jira/browse/JENA-731 > Project: Apache Jena > Issue Type: Bug > Components: Cmd line tools >Affects Versions: Jena 2.11.2 >Reporter: Benson Margulies > Fix For: Jena 2.12.0 > > > The plugin neglects to add a source root. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Fixes to the schemagen plugin
On 27/06/14 11:12, Benson Margulies wrote: Shall I make the plugin have that version number, too? If you leave the for the moment, we can discuss the long term policy. I'll fix the enforcer glitch. Thanks - the solution didn't jump straight out at me. Andy On Fri, Jun 27, 2014 at 4:00 AM, Andy Seaborne wrote: On 27/06/14 03:35, Benson Margulies wrote: OK, got into JIRA, created two jiras, committed, marked them resolved. Great - there's a build problem as noted because the enforcer enforces. Andy, could you please add a component for the jena-maven-tools and a version for 0.5 and 0.6 and I'll spruce them up further. Component "Maven Tool" added to JIRA. I don't what everyone else thinks but you might as well use the Jena version number. It is part of the main build/release cycle now and releases are what affect users. It's also what people seem to use for labels on reports. TDB's (internal) version reflects disk format, but nowadays such a chanage is going to be a Jena change. I've just removed the active JIRA version. Andy On Thu, Jun 26, 2014 at 9:42 PM, Benson Margulies wrote: Hi folks. I'm temporarily locked out of JIRA. I have some fixes to the maven plugin. If infra unsticks me, I'll make a JIRA, but if not, would anyone be disturbed if I made a jira-less commit? The fixes are: 1: make the default output generated-sources/jena. Using generated-sources tangles up with 'annotations'. 2: make the output directory configurable. 3: add the output directory to the source roots. --benson
Re: Fixes to the schemagen plugin
Shall I make the plugin have that version number, too? I'll fix the enforcer glitch. On Fri, Jun 27, 2014 at 4:00 AM, Andy Seaborne wrote: > On 27/06/14 03:35, Benson Margulies wrote: >> >> OK, got into JIRA, created two jiras, committed, marked them resolved. > > > Great - there's a build problem as noted because the enforcer enforces. > > >> >> Andy, could you please add a component for the jena-maven-tools and a >> version for 0.5 and 0.6 and I'll spruce them up further. > > > Component "Maven Tool" added to JIRA. > > I don't what everyone else thinks but you might as well use the Jena version > number. > > It is part of the main build/release cycle now and releases are what affect > users. It's also what people seem to use for labels on reports. > > TDB's (internal) version reflects disk format, but nowadays such a chanage > is going to be a Jena change. I've just removed the active JIRA version. > > Andy > > >> >> On Thu, Jun 26, 2014 at 9:42 PM, Benson Margulies >> wrote: >>> >>> Hi folks. >>> >>> I'm temporarily locked out of JIRA. I have some fixes to the maven >>> plugin. >>> >>> If infra unsticks me, I'll make a JIRA, but if not, would anyone be >>> disturbed if I made a jira-less commit? >>> >>> The fixes are: >>> >>> 1: make the default output generated-sources/jena. Using >>> generated-sources tangles up with 'annotations'. >>> >>> 2: make the output directory configurable. >>> >>> 3: add the output directory to the source roots. >>> >>> --benson > >
[jira] [Closed] (JENA-720) NodeId does not handle BigDecimal correctly
[
https://issues.apache.org/jira/browse/JENA-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne closed JENA-720.
--
Resolution: Fixed
> NodeId does not handle BigDecimal correctly
> ---
>
> Key: JENA-720
> URL: https://issues.apache.org/jira/browse/JENA-720
> Project: Apache Jena
> Issue Type: Bug
> Components: TDB
>Affects Versions: Jena 2.11.2
>Reporter: Marek Kowalczyk
>Assignee: Andy Seaborne
> Fix For: Jena 2.12.0
>
> Attachments: JENA-720.patch
>
>
> There is an bug in NodeId. extract(NodeId nodeId)
> {code}
> case DECIMAL:
> {
> BigDecimal d = DecimalNode.unpackAsBigDecimal(v) ;
> String x = d.toEngineeringString() ;
> return NodeFactory.createLiteral(x, null,
> XSDDatatype.XSDdecimal) ;
> }
> {code}
> NodeFactory.createLiteral is expecting that x will be valid lexical form,
> while d.toEngineeringString() is not.
> It should be:
> {code}
> case DECIMAL:
> {
> BigDecimal d = DecimalNode.unpackAsBigDecimal(v) ;
> String x = d.toPlainString() ;
> return NodeFactory.createLiteral(x, null,
> XSDDatatype.XSDdecimal) ;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: GSoC : CSV PropertyTables : mid-term checkpoint
Hi, Here's the mid-term report. In short, this project is to make Jena SPARQL processing abilities on CSVs, or generally, the regular table shaped data. Project Progress: I changed the project plan a bit. In the first half part, I actually worked on: 2.1 RIOT Reader for CSV Files ( done ) 1.2 PropertyTable ( the design of the API ) 1.3 GraphPropertyTable ( a preliminary implementation based on Hashmap ) In the remaining weeks, I'm supposed to complete the followings: 2.2 CSV2RDF tool 2.3 OpExecutor Optimization for GraphPropertyTable 1.1 CSV Parser The project plan is going on well, but there're some issues that pointed out by Andy to be resolved: (1) I'll evaluate (e.g. by testing with large data) the current implementation PropertyTable and GraphPropertyTable, and try to optimize it with a smaller storage cost (e.g, by removing and adding some indexes, to support fast "find by subject column/value then get row by subject" query, which is slow now). Or make a new implementation (maybe Java array) to compare. This work should also consider the part of 2.3, related source code need to be investigated before hand. (2) Currently the tests are restricted in some examples for demonstration. I'll make more (structured) tests, especially for 1.1 and 2.1 (3) Documentation with examples for users in the Jena website. So far, I've got much more insights of Jena thanks to the project. The challenging problem of (1) interests me the most. I appreciate the help from Andy very much. Cheers, Ying Jiang On Tue, Jun 24, 2014 at 4:26 AM, Andy Seaborne wrote: > Hi Ying, > > It's the mid-point of the GSoC programme so it's a good time to assess the > state of the project. It looks close to the plan and I'd like you to > (briefly) write-up how the project is going. Check you are getting what you > want out of the project as well. It is not just code production. Is the > rest of the plan looking right still? > > > Looking on at the repository, there are a few things I'd like to see: > > 1/ More tests - tests should be structured so each tests a specific thing so > when/if there are test failures, it's easier to see what might the the root > cause. > > 2/ Examples and documentation > > 3/ Evaluation : > > For example, is the property table specialisation resulting in a smaller > storage cost? And, iteratively, can the design be changed to be more > compact? Maybe some indexing isn't needed; maybe a different way to index > the same access patterns would take less space. > > > > Other: > > The code can be packaged under org.apache.jena. We're trying to avoid > com.hp.hpl.jena. > > A specific question: > > Access by subject is an important use case even when the rows are blank > nodes. It will matter for SPARQL and even in since - "find by subject > column/value then get row by subject", that is two graph.find calls, seems a > reasonable access pattern. > > I could not see that graph.find(subject, ANY, ANY) is using > PropertyTable.getRow in the graph.find codepath and I expected it would be. > Did I miss something? > > Andy
[jira] [Updated] (JENA-731) schemagen does not add the generated source directory to the source roots
[ https://issues.apache.org/jira/browse/JENA-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-731: --- Assignee: (was: Andy Seaborne) > schemagen does not add the generated source directory to the source roots > - > > Key: JENA-731 > URL: https://issues.apache.org/jira/browse/JENA-731 > Project: Apache Jena > Issue Type: Bug > Components: Cmd line tools >Affects Versions: Jena 2.11.2 >Reporter: Benson Margulies > Fix For: Jena 2.12.0 > > > The plugin neglects to add a source root. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JENA-731) schemagen does not add the generated source directory to the source roots
[ https://issues.apache.org/jira/browse/JENA-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-731: --- Affects Version/s: Jena 2.11.2 > schemagen does not add the generated source directory to the source roots > - > > Key: JENA-731 > URL: https://issues.apache.org/jira/browse/JENA-731 > Project: Apache Jena > Issue Type: Bug > Components: Cmd line tools >Affects Versions: Jena 2.11.2 >Reporter: Benson Margulies > Fix For: Jena 2.12.0 > > > The plugin neglects to add a source root. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JENA-731) schemagen does not add the generated source directory to the source roots
[ https://issues.apache.org/jira/browse/JENA-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-731: --- Fix Version/s: Jena 2.12.0 > schemagen does not add the generated source directory to the source roots > - > > Key: JENA-731 > URL: https://issues.apache.org/jira/browse/JENA-731 > Project: Apache Jena > Issue Type: Bug > Components: Cmd line tools >Affects Versions: Jena 2.11.2 >Reporter: Benson Margulies > Fix For: Jena 2.12.0 > > > The plugin neglects to add a source root. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (JENA-731) schemagen does not add the generated source directory to the source roots
[ https://issues.apache.org/jira/browse/JENA-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne reassigned JENA-731: -- Assignee: Andy Seaborne > schemagen does not add the generated source directory to the source roots > - > > Key: JENA-731 > URL: https://issues.apache.org/jira/browse/JENA-731 > Project: Apache Jena > Issue Type: Bug > Components: Cmd line tools >Affects Versions: Jena 2.11.2 >Reporter: Benson Margulies >Assignee: Andy Seaborne > Fix For: Jena 2.12.0 > > > The plugin neglects to add a source root. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Fixes to the schemagen plugin
On 27/06/14 03:35, Benson Margulies wrote: OK, got into JIRA, created two jiras, committed, marked them resolved. Great - there's a build problem as noted because the enforcer enforces. Andy, could you please add a component for the jena-maven-tools and a version for 0.5 and 0.6 and I'll spruce them up further. Component "Maven Tool" added to JIRA. I don't what everyone else thinks but you might as well use the Jena version number. It is part of the main build/release cycle now and releases are what affect users. It's also what people seem to use for labels on reports. TDB's (internal) version reflects disk format, but nowadays such a chanage is going to be a Jena change. I've just removed the active JIRA version. Andy On Thu, Jun 26, 2014 at 9:42 PM, Benson Margulies wrote: Hi folks. I'm temporarily locked out of JIRA. I have some fixes to the maven plugin. If infra unsticks me, I'll make a JIRA, but if not, would anyone be disturbed if I made a jira-less commit? The fixes are: 1: make the default output generated-sources/jena. Using generated-sources tangles up with 'annotations'. 2: make the output directory configurable. 3: add the output directory to the source roots. --benson
[jira] [Updated] (JENA-720) NodeId does not handle BigDecimal correctly
[
https://issues.apache.org/jira/browse/JENA-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne updated JENA-720:
---
Fix Version/s: (was: TDB 1.1.0)
Jena 2.12.0
> NodeId does not handle BigDecimal correctly
> ---
>
> Key: JENA-720
> URL: https://issues.apache.org/jira/browse/JENA-720
> Project: Apache Jena
> Issue Type: Bug
> Components: TDB
>Affects Versions: Jena 2.11.2
>Reporter: Marek Kowalczyk
>Assignee: Andy Seaborne
> Fix For: Jena 2.12.0
>
> Attachments: JENA-720.patch
>
>
> There is an bug in NodeId. extract(NodeId nodeId)
> {code}
> case DECIMAL:
> {
> BigDecimal d = DecimalNode.unpackAsBigDecimal(v) ;
> String x = d.toEngineeringString() ;
> return NodeFactory.createLiteral(x, null,
> XSDDatatype.XSDdecimal) ;
> }
> {code}
> NodeFactory.createLiteral is expecting that x will be valid lexical form,
> while d.toEngineeringString() is not.
> It should be:
> {code}
> case DECIMAL:
> {
> BigDecimal d = DecimalNode.unpackAsBigDecimal(v) ;
> String x = d.toPlainString() ;
> return NodeFactory.createLiteral(x, null,
> XSDDatatype.XSDdecimal) ;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (JENA-720) NodeId does not handle BigDecimal correctly
[
https://issues.apache.org/jira/browse/JENA-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne updated JENA-720:
---
Affects Version/s: (was: TDB 1.0.1)
Jena 2.11.2
> NodeId does not handle BigDecimal correctly
> ---
>
> Key: JENA-720
> URL: https://issues.apache.org/jira/browse/JENA-720
> Project: Apache Jena
> Issue Type: Bug
> Components: TDB
>Affects Versions: Jena 2.11.2
>Reporter: Marek Kowalczyk
>Assignee: Andy Seaborne
> Fix For: Jena 2.12.0
>
> Attachments: JENA-720.patch
>
>
> There is an bug in NodeId. extract(NodeId nodeId)
> {code}
> case DECIMAL:
> {
> BigDecimal d = DecimalNode.unpackAsBigDecimal(v) ;
> String x = d.toEngineeringString() ;
> return NodeFactory.createLiteral(x, null,
> XSDDatatype.XSDdecimal) ;
> }
> {code}
> NodeFactory.createLiteral is expecting that x will be valid lexical form,
> while d.toEngineeringString() is not.
> It should be:
> {code}
> case DECIMAL:
> {
> BigDecimal d = DecimalNode.unpackAsBigDecimal(v) ;
> String x = d.toPlainString() ;
> return NodeFactory.createLiteral(x, null,
> XSDDatatype.XSDdecimal) ;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (JENA-732) Default generation target for schemagen maven plugin needs a dir
[ https://issues.apache.org/jira/browse/JENA-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-732: --- Affects Version/s: Jena 2.11.2 > Default generation target for schemagen maven plugin needs a dir > > > Key: JENA-732 > URL: https://issues.apache.org/jira/browse/JENA-732 > Project: Apache Jena > Issue Type: Bug > Components: Maven Tools >Affects Versions: Jena 2.11.2 >Reporter: Benson Margulies > > target/generated-sources is the root of roots; it typically contains > directories that in turn contain directories. Adding a /jena would make > sense. Also, making the directory configurable would be nice. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (JENA-720) NodeId does not handle BigDecimal correctly
[
https://issues.apache.org/jira/browse/JENA-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne reopened JENA-720:
Reopen to adjust versions.
> NodeId does not handle BigDecimal correctly
> ---
>
> Key: JENA-720
> URL: https://issues.apache.org/jira/browse/JENA-720
> Project: Apache Jena
> Issue Type: Bug
> Components: TDB
>Affects Versions: Jena 2.11.2
>Reporter: Marek Kowalczyk
>Assignee: Andy Seaborne
> Fix For: Jena 2.12.0
>
> Attachments: JENA-720.patch
>
>
> There is an bug in NodeId. extract(NodeId nodeId)
> {code}
> case DECIMAL:
> {
> BigDecimal d = DecimalNode.unpackAsBigDecimal(v) ;
> String x = d.toEngineeringString() ;
> return NodeFactory.createLiteral(x, null,
> XSDDatatype.XSDdecimal) ;
> }
> {code}
> NodeFactory.createLiteral is expecting that x will be valid lexical form,
> while d.toEngineeringString() is not.
> It should be:
> {code}
> case DECIMAL:
> {
> BigDecimal d = DecimalNode.unpackAsBigDecimal(v) ;
> String x = d.toPlainString() ;
> return NodeFactory.createLiteral(x, null,
> XSDDatatype.XSDdecimal) ;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (JENA-732) Default generation target for schemagen maven plugin needs a dir
[ https://issues.apache.org/jira/browse/JENA-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-732: --- Component/s: Maven Tools > Default generation target for schemagen maven plugin needs a dir > > > Key: JENA-732 > URL: https://issues.apache.org/jira/browse/JENA-732 > Project: Apache Jena > Issue Type: Bug > Components: Maven Tools >Reporter: Benson Margulies > > target/generated-sources is the root of roots; it typically contains > directories that in turn contain directories. Adding a /jena would make > sense. Also, making the directory configurable would be nice. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Fixes to the schemagen plugin
benson, We have a build failure: https://builds.apache.org/user/andy/my-views/view/Jena/job/Jena_Development_Test/1311/ org.apache.maven:maven-project:2.2.1 is way out of date causes dependency convergence errors on: org.apache.maven:maven-model junit:junit org.codehaus.plexus:plexus-utils and others. We run the enforcer plugin ... so the build breaks. maven-project:2.2.1 was released in Aug 2009. Andy On 27/06/14 03:35, Benson Margulies wrote: OK, got into JIRA, created two jiras, committed, marked them resolved. Andy, could you please add a component for the jena-maven-tools and a version for 0.5 and 0.6 and I'll spruce them up further. On Thu, Jun 26, 2014 at 9:42 PM, Benson Margulies wrote: Hi folks. I'm temporarily locked out of JIRA. I have some fixes to the maven plugin. If infra unsticks me, I'll make a JIRA, but if not, would anyone be disturbed if I made a jira-less commit? The fixes are: 1: make the default output generated-sources/jena. Using generated-sources tangles up with 'annotations'. 2: make the output directory configurable. 3: add the output directory to the source roots. --benson
