[jira] [Commented] (JCS-87) Migrate to build with Maven 3.0

["Diego Rivera (Commented) (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JCS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188758#comment-13188758 ] 

Diego Rivera commented on JCS-87:
---------------------------------

Forgot to add that most of the failed tests (above) don't appear to have anything to do with the (RMI?) server not being started.  Furthermore, for newer mechanisms something like an embedded tomcat (Jetty?) could be used when that's needed for integration tests, using commons-daemon 
                
> Migrate to build with Maven 3.0
> -------------------------------
>
>                 Key: JCS-87
>                 URL: https://issues.apache.org/jira/browse/JCS-87
>             Project: Commons JCS
>          Issue Type: Improvement
>    Affects Versions: jcs-1.3
>            Reporter: Diego Rivera
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> Evidently, the documentation clearly states that Maven 1.x is the only supported mechanism to build JCS.  However, this is very dated and it wouldn't be a bad idea to update the build process to more modern/current standards.
> I've tried to do this, and have run into a few snags wrt tests - I get many unit tests failures in what I expect should have been trivial tests:
> Failed tests:   testIndexedDiskCache4(org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheSameRegionConcurrentUnitTest$4): expected:<indexedRegion4 data 2200> but was:<null>
>   testIndexedDiskCache5(org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheSameRegionConcurrentUnitTest$5): expected:<indexedRegion4 data 0> but was:<null>
>   testIndexedDiskCache1(org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheNoMemoryUnitTest$1): expected:<indexedRegion1 data 0> but was:<null>
>   testIndexedDiskCache3(org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheNoMemoryUnitTest$3): expected:<indexedRegion3 data 0> but was:<null>
>   testIndexedDiskCache2(org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheNoMemoryUnitTest$2): expected:<indexedRegion2 data 0> but was:<null>
>   testBlockDiskCache1(org.apache.jcs.auxiliary.disk.block.BlockDiskCacheSameRegionConcurrentUnitTest$1): Wrong value for key [0:key] expected:<blockRegion4 data 0-blockRegion4> but was:<null>
>   testBlockDiskCache2(org.apache.jcs.auxiliary.disk.block.BlockDiskCacheSameRegionConcurrentUnitTest$2): Wrong value for key [1000:key] expected:<blockRegion4 data 1000-blockRegion4> but was:<null>
>   testBlockDiskCache3(org.apache.jcs.auxiliary.disk.block.BlockDiskCacheSameRegionConcurrentUnitTest$3): Wrong value for key [2000:key] expected:<blockRegion4 data 2000-blockRegion4> but was:<null>
>   testBlockDiskCache4(org.apache.jcs.auxiliary.disk.block.BlockDiskCacheSameRegionConcurrentUnitTest$4): Wrong value for key [2200:key] expected:<blockRegion4 data 2200-blockRegion4> but was:<null>
>   testExpireInBackground(org.apache.jcs.auxiliary.disk.jdbc.JDBCDiskCacheShrinkUnitTest): Removed key should be null: 0:key
>   testSpoolEvent(org.apache.jcs.engine.control.event.SimpleEventHandlingUnitTest): The number of ELEMENT_EVENT_SPOOLED_DISK_AVAILABLE events [0] does not equal the number expected [20000]
>   testSpoolNoDiskEvent(org.apache.jcs.engine.control.event.SimpleEventHandlingUnitTest): The number of ELEMENT_EVENT_SPOOLED_DISK_NOT_AVAILABLE events  [19002] does not equal the number expected.
>   testSpoolNotAllowedEvent(org.apache.jcs.engine.control.event.SimpleEventHandlingUnitTest): The number of ELEMENT_EVENT_SPOOLED_NOT_ALLOWED events [0] does not equal the number expected.
>   testSpoolNotAllowedEventOnItem(org.apache.jcs.engine.control.event.SimpleEventHandlingUnitTest): The number of ELEMENT_EVENT_SPOOLED_NOT_ALLOWED events [0] does not equal the number expected.
>   testUpdateConfig(org.apache.jcs.engine.control.CompositeCacheDiskUsageUnitTest): expected:<1> but was:<0>
>   testSystemPropertyUsage(org.apache.jcs.engine.SystemPropertyUsageUnitTest): System property value is not reflected expected:<1000> but was:<6789>
>   testLoadFromCCF(org.apache.jcs.engine.memory.mru.MRUMemoryCacheUnitTest): Cache name should have MRU in it.
>   testGetStatsThroughHub(org.apache.jcs.engine.memory.mru.MRUMemoryCacheUnitTest): Should have 200 puts
>   testDefaultConfigUndefinedPool(org.apache.jcs.utils.threadpool.ThreadPoolManagerUnitTest): expected:<150> but was:<151>
>   testNonExistentConfigFile(org.apache.jcs.utils.threadpool.ThreadPoolManagerUnitTest): expected:<150> but was:<151>
>   testWaitPolicyConfig(org.apache.jcs.utils.threadpool.ThreadPoolManagerUnitTest): Max is wrong expected:<150> but was:<11>
>   testNoBoundary(org.apache.jcs.utils.threadpool.ThreadPoolManagerUnitTest): Should have a linked queue and not a bounded buffer.
>   testSystemPropertyInValueDelimeter(org.apache.jcs.access.SystemPropetyUnitTest): We should have used the system property for the memory size expected:<1234> but was:<6789>
> Tests in error: 
>   test(org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPFilterRemoveHashCodeUnitTest): Socket is null, cannot connect to localhost:1110
>   testPutLocalPutRemoteGetBusyVerifyRemoved(org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPIssueRemoveOnPutUnitTest): Socket is null, cannot connect to localhost:1110
>   testStandardPut(org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPIssueRemoveOnPutUnitTest): Socket is null, cannot connect to localhost:1110
> Clearly something needs to be started to listen on that port (the RMI server, maybe?).  However, the build documentation makes no mention of this anywhere.  Migrating to a newer build mechanism may not fix this (and other) issues, but it would help revise the build process and perhaps find more elegant and future-proof mechanisms to meet these testing requirements.
> If you'd like help implementing this feature, I might be able to provide time and effort towards this goal if someone helps me understand the full build process top-to-bottom.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira