Tyler Palsulich created OODT-825:
------------------------------------
Summary: Fix Radix script archetype version
Key: OODT-825
URL: https://issues.apache.org/jira/browse/OODT-825
Project: OODT
Issue Type: Bug
Reporter: Tyler Palsulich
Assignee: Tyler Palsulich
The radix script has the wrong version of the archetype and of OODT, as found by Konstantinos
Mavromatis.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[ https://issues.apache.org/jira/browse/OODT-824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14341910#comment-14341910
]
Chris A. Mattmann commented on OODT-824:
----------------------------------------
Made some progress on this today in r1663022. Going to be a while.
For now:
* disabled curator build in OODT pom.xml
* didn't commit this but I am experimenting with shutting off the Scala compiler in oodt-core
(I will file a separate issue for this - it shouldn't be part of OODT-core)
* also experimenting with removing Spring dependencies from the file manager (was trying to
solve the logging problem, but that wasn't it) - take care of in r1663023.
* trying to figure out the right hierarchy of assets, and which ones are actually used in
the curator. We had multiple versions of jquery and even source files for some of the libraries.
Those are gone now.
* got the HomePage of the curator cockpit displaying in Wicket and set up the project and
path. the cockpit displays when you run this in an embedded Tomcat with mvn tomcat7:run-war
Still TODO:
* refactor the curator services into its own project likely curator/curator-services and then
have curator/curator-webapp and then remove the services from this project
* overlay curator-services on this project as a dependency
* refactor the CuratorCockpit into a webapp/oodt-webapp-components project so it can be dropped
into the OPSUI
* overlay curator-services on OPSUI
* porting over the login pages and SSO functionality
* adding in the EDRN and LMMP skins to show skinning
* creating a default OODT skin for the curator
> Port the Curator to Apache Wicket
> ---------------------------------
>
> Key: OODT-824
> URL: https://issues.apache.org/jira/browse/OODT-824
> Project: OODT
> Issue Type: Bug
> Components: curator
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Fix For: 0.9
>
>
> To remain consistent with the rest of the components and modules we have, I am going
to port the Curator over to use Apache Wicket. Wish me luck!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OODT-823) OODT build fails when using maven 3 with jdk8. Specifically while generating javadocs (the javadoc compiler that ships with JDK8 throws errors if the javadoc does not conform to the format prescribed for javadocs under jdk8)"Aditya Dhulipala (JIRA)" <jira@apache.org>urn:uuid:%3cJIRA-12776772-1424669489000-110344-1424669531493@Atlassian-JIRA%3e2015-02-23T05:32:11Z

[ https://issues.apache.org/jira/browse/OODT-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris A. Mattmann updated OODT-819:
-----------------------------------
Description: I've noticed while using the SolrFMCatalog that CAS fields are not populated
correctly. For example, some of the CAS fields are required like CAS.ProductReceivedTime -
all sorts of downstream apps (FM prod webapp; OPSUI; etc) that depend on these fields break
with the current SolrFMCatalog implementation. Another thing I noticed is that ProductType
isn't added directly to the catalog as it is passed in - for example I pass in ProductType
and CAS.ProductType is what gets cataloged, regardless of what I passed in. This needs to
be fixed.
> SolrCatalog doesn't populate CAS fields correctly
> -------------------------------------------------
>
> Key: OODT-819
> URL: https://issues.apache.org/jira/browse/OODT-819
> Project: OODT
> Issue Type: Bug
> Components: file manager
> Affects Versions: 0.8, 0.8.1
> Reporter: Chris A. Mattmann
> Fix For: 0.9
>
>
> I've noticed while using the SolrFMCatalog that CAS fields are not populated correctly.
For example, some of the CAS fields are required like CAS.ProductReceivedTime - all sorts
of downstream apps (FM prod webapp; OPSUI; etc) that depend on these fields break with the
current SolrFMCatalog implementation. Another thing I noticed is that ProductType isn't added
directly to the catalog as it is passed in - for example I pass in ProductType and CAS.ProductType
is what gets cataloged, regardless of what I passed in. This needs to be fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OODT-818) CmdLineIngester should log there was an exception and move on during ingest"Chris A. Mattmann (JIRA)" <jira@apache.org>urn:uuid:%3cJIRA-12775739-1424208330000-68937-1424210894996@Atlassian-JIRA%3e2015-02-17T22:08:15Z