Re: Potential problems in the XmlInputSource class...
Sure. Please open a JIRA issue and provide a patch. You can
just paste your message into the issue.
--Thilo
On 3/10/2010 17:35, Baptiste Gaillard wrote:
>
> Hi,
>
> I've read multiple messages about UIMA and OSGI on this forum.
>
> On our project we have successfully integrated UIMA components inside OSGI
> Bundle (our solution provides an automatic OSGI Bundle genration system which
> take PEAR files so developpers do not have to worry about OSGI).
>
> We have encountered a JAR locking problem inside the XmlInputSource class,
> the problem comes from this instruction (WmlInputSource line 90) :
>
> mInputStream = mURL.openStream()
>
> When we do that with a URL which refers to a file inside a JAR file a
> JarURLConnection is used.
>
> JarURLConnection seems to have a bug because in the destroy method of
> XmlInputSource those instruction do not close the ZipFile associated to the
> JARUrlConnection.
>
> if (mInputStream != null)
> {
> mInputStream.close(); // DO NOT CLOSE THE ASSOCIATED ZipFile !!!
> }
>
>
> The bug has been reported in the SUN Bug Database: // see
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4386865
>
> This is problematic with OSGI because we can unload our Bundles (UIMA
> components in our case ;-) ) but never delete theme from the file system
> after...
>
> The solution to close the ZipFiles in XmlInputSource is to add the following
> instructions in the constructor and destroy method:
>
> private URLConnection urlConnection;
>
> public XMLInputSource(String aUrlOrFileName) throws IOException {
> //try as URL first, then as file name
> try {
> mURL = new URL(aUrlOrFileName);
> }
> catch (MalformedURLException e) {
> mURL = new File(aUrlOrFileName).toURL();
> }
>
> this.urlConnection = mURL.openConnection();
>
> mInputStream = mURL.openStream();
> }
>
>
> public void close()
> throws IOException
> {
> if (mInputStream != null)
> {
> mInputStream.close();
> }
>
> if((this.urlConnection != null) && (this.urlConnection instanceof
> JarURLConnection))
> {
> ((JarURLConnection)urlConnection).getJarFile().close();
> }
>
> mURL = null;
> }
>
> Is it possible to include those modifications in the next UIMA release ?
>
> Thanks,
>
> Baptiste Gaillard
>
>
>
>
>
> _
> Hotmail arrive sur votre téléphone ! Compatible Iphone, Windows Phone,
> Blackberry, …
> http://www.messengersurvotremobile.com/?d=Hotmail
Re: slight restructuring of SVN when we graduate
Does that mean we no longer have to copy sanbox projects to uimaj to build them? I would love that. --Thilo On 3/8/2010 19:37, Marshall Schor wrote: > When we graduate, I think it would be a good idea to slightly > restructure our SVN layout, moving the trunk/branches/tags designation > to one level higher for the uimaj, uima-as, and sandbox projects. > > That is, the new layout would look something like: > > .../uima/trunk > /uimaj (Java SDK) > /uima-as (add-on to above > /sandbox > /superPoms > /sharedBuildTools > /branches > /tags > > The branches and tags can have just parts of the trunk copied to them, > or they can have the whole trunk. The Apache Release plugin works with > this structure; for instance, if you want to release just > sandbox/projectXXX the release plugin would copy sandbox/projectXXX to > the tag, not the entire trunk. (I haven't tried this, but that's the > impression I get from reading.) > > The goal of this is to allow checking out the "trunk" to check out > everything, as well as allow checking out any specific sub-part(s) of > interest (e.g., one sandbox project), and have a consistent layout in > working store that matches the SVN. This will enable a more > straight-forward build process, and allow us to use more standard Maven > tooling. > > The sharedBuildTools would be tooling (such as DocBook tools) needed for > building, but not something that is part of normal distributions or > releases. (It *could* be released, as a separate component, if that was > desired). (It can also be included in the tag - to preserve a > particular version of the tooling used to build a release). > > Any opinions pro/con moving to this kind of layout, when we move out of > the incubator? > > -Marshall > > > > > > >
Re: How to mantain the UIMA nature when exporting an eclipse plugin
On 2/23/2010 17:02, Antonella Laterza wrote: > Hi everyone! > I've developed a plugin for the Jazz Rational Team Concert Eclipse Client > and I've included a UIMA aggregate analysis engine. To do this, I've set the > UIMA Nature to the project, I've installed the pear packages of the > components (WhitespaceTokenizer and DictionaryAnnotator) and then I've > created a class to access my new aggregate analysis engine. Now, I've a > problem. If I deploy the plugin as an Eclipse plugin, the internal structure > of the project changes and I lose the UIMA nature. So, I can't access the > xml dictionary file, necessary to the DictionaryAnnotator component. > How can I export my plugin, in order to mantain the UIMA nature of the > project? I don't think you can keep the UIMA nature, but all that may be required is that you add some directories to the classpath of your project. That includes at least the desc directory, where the descriptors live, and the directory where the dictionary lives. I didn't verify this, but I'm pretty sure that the dictionary annotator treats its dictionaries as UIMA resources, so adding them to the classpath should work. --Thilo > > Thanks in advance! > > Antonella > > P.S. I know that I can create a pear package to mantain the UIMA nature, > but I don't know how to integrate this package into the RTC Client. So I > need to find another solution! >
Re: [Discuss] graduation
+1, let's go! On 2/16/2010 15:05, Jukka Zitting wrote: > Hi, > > Let's push this forward... See below for a proposed board resolution > with Marshall as the chairman, with all the current committers (and me > as a former mentor) as PMC members, and with the scope I proposed in > response to Marshall's version. WDYT? > > BR, > > Jukka Zitting > > > X. Establish the Apache UIMA Project > >WHEREAS, the Board of Directors deems it to be in the best >interests of the Foundation and consistent with the >Foundation's purpose to establish a Project Management >Committee charged with the creation and maintenance of >open-source software related to the analysis of unstructured >data, guided by the UIMA Oasis Standard, for distribution at >no charge to the public. > >NOW, THEREFORE, BE IT RESOLVED, that a Project Management >Committee (PMC), to be known as the "Apache UIMA Project", >be and hereby is established pursuant to Bylaws of the >Foundation; and be it further > >RESOLVED, that the Apache UIMA Project be and hereby is >responsible for the creation and maintenance of software >related to the analysis of unstructured data, guided by >the UIMA Oasis Standard, and be it further > >RESOLVED, that the office of "Vice President, Apache UIMA" be >and hereby is created, the person holding such office to >serve at the direction of the Board of Directors as the chair >of the Apache UIMA Project, and to have primary responsibility >for management of the projects within the scope of >responsibility of the Apache UIMA Project; and be it further > >RESOLVED, that the persons listed immediately below be and >hereby are appointed to serve as the initial members of the >Apache UIMA Project: > > * Adam Lally > * Bhavani Iyer > * Burn Lewis > * Edward Epstein > * Jaroslaw Cwiklik > * Joern Kottmann > * Jukka Zitting > * Marshall Schor > * Michael Baessler > * Thilo Goetz > * Tommaso Teofili > * Tong Fin > >NOW, THEREFORE, BE IT FURTHER RESOLVED, that Marshall Schor >be appointed to the office of Vice President, Apache UIMA, to >serve in accordance with and subject to the direction of the >Board of Directors and the Bylaws of the Foundation until >death, resignation, retirement, removal or disqualification, >or until a successor is appointed; and be it further > >RESOLVED, that the initial Apache UIMA PMC be and hereby is >tasked with the creation of a set of bylaws intended to >encourage open development and increased participation in the >Apache UIMA Project; and be it further > >RESOLVED, that the Apache UIMA Project be and hereby >is tasked with the migration and rationalization of the Apache >Incubator UIMA podling; and be it further > >RESOLVED, that all responsibilities pertaining to the Apache >Incubator UIMA podling encumbered upon the Apache Incubator >Project are hereafter discharged.
Re: [PROPOSAL] AlchemyAPI Annotator
On 1/29/2010 10:12, Tommaso Teofili wrote: > Hi all, > we have 3 +1s and no 0s nor -1s. > Can we consider it passed and go on with importing the code? > Cheers, > Tommaso > Tommaso, how much code is it? If it's not a lot of code, and you wrote all of it yourself, you can just commit it. If it's a significant amount of code, we may need a code grant (it would be easier if we didn't). --Thilo
Re: OSGIing UIMA
On 1/28/2010 17:15, Jörn Kottmann wrote: > Marshall Schor wrote: >> I'm probably showing my ignorance here :-) but, leaving aside the >> question of making core uima support annotators as osgi bundles, can you >> say what the differences are between the uimaj-ep-runtime bundle we >> build for eclipse, having all the core UIMA capability, and your goal >> below of "making uimaj available as an OSGI bundle"? My understanding >> is that Eclipse plugins are osgi bundles, and we build these using the >> Felix maven plugin, which wraps the standard OSGI bundle making code. >> >> Thanks for the clarifications... >> >> > Isn't the only thing we are missing the support for > annotators in OSGi bundles ? Right now that can be > hacked by using the Eclipse-RegisterBuddy header, > which works for example with the spring OSGi server. > > Thilo, why do you think we cannot add OSGi annotator bundles > without breaking backward compatibility ? Good question. I should have written it down, I can't quite recall now what I was thinking of. One thing that might get interesting is JCas, and basically everything that does manual class loading. Maybe this can all be done in a backward compatible manner, though. Another thing that bears thinking about is our current OSGi/Eclipse bundles. They just export all packages that there are. If we change that and do not export packages that are really supposed to be implementation private, that would certainly break things. If we don't make that change, we loose at least some value of the OSGi-ification. --Thilo > > Beside that, it might be a bit more tricky for uima as because it > relies on ActiveMQ which did not work well with OSGi in my tests > with the uima as client and the spring OSGi server. > > Jörn
Re: OSGIing UIMA
On 1/28/2010 10:12, Tommaso Teofili wrote: > Hi all, > reading > http://cwiki.apache.org/UIMA/uima-osgi-enablement.html > I was wondering about how making uimaj available as an OSGI bundle. > I've seen the uimaj-as-osgi-runtime so I think I could make something > similar to it, and not using eclipse-plugin-supePom as parent, only for > uimaj-core, tools component-test, etc. (excluding AS stuff). > What do you think about it? > Since this is something I'm going to dig inside to integrate UIMA with > Clerezza do you have any suggestions/hints? > Cheers, > Tommaso > I've been thinking about this topic myself on and off for a while. I think it doesn't make much sense to create a UIMA core OSGi bundle without OSGi-enabling UIMA itself. If you go the OSGi route, you want your annotators to be bundles as well. So you need to add the ability to UIMA to load annotator OSGi bundles. I don't think that would be too hard to do, but I'm not sure it can be done in ways that are completely backward compatible. I would personally love to see OSGi bundles replace our pear format. Anyway, these are just my thoughts. If there is interest in really OSGiifying UIMA, that's something I'd be interested in contributing to. --Thilo
Re: http://incubator.apache.org/uima/downloads/sandbox/simple-server/simpleServerUserGuide.html
On 1/20/2010 23:02, Jim Condit wrote: > Hi UIMA Dev, > > > > Just wanted to let you know that the link to the REST server User Guide > seems to be broken: > > > > http://incubator.apache.org/uima/downloads/sandbox/simple-server/simpleServe > rUserGuide.html > > > > Thanks, > > > > Jim > > Thanks for pointing this out. Seems all the links to sandbox documentation went missing. For the simple server, the documentation is here: http://incubator.apache.org/uima/downloads/sandbox/simple-server/simpleServerUserGuide/simpleServerUserGuide.html --Thilo
Re: January board report
On 1/13/2010 10:01, Tommaso Teofili wrote: > Hi, > fot the January 2010 report (today is the deadline) I collected the > following items: > * 2.3.0-RC9 is out for testing and being voted as 2.3.0-incubating * UIMA > and Semantic Search presentation at IKS 2nd workshop (see [[ > http://incubator.apache.org/uima/iks09.html|here]]) * new incubating project > Clerezza planning to integrate with UIMA * New committer voted in (Bhavani > Iyer) * Fixed switching between ResourceManagers loaded with different class > loaders * Fixed script classpaths * Fixed UIMA-AS broker connection issues > > I got the last three items from our Jira sorting issues by priority. > Any other suggestion is welcome :) > Cheers. > Tommaso > Hi Tommaso, it's a good thought, but I don't think the board is interested in our progress at that level of detail. I would leave out mentioning specific issues we fixed. My opinion, anyway. --Thilo
Re: [VOTE] Release UIMA 2.3.0 RC9 as UIMA 2.3.0 incubating
On 1/11/2010 17:18, Marshall Schor wrote: > [ ] +1 Release RC9, it's ready > [ ] -1 Don't release yet because of these issues which need to be > addressed first: ... +1 --Thilo > > --Marshall >
Re: Incubator PMC/Board report for January 2010 ("UIMA Developers" )
Would it be appropriate to say something like "getting ready for a graduation vote very soon" so the Board knows we're getting there and doesn't worry about us too much? --Thilo On 1/11/2010 10:52, Tommaso Teofili wrote: > Hi, > I'm going to add > >- 2.3.0-RC9 is out for testing >- > >UIMA and Semantic Search presentation at IKS 2nd workshop (see >http://wiki.iks-project.eu/index.php/2nd_Workshop) >- > >new incubating project Clerezza planning to integrate with UIMA > > Tommaso > > > 2010/1/11 Tommaso Teofili > >> Hi guys, >> we have to report by Wednesday, I can take care of it. >> We can share in this thread all the stuff we want to report. >> >> Cheers. >> Tommaso >> >> >> >> >> 2010/1/1 Marvin >> >> Dear UIMA Developers, >>> >>> This email was sent by an automated system on behalf of the Apache >>> Incubator PMC. >>> It is an initial reminder to give you plenty of time to prepare your >>> quarterly >>> board report. >>> >>> The board meeting is scheduled for Wed, 20 January 2010, 2 pm Pacific. >>> The report >>> for your podling will form a part of the Incubator PMC report. The >>> Incubator PMC >>> requires your report to be submitted one week before the board meeting, to >>> allow >>> sufficient time for review. >>> >>> Please submit your report with sufficient time to allow the incubator PMC, >>> and >>> subsequently board members to review and digest. Again, the very latest >>> you >>> should submit your report is one week prior to the board meeting. >>> >>> Thanks, >>> >>> The Apache Incubator PMC >>> >>> Submitting your Report >>> -- >>> >>> Your report should contain the following: >>> >>> * Your project name >>> * A brief description of your project, which assumes no knowledge of the >>> project >>> or necessarily of its field >>> * A list of the three most important issues to address in the move >>> towards >>> graduation. >>> * Any issues that the Incubator PMC or ASF Board might wish/need to be >>> aware of >>> * How has the community developed since the last report >>> * How has the project developed since the last report. >>> >>> This should be appended to the Incubator Wiki page at: >>> >>> http://wiki.apache.org/incubator/January2010 >>> >>> Note: This manually populated. You may need to wait a little before this >>> page is >>> created from a template. >>> >>> Mentors >>> --- >>> Mentors should review reports for their project(s) and sign them off on >>> the >>> Incubator wiki page. Signing off reports shows that you are following the >>> project - projects that are not signed may raise alarms for the Incubator >>> PMC. >>> >>> Incubator PMC >>> >>> >> >
Re: [VOTE] Release UIMA 2.3.0 release candidate 7 as UIMA 2.3.0 incubating
On 12/10/2009 13:49, Marshall Schor wrote: > [X] +1 Release RC7, it's ready > [ ] -1 Don't release yet because of these issues which need to be > addressed first: ... > > --Marshall +1 --Thilo
[jira] Closed: (UIMA-1693) Pear installer: logger config not found when running pear installer
[ https://issues.apache.org/jira/browse/UIMA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thilo Goetz closed UIMA-1693. - Resolution: Not A Problem Ok, user error. Sorry for the noise. I don't usually set UIMA_HOME, and most things work without it. I guess I shouldn't test stuff that I never use in real life ;-) > Pear installer: logger config not found when running pear installer > --- > > Key: UIMA-1693 > URL: https://issues.apache.org/jira/browse/UIMA-1693 > Project: UIMA > Issue Type: Bug > Components: Tools >Affects Versions: 2.3 >Reporter: Thilo Goetz >Priority: Minor > > I installed the 2.3-RC5 Eclipse tooling, imported the examples projects and > tried to run the pear installer via the preconfigured pear installer launch > configuration. This results in the exception below. The same does not > happen when the pear installer is started via the .bat file. Pear > installation works regardless, so this is minor and should not hold up 2.3. > java.io.FileNotFoundException: \config\Logger.properties (The system cannot > find the path specified.) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.(FileInputStream.java:112) > at java.io.FileInputStream.(FileInputStream.java:72) > at java.util.logging.LogManager.readConfiguration(LogManager.java:459) > at java.util.logging.LogManager$3.run(LogManager.java:221) > at > java.security.AccessController.doPrivileged(AccessController.java:202) > at java.util.logging.LogManager.(LogManager.java:207) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1695) Eclipse tooling: CDE fully instantiates components of aggregates, resulting in OutOfMemory issues
Eclipse tooling: CDE fully instantiates components of aggregates, resulting in OutOfMemory issues - Key: UIMA-1695 URL: https://issues.apache.org/jira/browse/UIMA-1695 Project: UIMA Issue Type: Improvement Components: Eclipse plugins Affects Versions: 2.3 Reporter: Thilo Goetz Priority: Minor When I create an aggregate descriptor from several installed pears (e.g., WS tokenizer, tagger & regex), the CDE creates an OOM situation on Eclipse 3.5 and Sun Java 6 on windows. This seems to be due to the fact that the CDE fully instantiates delegate components to get at their metadata. Is this really necessary? We keep all our metadata in xml specifically so we don't have to do this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Testing of Eclipse tooling
I tested the Eclipse tooling with Eclipse 3.4.2 and 3.5.1. I have some vague memory that we decided to drop Eclipse 3.3 support for this release, is that correct? --Thilo
[jira] Commented: (UIMA-1693) Pear installer: logger config not found when running pear installer
[ https://issues.apache.org/jira/browse/UIMA-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785841#action_12785841 ] Thilo Goetz commented on UIMA-1693: --- This also happens when you start CVD from Eclipse. Logging and "view log" in CVD work regardless, so this is still minor imho. > Pear installer: logger config not found when running pear installer > --- > > Key: UIMA-1693 > URL: https://issues.apache.org/jira/browse/UIMA-1693 > Project: UIMA > Issue Type: Bug > Components: Tools >Affects Versions: 2.3 >Reporter: Thilo Goetz >Priority: Minor > > I installed the 2.3-RC5 Eclipse tooling, imported the examples projects and > tried to run the pear installer via the preconfigured pear installer launch > configuration. This results in the exception below. The same does not > happen when the pear installer is started via the .bat file. Pear > installation works regardless, so this is minor and should not hold up 2.3. > java.io.FileNotFoundException: \config\Logger.properties (The system cannot > find the path specified.) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.(FileInputStream.java:112) > at java.io.FileInputStream.(FileInputStream.java:72) > at java.util.logging.LogManager.readConfiguration(LogManager.java:459) > at java.util.logging.LogManager$3.run(LogManager.java:221) > at > java.security.AccessController.doPrivileged(AccessController.java:202) > at java.util.logging.LogManager.(LogManager.java:207) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: release candidate 05 is now posted at the usual place
Tommaso Teofili wrote: > Hi Thilo, > I tried what you did and got the same problem. > The tag inside is missing, once that is fixed, I > got everything to work. Ok, that's great! > I can commit the patch if you think it's alright. Yes, please do. I'm sure Marshall will be happy when he wakes up and sees this problem has already been fixed :-) --Thilo > Cheers. > Tommaso > > 2009/12/4 Thilo Goetz > >> Marshall Schor wrote: >>> Find it at >>> http://people.apache.org/~schor/uima-release-candidates/2.3.0-RC5/<http://people.apache.org/%7Eschor/uima-release-candidates/2.3.0-RC5/> >>> >>> except for the uima-cpp release, which remains under rc1 (it hasn't >>> changed). >>> >>> (Release candidate 4 had RAT issues). >>> >>> The compare of the source export out of svn with our source distribution >>> should be closer - but some differences remain, including treatment of >>> empty directories ( present in SVN, but not in the source assembly). >>> >>> -Marshall >> I can't build the release candidate with a clean mvn repo. Here's >> what I did. Downloaded UIMA core sources, unpacked, cd to uimaj. >> Move local maven repo for really clean build. I do this with every >> release candidate, it worked with RC3. Call mvn install. I get >> the usual helpful error message below. I'm using the latest stable >> maven release, 2.2.1. >> >> Now when I use my previous local maven cache, everything works. Can >> anybody reproduce this behavior? >> >> --Thilo >> >> [ERROR] FATAL ERROR >> [INFO] >> >> [INFO] The scm url cannot be null. >> [INFO] >> >> [INFO] Trace >> java.lang.NullPointerException: The scm url cannot be null. >>at >> org.apache.maven.scm.manager.AbstractScmManager.makeScmRepository(Abs >> tractScmManager.java:181) >>at >> org.codehaus.mojo.build.CreateMojo.getScmRepository(CreateMojo.java:7 >> 22) >>at >> org.codehaus.mojo.build.CreateMojo.getScmBranch(CreateMojo.java:593) >>at org.codehaus.mojo.build.CreateMojo.execute(CreateMojo.java:452) >>at >> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi >> nManager.java:490) >>at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa >> ultLifecycleExecutor.java:694) >>at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi >> fecycle(DefaultLifecycleExecutor.java:556) >>at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau >> ltLifecycleExecutor.java:535) >>at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan >> dleFailures(DefaultLifecycleExecutor.java:387) >>at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen >> ts(DefaultLifecycleExecutor.java:348) >>at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi >> fecycleExecutor.java:180) >>at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) >>at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) >>at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) >>at >> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:6 >> 0) >>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. >> java:45) >>at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces >> sorImpl.java:37) >>at java.lang.reflect.Method.invoke(Method.java:599) >>at >> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) >>at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) >>at >> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) >> >>at org.codehaus.classworlds.Launcher.main(Launcher.java:375) >> [INFO] >> >> [INFO] Total time: 34 seconds >> [INFO] Finished at: Fri Dec 04 09:34:49 CET 2009 >> [INFO] Final Memory: 19M/73M >> [INFO] >> >> D:\installers\uima\2.3-rc5\build\uimaj-2.3.0-incubating\uimaj> >> >
[jira] Created: (UIMA-1693) Pear installer: logger config not found when running pear installer
Pear installer: logger config not found when running pear installer --- Key: UIMA-1693 URL: https://issues.apache.org/jira/browse/UIMA-1693 Project: UIMA Issue Type: Bug Components: Tools Affects Versions: 2.3 Reporter: Thilo Goetz Priority: Minor I installed the 2.3-RC5 Eclipse tooling, imported the examples projects and tried to run the pear installer via the preconfigured pear installer launch configuration. This results in the exception below. The same does not happen when the pear installer is started via the .bat file. Pear installation works regardless, so this is minor and should not hold up 2.3. java.io.FileNotFoundException: \config\Logger.properties (The system cannot find the path specified.) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:112) at java.io.FileInputStream.(FileInputStream.java:72) at java.util.logging.LogManager.readConfiguration(LogManager.java:459) at java.util.logging.LogManager$3.run(LogManager.java:221) at java.security.AccessController.doPrivileged(AccessController.java:202) at java.util.logging.LogManager.(LogManager.java:207) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: release candidate 05 is now posted at the usual place
Marshall Schor wrote: > Find it at > http://people.apache.org/~schor/uima-release-candidates/2.3.0-RC5/ > > except for the uima-cpp release, which remains under rc1 (it hasn't > changed). > > (Release candidate 4 had RAT issues). > > The compare of the source export out of svn with our source distribution > should be closer - but some differences remain, including treatment of > empty directories ( present in SVN, but not in the source assembly). > > -Marshall I can't build the release candidate with a clean mvn repo. Here's what I did. Downloaded UIMA core sources, unpacked, cd to uimaj. Move local maven repo for really clean build. I do this with every release candidate, it worked with RC3. Call mvn install. I get the usual helpful error message below. I'm using the latest stable maven release, 2.2.1. Now when I use my previous local maven cache, everything works. Can anybody reproduce this behavior? --Thilo [ERROR] FATAL ERROR [INFO] [INFO] The scm url cannot be null. [INFO] [INFO] Trace java.lang.NullPointerException: The scm url cannot be null. at org.apache.maven.scm.manager.AbstractScmManager.makeScmRepository(Abs tractScmManager.java:181) at org.codehaus.mojo.build.CreateMojo.getScmRepository(CreateMojo.java:7 22) at org.codehaus.mojo.build.CreateMojo.getScmBranch(CreateMojo.java:593) at org.codehaus.mojo.build.CreateMojo.execute(CreateMojo.java:452) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:6 0) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:45) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:599) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 34 seconds [INFO] Finished at: Fri Dec 04 09:34:49 CET 2009 [INFO] Final Memory: 19M/73M [INFO] D:\installers\uima\2.3-rc5\build\uimaj-2.3.0-incubating\uimaj>
Re: Need help with DictionaryAnnotator
On 12/3/2009 12:24, Antonella Laterza wrote: I'm using the deafult dictionary file, so it is in the default directory (/DictionaryAnnotator/resources) and I set the datapath with the absolute path of the file (/DictionaryAnnotator/resources/dictionary.xml), as described in the UIMA CDE Property Page. I guess the datapath should point to the directory that contains the dictionary file, not the file itself. 2009/12/3 Thilo Goetz Hi Antonella, please tell us where you put the dictionary and what you set the datapath to. --Thilo On 12/3/2009 10:42, Antonella Laterza wrote: Hi everyone, I'm really new to UIMA and I need some help with the DictionaryAnnotator component. When I try to execute the DictionaryAnnotator with the CAS Visual Debugger or the Document Analyzer, I always get this error message: org.apache.uima.tools.cvd.MainFrame.handleException(575): GRAVE: Initialization of annotator class "org.apache.uima.annotator.dict_annot.impl.DictionaryAnnotator" failed. org.apache.uima.resource.ResourceInitializationException: Initialization of annotator class "org.apache.uima.annotator.dict_annot.impl.DictionaryAnnotator" failed. [...] Caused by: org.apache.uima.annotator.dict_annot.impl.DictionaryAnnotatorConfigException: "The resource file dictionary.xml could not be found." I've read the DictionaryAnnotator User Guide (Chapter 3 - "Annotator Configuration") and I've set the UIMA data path in order to include the dictionary file...but it still doesn't work! Any suggestion? Thanks in advance! Antonella P.S. I'm working with eclipse (with the Jazz Rational Team Concert Eclipse client, because I'm developing a Jazz plugin) and I've followed all the steps to set up the Eclipse IDE to work correctly with UIMA. First I tried to use the annotator included in the downloadable package, but it didn't work. So I followed the steps described in the "Apache UIMA - Source Code" page to check out the code from the repository and build it with maven and now I've all java projects for the UIMA base and Sandbox in my eclipse workspace.
Re: Need help with DictionaryAnnotator
Hi Antonella, please tell us where you put the dictionary and what you set the datapath to. --Thilo On 12/3/2009 10:42, Antonella Laterza wrote: Hi everyone, I'm really new to UIMA and I need some help with the DictionaryAnnotator component. When I try to execute the DictionaryAnnotator with the CAS Visual Debugger or the Document Analyzer, I always get this error message: org.apache.uima.tools.cvd.MainFrame.handleException(575): GRAVE: Initialization of annotator class "org.apache.uima.annotator.dict_annot.impl.DictionaryAnnotator" failed. org.apache.uima.resource.ResourceInitializationException: Initialization of annotator class "org.apache.uima.annotator.dict_annot.impl.DictionaryAnnotator" failed. [...] Caused by: org.apache.uima.annotator.dict_annot.impl.DictionaryAnnotatorConfigException: "The resource file dictionary.xml could not be found." I've read the DictionaryAnnotator User Guide (Chapter 3 - "Annotator Configuration") and I've set the UIMA data path in order to include the dictionary file...but it still doesn't work! Any suggestion? Thanks in advance! Antonella P.S. I'm working with eclipse (with the Jazz Rational Team Concert Eclipse client, because I'm developing a Jazz plugin) and I've followed all the steps to set up the Eclipse IDE to work correctly with UIMA. First I tried to use the annotator included in the downloadable package, but it didn't work. So I followed the steps described in the "Apache UIMA - Source Code" page to check out the code from the repository and build it with maven and now I've all java projects for the UIMA base and Sandbox in my eclipse workspace.
[jira] Updated: (UIMA-1682) Notify the user if the language in the CAS is set to "x" and the SnowballAnnotator won't work properly.
[ https://issues.apache.org/jira/browse/UIMA-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thilo Goetz updated UIMA-1682: -- Assignee: Thilo Goetz Defer post 2.3. > Notify the user if the language in the CAS is set to "x" and the > SnowballAnnotator won't work properly. > --- > > Key: UIMA-1682 > URL: https://issues.apache.org/jira/browse/UIMA-1682 > Project: UIMA > Issue Type: Improvement > Components: Sandbox-SnowballAnnotator >Affects Versions: 2.2.2 >Reporter: Marc Hofer >Assignee: Thilo Goetz >Priority: Trivial > Attachments: SnowballAnnotator.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > If you don't use debugging tools such as the CVD, the language of the CAS is > per default set to "x". In this case the SnowballAnnotator won't work. It > would be nice to notify the user, that the language isn't set properly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1682) Notify the user if the language in the CAS is set to "x" and the SnowballAnnotator won't work properly.
[ https://issues.apache.org/jira/browse/UIMA-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783647#action_12783647 ] Thilo Goetz commented on UIMA-1682: --- Another issue seems to me that the descriptor specifies x-unspecified as supported language. That doesn't seem right to me, as it really only supports a finite set of languages. > Notify the user if the language in the CAS is set to "x" and the > SnowballAnnotator won't work properly. > --- > > Key: UIMA-1682 > URL: https://issues.apache.org/jira/browse/UIMA-1682 > Project: UIMA > Issue Type: Improvement > Components: Sandbox-SnowballAnnotator >Affects Versions: 2.2.2 >Reporter: Marc Hofer >Priority: Trivial > Attachments: SnowballAnnotator.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > If you don't use debugging tools such as the CVD, the language of the CAS is > per default set to "x". In this case the SnowballAnnotator won't work. It > would be nice to notify the user, that the language isn't set properly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (UIMA-1676) Regex: pear install.xml is missing 2 of the 3 jar files
Marshall Schor wrote: > Looking at a previous thread: > http://markmail.org/thread/xrv7qormkenc4hxd I now remember we have made > a change in the behavior to require explicitly listing all the jars in > the install.xml file. We thought that was OK because the Eclipse > tooling for building pears did this. > > I'm wondering if the right fix for this is to change the maven pear > plugin to operate like the eclipse pear builder plugin, and have it add > the lib jars to the install.xml? That would fix the issue here, and > likely reduce "breakage" if people rebuild their pears after this release. > > If we did this, I would change the documentation to say ... there is no > need to specify Class Path entries for Jars in the lib directory, when > using the Eclipse plugin pear packager or the Maven Pear Packager. > > Opinions? You can guess what my opinion about this is from previous conversations. It leads to the kind of workarounds you have to do we discussed on the users list a week or so ago. When I build a pear with an ant script, I copy the files I want packaged to a temp dir and the package the pear there, to make sure the [expletive deleted] pear packager really only packages what I want it to, not all my eclipse dot files and whatnot. But that's just my opinion. --Thilo > > -Marshall > > Marshall Schor wrote: >> Thilo Goetz wrote: >> >>> On 11/23/2009 15:47, Marshall Schor wrote: >>> >>>> A little more investigation: I think what is supposed to happen is that >>>> the "install" process for the pear ends up calling >>>> buildComponentClassPath in the InstallationController, which should be >>>> adding all the jars in the lib/ to the classpath. >>>> >>> No, the jars should be added to the classpath in the install.xml >>> file when the pear is built. This is not happening I guess. >>> >> Right. This can be added to the build. >> >>> uima-an-regex.jar *is* added to the classpath, the other two are >>> not. So afaics, this has nothing to do with the changes to >>> buildComponentClassPath. For example, when you create an eclipse >>> project with the regex annotator in it, complete with all 3 jar >>> files in the lib dir, the pear packaging tool automatically >>> generates the correct classpath. >>> >> I tried "installing" the pear, and found that the >> buildComponentClassPath did create a correct classpath, but wrote it out >> in the installation's metadata/ directory as the file "setenv.txt". >> This file has a comment at the top which says: >> ### Add the following environment variables >> ### to appropriate existing environment variables >> ### to run the RegularExpressionAnnotator component >> >> Does anyone know how this setenv.txt file is supposed to be used, >> somehow, when the pear is run? Is there any code which picks it up and >> applies it automatically, or is this just supposed to be a manual operation? >> >> -Marshall >> >>> --Thilo >>> >>> >>>> Can you say how you are running the pear in a manner where this is not >>>> happening? >>>> >>>> -Marshall >>>> >>>> Marshall Schor wrote: >>>> >>>>> Well, this may be due to a misunderstanding on my part. The issue is >>>>> around what files get added *automatically* to the class path in >>>>> various >>>>> situations. >>>>> >>>>> I know we made a change to remove automatic adding of the files in the >>>>> lib/ when "running" a pear, but I had understood that the pear >>>>> packaging >>>>> was still going to add those files to the generated classpath, when >>>>> creating the pear. That is what is *not* happening. >>>>> >>>>> Thilo - is that your understanding of what should be happening? If >>>>> not, >>>>> what do you think should be happening with regard to this? I remember >>>>> some discussion around not breaking older pear files with our >>>>> changes... >>>>> >>>>> -Marshall >>>>> >>>>> Marshall Schor wrote: >>>>> >>>>> >>>>>> Thilo Goetz wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Er, I see that this is now all maven based. I have >>>>
Re: [jira] Created: (UIMA-1676) Regex: pear install.xml is missing 2 of the 3 jar files
On 11/23/2009 18:12, Marshall Schor wrote: Thilo Goetz wrote: On 11/23/2009 15:47, Marshall Schor wrote: A little more investigation: I think what is supposed to happen is that the "install" process for the pear ends up calling buildComponentClassPath in the InstallationController, which should be adding all the jars in the lib/ to the classpath. No, the jars should be added to the classpath in the install.xml file when the pear is built. This is not happening I guess. Right. This can be added to the build. Ok, that's good. uima-an-regex.jar *is* added to the classpath, the other two are not. So afaics, this has nothing to do with the changes to buildComponentClassPath. For example, when you create an eclipse project with the regex annotator in it, complete with all 3 jar files in the lib dir, the pear packaging tool automatically generates the correct classpath. I tried "installing" the pear, and found that the buildComponentClassPath did create a correct classpath, but wrote it out in the installation's metadata/ directory as the file "setenv.txt". This file has a comment at the top which says: ### Add the following environment variables ### to appropriate existing environment variables ### to run the RegularExpressionAnnotator component Does anyone know how this setenv.txt file is supposed to be used, somehow, when the pear is run? Is there any code which picks it up and applies it automatically, or is this just supposed to be a manual operation? There are two files, setenv.txt and install.xml. They should have the same content. The install.xml is the one that's being used by the pear runtime. The setenv.txt is there only as a convenience in case somebody wants to actually set the relevant vars in a shell. I've never heard of anybody using it. The fact that the classpath in setenv.txt is correct is due to the usual buildComponentClassPath magic, adding whatever is in the lib dir. You'll note that the uima-an-regex.jar is in there twice, once because it's in install.xml, and once because it lives in the lib dir. Not nice, but as I said, I don't think anybody cares about it anyway. With the changes to buildComponentClassPath, setenv.txt should really only contain whatever install.xml contains. buildComponentClassPath can be run in two modes, online and offline. Offline is for packaging (collecting everything in the lib dir), online is for runtime. The generation for setenv.txt must be calling buildComponentClassPath in offline mode, but it should be online. I suppose we can fix that, but we might just as well leave it alone for now. --Thilo -Marshall --Thilo Can you say how you are running the pear in a manner where this is not happening? -Marshall Marshall Schor wrote: Well, this may be due to a misunderstanding on my part. The issue is around what files get added *automatically* to the class path in various situations. I know we made a change to remove automatic adding of the files in the lib/ when "running" a pear, but I had understood that the pear packaging was still going to add those files to the generated classpath, when creating the pear. That is what is *not* happening. Thilo - is that your understanding of what should be happening? If not, what do you think should be happening with regard to this? I remember some discussion around not breaking older pear files with our changes... -Marshall Marshall Schor wrote: Thilo Goetz wrote: Er, I see that this is now all maven based. I have no idea how to add the missing jars. Over to you, Marshall. OK - will do... -Marshall --Thilo On 11/23/2009 14:45, Thilo Goetz wrote: This is probably a regression from https://issues.apache.org/jira/browse/UIMA-1595 I should be able to investigate later today, but if anybody else wants a go, feel free. --Thilo On 11/23/2009 14:34, Thilo Goetz (JIRA) wrote: Regex: pear install.xml is missing 2 of the 3 jar files --- Key: UIMA-1676 URL: https://issues.apache.org/jira/browse/UIMA-1676 Project: UIMA Issue Type: Bug Components: Sandbox-RegexAnnotator Affects Versions: 2.3S Reporter: Thilo Goetz Fix For: 2.3S The regex pear file is not packaged correctly. 2 out of 3 jar files are missing from the install.xml file, resulting in ClassNotFoundExceptions when you're trying to run the installed pear.
Re: [jira] Created: (UIMA-1676) Regex: pear install.xml is missing 2 of the 3 jar files
On 11/23/2009 15:47, Marshall Schor wrote: A little more investigation: I think what is supposed to happen is that the "install" process for the pear ends up calling buildComponentClassPath in the InstallationController, which should be adding all the jars in the lib/ to the classpath. No, the jars should be added to the classpath in the install.xml file when the pear is built. This is not happening I guess. uima-an-regex.jar *is* added to the classpath, the other two are not. So afaics, this has nothing to do with the changes to buildComponentClassPath. For example, when you create an eclipse project with the regex annotator in it, complete with all 3 jar files in the lib dir, the pear packaging tool automatically generates the correct classpath. --Thilo Can you say how you are running the pear in a manner where this is not happening? -Marshall Marshall Schor wrote: Well, this may be due to a misunderstanding on my part. The issue is around what files get added *automatically* to the class path in various situations. I know we made a change to remove automatic adding of the files in the lib/ when "running" a pear, but I had understood that the pear packaging was still going to add those files to the generated classpath, when creating the pear. That is what is *not* happening. Thilo - is that your understanding of what should be happening? If not, what do you think should be happening with regard to this? I remember some discussion around not breaking older pear files with our changes... -Marshall Marshall Schor wrote: Thilo Goetz wrote: Er, I see that this is now all maven based. I have no idea how to add the missing jars. Over to you, Marshall. OK - will do... -Marshall --Thilo On 11/23/2009 14:45, Thilo Goetz wrote: This is probably a regression from https://issues.apache.org/jira/browse/UIMA-1595 I should be able to investigate later today, but if anybody else wants a go, feel free. --Thilo On 11/23/2009 14:34, Thilo Goetz (JIRA) wrote: Regex: pear install.xml is missing 2 of the 3 jar files --- Key: UIMA-1676 URL: https://issues.apache.org/jira/browse/UIMA-1676 Project: UIMA Issue Type: Bug Components: Sandbox-RegexAnnotator Affects Versions: 2.3S Reporter: Thilo Goetz Fix For: 2.3S The regex pear file is not packaged correctly. 2 out of 3 jar files are missing from the install.xml file, resulting in ClassNotFoundExceptions when you're trying to run the installed pear.
Re: [jira] Created: (UIMA-1676) Regex: pear install.xml is missing 2 of the 3 jar files
Er, I see that this is now all maven based. I have no idea how to add the missing jars. Over to you, Marshall. --Thilo On 11/23/2009 14:45, Thilo Goetz wrote: This is probably a regression from https://issues.apache.org/jira/browse/UIMA-1595 I should be able to investigate later today, but if anybody else wants a go, feel free. --Thilo On 11/23/2009 14:34, Thilo Goetz (JIRA) wrote: Regex: pear install.xml is missing 2 of the 3 jar files --- Key: UIMA-1676 URL: https://issues.apache.org/jira/browse/UIMA-1676 Project: UIMA Issue Type: Bug Components: Sandbox-RegexAnnotator Affects Versions: 2.3S Reporter: Thilo Goetz Fix For: 2.3S The regex pear file is not packaged correctly. 2 out of 3 jar files are missing from the install.xml file, resulting in ClassNotFoundExceptions when you're trying to run the installed pear.
Re: [jira] Created: (UIMA-1676) Regex: pear install.xml is missing 2 of the 3 jar files
This is probably a regression from https://issues.apache.org/jira/browse/UIMA-1595 I should be able to investigate later today, but if anybody else wants a go, feel free. --Thilo On 11/23/2009 14:34, Thilo Goetz (JIRA) wrote: Regex: pear install.xml is missing 2 of the 3 jar files --- Key: UIMA-1676 URL: https://issues.apache.org/jira/browse/UIMA-1676 Project: UIMA Issue Type: Bug Components: Sandbox-RegexAnnotator Affects Versions: 2.3S Reporter: Thilo Goetz Fix For: 2.3S The regex pear file is not packaged correctly. 2 out of 3 jar files are missing from the install.xml file, resulting in ClassNotFoundExceptions when you're trying to run the installed pear.
[jira] Created: (UIMA-1676) Regex: pear install.xml is missing 2 of the 3 jar files
Regex: pear install.xml is missing 2 of the 3 jar files --- Key: UIMA-1676 URL: https://issues.apache.org/jira/browse/UIMA-1676 Project: UIMA Issue Type: Bug Components: Sandbox-RegexAnnotator Affects Versions: 2.3S Reporter: Thilo Goetz Fix For: 2.3S The regex pear file is not packaged correctly. 2 out of 3 jar files are missing from the install.xml file, resulting in ClassNotFoundExceptions when you're trying to run the installed pear. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Apache Uima 2.3.0-incubating release candidate 01
On 11/13/2009 16:32, Marshall Schor wrote: Thilo Goetz wrote: On 11/13/2009 04:53, Marshall Schor wrote: The release candidate 01 for 2.3.0-incubating is on http://people.apache.org/~schor/uima-release-candidates/2.3.0-RC1/ It has 4 parts: uimaj - the main uima release uima-as - the uima-as add on uima-sandbox - the sandbox components being released uima-cpp - the C++ release, including several binary builds. The Release Audit Reports (RAT) are included. I'll work on posting a test plan to our wiki, probably tomorrow; meanwhile, please try it out. -Marshall Marshall, the key you used to sign the release is unsigned. I thought there was a way to carry over the old signatures? Or can you maybe sign your new key with the old one? I haven't done this myself yet. hmmm. I had signed the new key with the old one. I just now checked this using gpg --list-sigs for my key, and it shows (for me) that it is signed with my old key. The new key is titled Marshall I Schor (Code Signing Key 2) -- note the "2", and the old key is the same name without the "2". How did you determine that my signing key was "unsigned"? -Marshall --Thilo Sorry, my mistake. I had neither imported nor trusted your old key, so the new one appeared non-trusted. "Unsigned" was wrong terminology on my part. Everything looks fine now. --Thilo
Re: Apache Uima 2.3.0-incubating release candidate 01
On 11/13/2009 04:53, Marshall Schor wrote: The release candidate 01 for 2.3.0-incubating is on http://people.apache.org/~schor/uima-release-candidates/2.3.0-RC1/ It has 4 parts: uimaj - the main uima release uima-as - the uima-as add on uima-sandbox - the sandbox components being released uima-cpp - the C++ release, including several binary builds. The Release Audit Reports (RAT) are included. I'll work on posting a test plan to our wiki, probably tomorrow; meanwhile, please try it out. -Marshall The CVD batch file is not working for me: c:\installers\uima\uima-2.3.0\apache-uima\bin>set UIMA_HOME=c:\installers\uima\uima-2.3.0\apache-uima c:\installers\uima\uima-2.3.0\apache-uima\bin>.\cvd.bat =c:\installers\uima\uima-2.3.0\apache-uima/docs/html""=="" was unexpected at this time. The same happens with all other batch files I tried. Am I missing anything obvious? Do I need to do more than set the UIMA_HOME variable? --Thilo
Re: Apache Uima 2.3.0-incubating release candidate 01
On 11/13/2009 04:53, Marshall Schor wrote: The release candidate 01 for 2.3.0-incubating is on http://people.apache.org/~schor/uima-release-candidates/2.3.0-RC1/ It has 4 parts: uimaj - the main uima release uima-as - the uima-as add on uima-sandbox - the sandbox components being released uima-cpp - the C++ release, including several binary builds. The Release Audit Reports (RAT) are included. I'll work on posting a test plan to our wiki, probably tomorrow; meanwhile, please try it out. -Marshall Marshall, the key you used to sign the release is unsigned. I thought there was a way to carry over the old signatures? Or can you maybe sign your new key with the old one? I haven't done this myself yet. --Thilo
[jira] Closed: (UIMA-1642) Regex rule file parameter should allow wildcard expressions when using the datapath to locate rule files
[ https://issues.apache.org/jira/browse/UIMA-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thilo Goetz closed UIMA-1642. - Resolution: Fixed Done. Also added test cases and updated documentation. > Regex rule file parameter should allow wildcard expressions when using the > datapath to locate rule files > > > Key: UIMA-1642 > URL: https://issues.apache.org/jira/browse/UIMA-1642 > Project: UIMA > Issue Type: Improvement > Components: Sandbox-RegexAnnotator >Affects Versions: 2.2.2 >Reporter: Thilo Goetz >Assignee: Thilo Goetz >Priority: Minor > Fix For: 2.3S > > > Improve the regex annotator so it can load rule files with wildcard > expressions such as ruledir/*.rule -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1642) Regex rule file parameter should allow wildcard expressions when using the datapath to locate rule files
Regex rule file parameter should allow wildcard expressions when using the datapath to locate rule files Key: UIMA-1642 URL: https://issues.apache.org/jira/browse/UIMA-1642 Project: UIMA Issue Type: Improvement Components: Sandbox-RegexAnnotator Affects Versions: 2.2.2 Reporter: Thilo Goetz Assignee: Thilo Goetz Priority: Minor Fix For: 2.3S Improve the regex annotator so it can load rule files with wildcard expressions such as ruledir/*.rule -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Issues not closed for 2.3.0 release
Marshall Schor wrote: [...] > Both of these approaches put uimaj-core classes at the "root" level of > the application (i.e., "System") class-loader chain. I can't think of > any cases where that would not be OK; can anyone else? I think that may not work because the UIMA framework classes need to access the annotator classes. If the core is loaded by the system classloader, it will not have access to classes loaded by the bs loader. --Thilo
Re: Issues not closed for 2.3.0 release
Jaroslaw Cwiklik wrote:
> Marshall, I cant close https://issues.apache.org/jira/browse/UIMA-1531 yet.
> Over the weekend I've discovered why the Logger ignores uima
> formatter defined in Logger.properties and logs entries using the default
> formatter (xml). It turns out that the java LogManager uses system
> classloader to load the formatter class. Here is the method where this magic
> occurs:
> Formatter getFormatterProperty(String name, Formatter defaultValue) {
> String val = getProperty(name);
> try {
> if (val != null) {
> Class clz = ClassLoader.getSystemClassLoader().loadClass(val);
> return (Formatter) clz.newInstance();
> }
> } catch (Exception ex) {
> // We got one of a variety of exceptions in creating the
> // class or creating an instance.
> // Drop through.
> }
> // We got an exception. Return the defaultValue.
> return defaultValue;
> }
>
> It surprising that that this java component silently ignores errors. Since
> the uima formatter class is not loaded into the system classloader by the
> UimaBootstrap, the LogManager returns a default formatter from the method
> above.
>
> I dont know how to fix this problem yet. One possibility is to change
> UimaBootstrap to load jars/classes into the system classloader. Another
> possibility is to load this one class into the system classloader although
> I've failed trying to do this. I attempted to augment
> the system classloader using reflection to inject a new URL like so:
>
> URL url = new
> URL("jar:file:/C:/uima/releases/2.3.3-04/apache-uima/lib/uima-core.jar!/java/util/logging/XMLFormatter.class");
>
> Class[] parameters = new Class[]{URL.class};
> URLClassLoader sysloader = (URLClassLoader)
> ClassLoader.getSystemClassLoader();
> Class sysclass = URLClassLoader.class;
> try {
>Method method = sysclass.getDeclaredMethod("addURL", parameters);
>method.setAccessible(true);
>method.invoke(sysloader, new Object[]{url});
> } catch (Throwable t) {
>t.printStackTrace();
>throw new IOException("Error, could not add URL to system
> classloader");
> }//end try catch
>
> Again, for some reason this doesnt work.I can inject jar files into the
> system classloader using the above technique but not individual classes from
> jars.
Because the system classloader only understands jars
and directories. You can load the class file into
memory and feed the byte[] to the classloader with
the same kind of reflection techniques you use above.
Note that I'm _not_ recommending this, simply pointing
it out.
--Thilo
>
>
> Jerry
>
>
> On Sun, Oct 18, 2009 at 4:22 PM, Marshall Schor wrote:
>
>> Hi everyone,
>>
>> I'm "itching" to get the 2.3.0 release done.
>>
>> Of the issues that are open, reopened, or in-progress, most are now
>> being deferred to past this release.
>>
>> The ones left that may need to be worked on before the release is done
>> include:
>>
>> (Joern) UIMA-1619
>> Clarify that a Cas Editor Project is required to use the Cas Editor in
>> the documentation
>> (Eddie)UIMA-1611
>> UimacppServiceControlled need to implement isStopped()
>>
>> (Marshall) UIMA-1539
>> Update READMEs for 2.3.0 release
>>
>> (Jerry) UIMA-1153
>> thread safety issue with sample flow controller
>> AdvancedFixedFlowController
>>
>> (Eddie)UIMA-1038
>> setUimaClasspath.sh
>> should export library paths for interoperability with UIMA C++
>>
>> (Jerry) UIMA-1531
>> Need a script to launch
>> a UIMA-AS service via RunWithJarPath
>>
>> (Jerry) UIMA-1484
>> Update UIMA-AS Documentation
>>
>>
>> Could the people in (parenthesis) take the lead in looking at these and
>> try and close out these issues?
>>
>> Thanks! -Marshall
>>
>
Re: UIMA report is due
Tommaso, thanks for taking care of the report. I tried to add a line, but can't seem to log in to the wiki right now. Since we don't have much time, could you add a bullet on the recent UIMA workshop at a comp. ling. conference (Joern and I were there): - academic UIMA http://docs.google.com/View?id=dft23bqs_3c7qnzg6x";>workshop with strong participation from UIMA's users list community Thanks, Thilo Tommaso Teofili wrote: > I never wrote that report before, but if nobody else comes out I volunteer > (maybe I'll ask some help here and there to gather all the informations). > +1 for begin the graduation process after the 2.3.0 release. > Tommaso > > 2009/10/13 Jukka Zitting > >> Hi, >> >> We're again due for our quarterly report, see [1]. Anyone willing to >> draft the report? >> >> As for the top priorities before graduation, I think UIMA is now ready >> to graduate and only needs to follow the graduation process [2] to >> become an Apache TLP. >> >> [1] http://wiki.apache.org/incubator/October2009 >> [2] http://incubator.apache.org/guides/graduation.html#process >> >> BR, >> >> Jukka Zitting >> >
Re: [jira] Created: (UIMA-1603) Missing doc describing service spec syntax
Marshall Schor wrote: > Thilo - I think you're probably the best one to add this doc; is this > something you can do shortly to include in 2.3.0 or should I defer this > past 2.3.0 release? I don't think I'll be able to work on this immediately, so let's please defer this till after the 2.3 release. --Thilo > > -Marshall > > Olivier Terrier (JIRA) wrote: >> Missing doc describing service spec syntax >> -- >> >> Key: UIMA-1603 >> URL: https://issues.apache.org/jira/browse/UIMA-1603 >> Project: UIMA >> Issue Type: Improvement >> Components: Sandbox-SimpleServer >> Affects Versions: 2.2.2 >> Reporter: Olivier Terrier >> Priority: Minor >> >> >> The SimpleServer is a great contribution, unfortunately, the documentation >> is quite incomplete. >> In particular there is now (even basic) guidelines on how to write a result >> spec xml file to customize the output. >> Even a simple readme file would be of great help >> >> >>
Re: [jira] Reopened: (UIMA-1531) Need a script to launch a UIMA-AS service via RunWithJarPath
Marshall Schor wrote: > > Eddie Epstein (JIRA) wrote: >> [ >> https://issues.apache.org/jira/browse/UIMA-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >> ] >> >> Eddie Epstein reopened UIMA-1531: >> - >> >> >> In the previous version of UIMA AS, the CVD application could be used to run >> a uima-as service via a jms-client descriptor. This doesn't work now because >> of missing UIMA AS jars from the CVD classpath. This is also true for other >> core UIMA command line scripts. >> >> One workaround could be to create an appropriate UIMA_CLASSPATH with a bunch >> of jars. An more user friendly workaround would be to add support for >> UIMA_JAR_PATH to the core UIMA command scripts. >> >> Comments? >> > Seems like a good idea to me, +1 -Marshall I still think it's a bad idea to put more class loading mysteries in the way of our users. --Thilo >> >>> Need a script to launch a UIMA-AS service via RunWithJarPath >>> >>> >>> Key: UIMA-1531 >>> URL: https://issues.apache.org/jira/browse/UIMA-1531 >>> Project: UIMA >>> Issue Type: New Feature >>> Components: Async Scaleout >>>Affects Versions: 2.3AS >>>Reporter: Jerry Cwiklik >>>Assignee: Jerry Cwiklik >>> Fix For: 2.3AS >>> >>> >>> Use existing RunWithJarPath.class from the core to enable loading jars >>> dynamically when launching UIMA AS service. Currently setUimaClasspath is >>> called to setup static classpath before deployment of UIMA_Service. For >>> more flexibility it would be better to >>> load all jar files from specified locations instead of depending on them to >>> be statically defined in setUimaClasspath. One of the reasons for >>> supporting dynamically loaded jars is the naming scheme used by ActiveMQ. >>> Each version comes with a differently named jars like for example >>> apache-activemq-4.1.1.jar, activemq-all-5.2.0.jar, etc. >>> >>
DDoS on Jira et al.
For those of you not following the infra mailing list: a distributed denial of service attack against the machine that hosts our Jira instance has been ongoing for the past several days. The infra team has been able to contain the attack, but it is still ongoing and Jira may be slower than usual. --Thilo
Re: CPM test case hang
Marshall Schor wrote: > > Thilo Goetz wrote: >> Marshall Schor wrote: >> >>> Thilo Goetz wrote: >>> >>>> Thilo Goetz wrote: >>>> >>>> >>>>> Works fine with UIMA 2.2.2. I guess it's time to nuke the >>>>> maven repo, do a clean extract from svn and see what happens. >>>>> And do a reboot in the bargain :-) >>>>> >>>>> >>>> Did the above except nuke the maven repo, and it still hangs. >>>> Let me know if you want me to do anything to investigate. >>>> >>>> >>> Please do the following when you get the hang to produce some >>> diagnositic info: >>> >>> Press ctrl-break to generate a Java Dump >>> >>> Look in the Java Dump for the section labeled: >>> LOCKS subcomponent dump routine >>> >>> See if you see anything like >>> Deadlock detected !!! >>> - >>> >> Well, no deadlock detected, I'm afraid. I include the locks >> and threads section below. This is starting to look like a >> maven problem to me. I see all these threads waiting, and >> they all seem to be maven threads, not from any CPM code afaict. >> The JSR 166 backport classes seem to come out of the maven >> jar. Unfortunately I can't try a different maven version >> as our build appears to require 2.2 now. >> >> Great hint about Ctrl-Break, I didn't know you could do >> that. >> > Can you run the tests from Eclipse? Do they hang if you do that? > > Thanks... -Marshall Works in Eclipse. I so we can conclude that it's a maven issue. >> --Thilo >> >> 0SECTION LOCKS subcomponent dump routine >> NULL === >> NULL >> 1LKPOOLINFOMonitor pool info: >> 2LKPOOLTOTAL Current total number of monitors: 21 >> NULL >> 1LKMONPOOLDUMP Monitor Pool Dump (flat & inflated object-monitors): >> 2LKMONINUSE sys_mon_t:0x62AB2998 infl_mon_t: 0x62AB29D8: >> 3LKMONOBJECT >> hidden/edu/emory/mathcs/backport/java/util/concurrent/linkedblockingqueue$serializablel...@00be1de8/00BE1DF4: >> >> 3LKNOTIFYQWaiting to be notified: >> 3LKWAITNOTIFY"pool-1-thread-1" (0x62695900) >> 3LKWAITNOTIFY"pool-1-thread-2" (0x62EC1500) >> 3LKWAITNOTIFY"pool-1-thread-3" (0x62EC1900) >> 3LKWAITNOTIFY"pool-1-thread-4" (0x62EC1D00) >> 3LKWAITNOTIFY"pool-1-thread-5" (0x62C3FD00) >> NULL >> >> 0SECTION THREADS subcomponent dump routine >> NULL = >> NULL >> 1XMCURTHDINFO Current Thread Details >> NULL -- >> NULL >> 1XMTHDINFO All Thread Details >> NULL -- >> NULL >> 2XMFULLTHDDUMP Full thread dump J9 VM (J2RE 5.0 IBM J9 2.3 Windows XP x86-32 >> build 20090706_38445_lHdSMr, native threads): >> 3XMTHREADINFO "main" (TID:0x0009F300, sys_thread_t:0x00036E28, state:R, >> native ID:0x084C) prio=5 >> 4XESTACKTRACE at java/lang/ProcessImpl.waitFor(Native Method) >> 4XESTACKTRACE at >> org/apache/maven/surefire/booter/shade/org/codehaus/plexus/util/cli/CommandLineUtils.executeCommandLine(CommandLineUtils.java:146) >> 4XESTACKTRACE at >> org/apache/maven/surefire/booter/shade/org/codehaus/plexus/util/cli/CommandLineUtils.executeCommandLine(CommandLineUtils.java:98) >> 4XESTACKTRACE at >> org/apache/maven/surefire/booter/SurefireBooter.fork(SurefireBooter.java:673) >> 4XESTACKTRACE at >> org/apache/maven/surefire/booter/SurefireBooter.forkSuites(SurefireBooter.java:479) >> 4XESTACKTRACE at >> org/apache/maven/surefire/booter/SurefireBooter.runSuitesForkOnce(SurefireBooter.java:379) >> 4XESTACKTRACE at >> org/apache/maven/surefire/booter/SurefireBooter.run(SurefireBooter.java:245) >> 4XESTACKTRACE at >> org/apache/maven/plugin/surefire/SurefirePlugin.execute(SurefirePlugin.java:537) >> 4XESTACKTRACE at >> org/apache/maven/plugin/DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) >> 4XESTACKTRACE at >> org/apache/maven/lifecycle/DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) >> 4XESTACKTRACE at >> org/apache/maven/lifecycle/DefaultLifecycleExecutor.executeGoalW
Re: CPM test case hang
Marshall Schor wrote: > Thilo Goetz wrote: >> Thilo Goetz wrote: >> >>> Works fine with UIMA 2.2.2. I guess it's time to nuke the >>> maven repo, do a clean extract from svn and see what happens. >>> And do a reboot in the bargain :-) >>> >> Did the above except nuke the maven repo, and it still hangs. >> Let me know if you want me to do anything to investigate. >> > Please do the following when you get the hang to produce some > diagnositic info: > > Press ctrl-break to generate a Java Dump > > Look in the Java Dump for the section labeled: > LOCKS subcomponent dump routine > > See if you see anything like > Deadlock detected !!! > - Well, no deadlock detected, I'm afraid. I include the locks and threads section below. This is starting to look like a maven problem to me. I see all these threads waiting, and they all seem to be maven threads, not from any CPM code afaict. The JSR 166 backport classes seem to come out of the maven jar. Unfortunately I can't try a different maven version as our build appears to require 2.2 now. Great hint about Ctrl-Break, I didn't know you could do that. --Thilo 0SECTION LOCKS subcomponent dump routine NULL === NULL 1LKPOOLINFOMonitor pool info: 2LKPOOLTOTAL Current total number of monitors: 21 NULL 1LKMONPOOLDUMP Monitor Pool Dump (flat & inflated object-monitors): 2LKMONINUSE sys_mon_t:0x62AB2998 infl_mon_t: 0x62AB29D8: 3LKMONOBJECT hidden/edu/emory/mathcs/backport/java/util/concurrent/linkedblockingqueue$serializablel...@00be1de8/00BE1DF4: 3LKNOTIFYQWaiting to be notified: 3LKWAITNOTIFY"pool-1-thread-1" (0x62695900) 3LKWAITNOTIFY"pool-1-thread-2" (0x62EC1500) 3LKWAITNOTIFY"pool-1-thread-3" (0x62EC1900) 3LKWAITNOTIFY"pool-1-thread-4" (0x62EC1D00) 3LKWAITNOTIFY"pool-1-thread-5" (0x62C3FD00) NULL 0SECTION THREADS subcomponent dump routine NULL = NULL 1XMCURTHDINFO Current Thread Details NULL -- NULL 1XMTHDINFO All Thread Details NULL -- NULL 2XMFULLTHDDUMP Full thread dump J9 VM (J2RE 5.0 IBM J9 2.3 Windows XP x86-32 build 20090706_38445_lHdSMr, native threads): 3XMTHREADINFO "main" (TID:0x0009F300, sys_thread_t:0x00036E28, state:R, native ID:0x084C) prio=5 4XESTACKTRACE at java/lang/ProcessImpl.waitFor(Native Method) 4XESTACKTRACE at org/apache/maven/surefire/booter/shade/org/codehaus/plexus/util/cli/CommandLineUtils.executeCommandLine(CommandLineUtils.java:146) 4XESTACKTRACE at org/apache/maven/surefire/booter/shade/org/codehaus/plexus/util/cli/CommandLineUtils.executeCommandLine(CommandLineUtils.java:98) 4XESTACKTRACE at org/apache/maven/surefire/booter/SurefireBooter.fork(SurefireBooter.java:673) 4XESTACKTRACE at org/apache/maven/surefire/booter/SurefireBooter.forkSuites(SurefireBooter.java:479) 4XESTACKTRACE at org/apache/maven/surefire/booter/SurefireBooter.runSuitesForkOnce(SurefireBooter.java:379) 4XESTACKTRACE at org/apache/maven/surefire/booter/SurefireBooter.run(SurefireBooter.java:245) 4XESTACKTRACE at org/apache/maven/plugin/surefire/SurefirePlugin.execute(SurefirePlugin.java:537) 4XESTACKTRACE at org/apache/maven/plugin/DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) 4XESTACKTRACE at org/apache/maven/lifecycle/DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) 4XESTACKTRACE at org/apache/maven/lifecycle/DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) 4XESTACKTRACE at org/apache/maven/lifecycle/DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) 4XESTACKTRACE at org/apache/maven/lifecycle/DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) 4XESTACKTRACE at org/apache/maven/lifecycle/DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) 4XESTACKTRACE at org/apache/maven/lifecycle/DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) 4XESTACKTRACE at org/apache/maven/DefaultMaven.doExecute(DefaultMaven.java:328) 4XESTACKTRACE at org/apache/maven/DefaultMaven.execute(DefaultMaven.java:138) 4XESTACKTRACE at org/apache/maven/cli/MavenCli.main(MavenCli.java:362(Compiled Code)) 4XESTACKTRACE at org/apache/maven/cli/compat/CompatibleMain.main(CompatibleMain.java:60) 4XESTACKTRACE at sun/reflect/NativeMethodAccessorImpl.invoke0(Native Method) 4XESTACKTRACE at sun/reflect/NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
Re: CPM test case hang
Thilo Goetz wrote: > Works fine with UIMA 2.2.2. I guess it's time to nuke the > maven repo, do a clean extract from svn and see what happens. > And do a reboot in the bargain :-) Did the above except nuke the maven repo, and it still hangs. Let me know if you want me to do anything to investigate. --Thilo > > --Thilo > > Thilo Goetz wrote: >> Jaroslaw Cwiklik wrote: >>> I've applied a patch to VinciCasProcessorDeployer.java. Build with a version >>> before the patch was applied and see if this problem goes away. >> No luck. I went back as far as I could so it would still compile, >> and still had the same problem. I guess the next thing to do would >> be to try our last release on that machine with that jvm and see >> if I have the same issue. I'll do that when I have time. >> >> --Thilo >> >>> JC >>> >>> On Fri, Sep 4, 2009 at 11:44 AM, Thilo Goetz wrote: >>> >>>> Jaroslaw Cwiklik wrote: >>>>> Ran on the command line multiple times with IBM 1.5 and Sun's 1.5 and no >>>>> hang. >>>> Yes, I can't reproduce it either on my laptop. Same code level, >>>> same jvm, both dual core processors, same maven version even. Still >>>> hangs reliably on my workstation, though. Some subtle synchronization >>>> issue, undoubtedly. Let me know if you want me to go back to an >>>> earlier code level and try there, or if there's anything else I can >>>> do to help. >>>> >>>> --Thilo >>>> >>>>> JC >>>>> >>>>> On Fri, Sep 4, 2009 at 10:26 AM, Thilo Goetz wrote: >>>>> >>>>>> Jaroslaw Cwiklik wrote: >>>>>>> Thilo, I've tried IBM's 1.5.8 and Sun's 1.5 and I cant recreate the >>>> hang. >>>>>> I >>>>>>> run the test cases in eclipse. Is anyone else having this problem? >>>>>> Please try it on the command line, that's where I had the problem. >>>>>> >>>>>> --Thilo >>>>>> >>>>>>> Jerry >>>>>>> >>>>>>> On Thu, Sep 3, 2009 at 9:19 AM, Jaroslaw Cwiklik >>>>>> wrote: >>>>>>>> Thilo, recently I applied a patch attached to JIRA UIMA-1304. I only >>>>>> tested >>>>>>>> this with JDK1.6. I will look into this today. >>>>>>>> >>>>>>>> Jerry >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Sep 3, 2009 at 5:00 AM, Thilo Goetz wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> has anything changed in the CPM recently? I get >>>>>>>>> a reliable test case hang here (no cpu activity): >>>>>>>>> >>>>>>>>> --- >>>>>>>>> T E S T S >>>>>>>>> --- >>>>>>>>> Running org.apache.uima.collection.impl.cpm.CpmProcessingTest >>>>>>>>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.344 >>>>>> sec >>>>>>>>> Running org.apache.uima.collection.impl.cpm.CasPoolTest >>>>>>>>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.125 >>>>>> sec >>>>>>>>> Running org.apache.uima.collection.impl.cpm.CpmInitTest >>>>>>>>> Initialize was called: true >>>>>>>>> Sep 3, 2009 10:50:48 AM >>>> org.apache.uima.collection.impl.cpm.BaseCPMImpl >>>>>>>>> process >>>>>>>>> WARNING: Processing the request to stop the CPM. (Thread Name: main) >>>>>>>>> Sep 3, 2009 10:50:48 AM >>>>>>>>> org.apache.uima.collection.impl.cpm.engine.CPMEngine process >>>>>>>>> INFO: The collection reader thread state is: 2007 (Thread Name: main) >>>>>>>>> >>>>>>>>> I have to kill the process, so I don't have more info than this. >>>>>>>>> It only happens with this jvm (on windows): >>>>>>>>> >>>>>>>>> java version "1.5.0" >>>>>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>>> pwi32dev-20090707 >>>>>>>>> (SR10 )) >>>>>>>>> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 >>>>>>>>> j9vmwi3223-20090707 (JIT enabled) >>>>>>>>> J9VM - 20090706_38445_lHdSMr >>>>>>>>> JIT - 20090623_1334_r8 >>>>>>>>> GC - 200906_09) >>>>>>>>> JCL - 20090705 >>>>>>>>> >>>>>>>>> I tried 3 others, and it goes through with all of them: >>>>>>>>> >>>>>>>>> java version "1.6.0" >>>>>>>>> Java(TM) SE Runtime Environment (build pwi3260sr5-20090529_04(SR5)) >>>>>>>>> IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 >>>>>>>>> jvmwi3260sr5-20090519_35743 (JIT enabled, AOT enabled) >>>>>>>>> J9VM - 20090519_035743_lHdSMr >>>>>>>>> JIT - r9_20090518_2017 >>>>>>>>> GC - 20090417_AA) >>>>>>>>> JCL - 20090529_01 >>>>>>>>> >>>>>>>>> java version "1.5.0_11" >>>>>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) >>>>>>>>> Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode) >>>>>>>>> >>>>>>>>> java version "1.6.0_13" >>>>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_13-b03) >>>>>>>>> Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode) >>>>>>>>> >>>>>>>>> Let me know if you need more information. >>>>>>>>> >>>>>>>>> --Thilo >>>>>>>>>
[jira] Commented: (UIMA-1546) Fix sandbox notice and license files
[ https://issues.apache.org/jira/browse/UIMA-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759646#action_12759646 ] Thilo Goetz commented on UIMA-1546: --- > I may be confused. There is a Lic/Not file here: > https://svn.apache.org/repos/asf/incubator/uima/sandbox/trunk (which is not > in any particular Sandbox project, but in the directory which contains all of > the sand box projects). > Yes, that's what I meant when I said "top level sandbox directory". We need that one anyway, and it needs to be the aggregate of all the src NOTICE files, right? So what's the point of maintainng it twice? Can't the assembly step access it or something? > There are similar files for the base uima (in > https://svn.apache.org/repos/asf/incubator/uima/uimaj/trunk) and in uima-as > (https://svn.apache.org/repos/asf/incubator/uima/uima-as/trunk) and uimacpp. > Yes. > I don't think there's a reason to put them in the SandboxDistr project > itself, at the top level of that pom project. Do you agree? The other > copies are in the annotator-package, under the build - where they are the > ones for the "merged" src/bin distributions that we build and officially > release. Sure. > > I would rather leave these two as they are - with the src ones just being > simple apache license and default notice files, for this release cycle, and > updating hte bin ones to be the merge of the "bin" ones in each released > sandbox project. For the individual releasing sandbox subprojects, they > only have "one" version - the one for the bin; the assembly build at the > moment uses that for the bin assembly, and uses the plain-vanilla ones for > the src assembly. That's what I don't understand, but maybe there are maven reasons that I don't know about. The src LICENSE/NOTICE files need to mention the third-party jars we're distributing with the src, those that are checked in in svn. I know you eliminated some, but are there none left? Is our sandbox distribution now just our own code? > Fix sandbox notice and license files > > > Key: UIMA-1546 > URL: https://issues.apache.org/jira/browse/UIMA-1546 > Project: UIMA > Issue Type: Bug > Components: Sandbox >Reporter: Thilo Goetz > Fix For: 2.3S > > > Review all sandbox notice and license files. Make sure top-level notice and > license files are aggregates of the component ones. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1546) Fix sandbox notice and license files
[ https://issues.apache.org/jira/browse/UIMA-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759591#action_12759591 ] Thilo Goetz commented on UIMA-1546: --- We need NOTICE/LICENSE files in the top level sandbox directory. We added them for core as well because we were required to by the IPMC. That's the set of files that I've been updating, and this set of files should replace whatever is in the readme-src (I didn't realize that existed). Jukka's point in the recent email discussion was that it would be sufficient to have one set of NOTICE/LICENSE files for the src and bin distributions, even if not everything that's in a bin distribution is also in a src distribution. So it seems to me we should just keep the top level files, and get rid of the ones in SandboxDistr (including the ones for SandboxDistr itself). > Fix sandbox notice and license files > > > Key: UIMA-1546 > URL: https://issues.apache.org/jira/browse/UIMA-1546 > Project: UIMA > Issue Type: Bug > Components: Sandbox >Reporter: Thilo Goetz > Fix For: 2.3S > > > Review all sandbox notice and license files. Make sure top-level notice and > license files are aggregates of the component ones. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SimpleServer special "assembly"
Marshall Schor wrote: > > Tommaso Teofili wrote: >> the specific assembly for SimpleServer was added to make a distribution jar >> when you run 'mvn package', containg /lib jars too (actually only >> uima-simple-server-xbean-1.0.jar). >> > IIRC, this was added in UIMA-1462 to support the SimpleUimaAsService, is > that correct? > > If so I would like to change this to a simpler approach, that > * automatically generates the xml parser classes at build time if > needed (if the .xsd files change) > * puts those classes into the main Jar - so we can get rid of the > uima-simple-server-xbean.jar > > To do this: > > 1) delete the special assembly > 2) replace the build_config_xml.xml script with an entry in the POM > which invokes the xmlbean maven plugin (yes, there is one!) > > Then, the Simple Uima-AS server can just rely on the one SimpleServer Jar. > > I've tried this, and it works, test cases go thru on Windows, etc. > > Any objections? +1, great work Marshall. --Thilo > > -Marshall >> Tommaso >> >> 2009/9/22 Marshall Schor >> >> >>> The SimpleServer project is the only sandbox project with its own >>> "assembly", which is done in addition to the Sandbox assembly. >>> >>> It produces one "bin"-style assembly, and packages it as a Jar. This >>> Jar has >>> * the class files >>> * a lib directory containing embedded Jars - one for the simple server, >>> and one for the special generated uima-simple-server-xbean-1.0 jar. >>> * META-INF dir having the LIC/NOT/DIS files plus the MANIFEST. >>> * a samples dir (in the Jar because it's in src/resources) >>> * a SimpleServerConfig.xsd file (in the Jar because it's in src/resources) >>> >>> Should we keep this additional assembly? I guess it seems a bit >>> confusing to have one of the projects have an additional assembly, but >>> perhaps it's being used by others, and should therefore be kept. I >>> would lean toward removing this, if it won't break users... >>> >>> -Marshall >>> >>> >>> >>> >>
[jira] Commented: (UIMA-1581) RegularExpressionAnnotator tests fail
[ https://issues.apache.org/jira/browse/UIMA-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758711#action_12758711 ] Thilo Goetz commented on UIMA-1581: --- Is this also due to EOL character issues? > RegularExpressionAnnotator tests fail > - > > Key: UIMA-1581 > URL: https://issues.apache.org/jira/browse/UIMA-1581 > Project: UIMA > Issue Type: Bug > Components: Sandbox-RegexAnnotator >Affects Versions: 2.3S > Environment: MacOS X >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: 2.3 > > > the following TestSetFeatureValues tests fail: > * testSetFeatureValues1 > * testSetFeatureValues2 > * testSetFeatureValues3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: tika annotator - License/Notice and Export Control
Marshall Schor wrote: > The tika annotator is packaging the following 3rd party artifacts at the > moment: > These first 2 are the Apache Licensed code of the actual tika > project <<< > > org.apache.tika:tika-core:jar:0.4:compile > org.apache.tika:tika-parsers:jar:0.4:compile > These next are 3rd party Jars. Some not from Apache <<< > > org.apache.commons:commons-compress:jar:1.0:compile > pdfbox:pdfbox:jar:0.7.3:compile > org.fontbox:fontbox:jar:0.1.0:compile > org.jempbox:jempbox:jar:0.2.0:compile > bouncycastle:bcmail-jdk14:jar:136:compile > bouncycastle:bcprov-jdk14:jar:136:compile > org.apache.poi:poi:jar:3.5-beta6:compile > org.apache.poi:poi-scratchpad:jar:3.5-beta6:compile > org.apache.poi:poi-ooxml:jar:3.5-beta6:compile > org.apache.poi:ooxml-schemas:jar:1.0:compile > org.apache.xmlbeans:xmlbeans:jar:2.3.0:compile > dom4j:dom4j:jar:1.6.1:compile > xml-apis:xml-apis:jar:1.0.b2:compile > org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0:compile > commons-logging:commons-logging:jar:1.1.1:compile > net.sourceforge.nekohtml:nekohtml:jar:1.9.9:compile > xerces:xercesImpl:jar:2.8.1:compile > asm:asm:jar:3.1:compile > log4j:log4j:jar:1.2.14:compile > > I'm pretty sure that the LICENSE/NOTICE files need updating to cover all > of these components. I checked one, the asm:asm:jar:3.1 - and found > it's license requires including certain notices, contain in its license, > in all redistributions. > > The Tika project gets around this by not having any binary distribution; > so they never > distribute (themselves) these parts. > > I believe we also need to get an Export 5D002 Registration for the Tika > Annotator, and also for the > Sandbox Distribution which includes it. > > Any volunteers to research the License/Notice requirements for these > components? > > -Marshall Ouch. How about we just pass the buck and don't distribute Tika either? I'm sure there will be a binary Tika distro eventually, with all the licenses and notices figured out. At that point, let's redistribute. Unless someone volunteers, that is. The Tika website has instructions on how to build etc. that we can point to. --Thilo
Re: SimpleServer dependencies on 3rd party jars
Marshall Schor wrote: > I went through these, and change the dependencies as follows: > > 1) org.apache.xmlbeans:xmlbeans changed to 2.4.0 (was 2.3.0) - several > other projects are using 2.4.0, and I thought it best to stay consistent :-) > > 2)javax.xml.bind:jsr173_api commented out. Instead, the xmlbeans > transitively pulls in stax:stax-api 1.0.1. This is the same as several > other sandbox projects using xmlbeans. > > 3) changed the other dependencies for things which were not included in > the lib/ previously, to provided - this puts these in the > compile-time classpath, but they are excluded from the jars that the > dependency plugin pulls into the lib/ that will be distributed. > > Is this OK? (it does build, run the tests, etc.). > > -Marshall As long as the test cases go through, that should be fine. Somebody will need to adapt the docs as well. I can do that, but I won't have time to do anything before the middle of next week. --Thilo
Re: xmlbeans use of either stax or jsr173_api jars
Tommaso Teofili wrote: > Hi Marshall,I tried to remove jsr173 dependency from SimpleServer and > DictionaryAnnotator and used Xmlbeans 2.4.0 version. > Tests and packaging behave properly (/lib directory had not been removed in > SimpleServer since I was waiting for the issue to be closed, but it should > be deleted as soon as "Maven way" is definitely chosen). > > StAX ( http://stax.codehaus.org/Home ) is under Apache License 2.0 so it's > ok from the licensing point of view, we should only investigate if we "like" > this JSR173 specification implementation or we would like to choose another > one. > In my opinion it is ok (no more dependencies needed). If the test cases go through, it's safe to switch and I'm all for it (speaking for SimpleServer and RegexAnnotator). --Thilo > > Tommaso > > > 2009/9/21 Marshall Schor > >> Several sandbox projects have dependencies on xmlbeans (e.g. >> RegularExpressionAnnotator, SimpleServer, and >> ConfigurableFeatureExtractor). >> >> The first 2 have obtained xmlbeans from http://xmlbeans.apache.org (as >> evidenced by their NOTICE). >> >> They have copied (some of) the Jar files that come from this into their >> lib/ directories (xbean.jar, jsr173_1.0_api.jar). >> >> The maven repo entry >> >> http://repo1.maven.org/maven2/org/apache/xmlbeans/xmlbeans/2.4.0/xmlbeans-2.4.0.pom >> lists a dependency >> >> >> stax >> stax-api >> 1.0.1 >> >> >> In the maven repository, this is listed as an Apache-licensed Jar, and I >> have read on the web (must be right :-) ) that this is a substitute >> which could be used instead of the jsr173_1.0_api. >> >> If I switch things in the Sandbox to obtain jar parts that are >> dependencies from the Maven repo system, instead of taking them from our >> lib/ directories, this change will result in having the above 2 projects >> get the xbean jar (as before) at version 2.4.0 and the stax_api jar >> version 1.0.1 instead of the jsr173_1.0_api. >> >> Is this OK? >> >> -Marshall (who is quite confused by the existence of all these >> alternative ways of putting parts together...) >> >
Re: A common approach to sandbox projects distribution of 3rd party jars
See my other mail in this thread, but also inline below. --Thilo Marshall Schor wrote: > > Thilo Goetz wrote: >> Jukka Zitting wrote: >> >>> Hi, >>> >>> On Sun, Sep 20, 2009 at 10:19 PM, Marshall Schor wrote: >>> >>>> After thinking about this for a while, and considering both methods, I >>>> think the most reliable way to handle 3rd party Jars is to manually put >>>> them into the lib/ directory, once, and then check the lib/ directory >>>> into SVN. This avoids build issues in the future which could occur if >>>> the Jar obtained from the maven dependency plugin is somehow corrupted, >>>> or changes level, etc. Also, having the Jars in SVN insures that >>>> whatever work we do to update the LICENSE/NOTICE files for those Jars >>>> remains valid (because the Jar doesn't (potentially) change). >>>> >>> By policy non-SNAPSHOT artifact in the Maven repository never change, >>> and each artifact is accompanied by checksums that guard against >>> corruption. It's possible for a user to mess up the files in their >>> local Maven repository, but it's probably just as likely that they'd >>> mess up any files in ./lib. >>> >>> To me the proposed solution sounds like extra effort with little or no >>> benefit. >>> >> One benefit I see is that you have only one NOTICE/LICENSE file >> for the source and binary distribution. > I had trouble understanding this, until I guessed that you're assuming > here that we will include these Jars in the "src" distribution, is this > right? >> What's more, if your >> source distribution does not include the dependencies and you >> therefore don't mention them in your NOTICE/LICENSE files, it >> might come as a surprise to users that the build pulls in all >> those files they didn't know about (or they don't even notice, >> which would be even worse). >> > > I see. The choices here: > > * case 1: having 3rd party Jars checked into SVN > 1.a) shipping these in the "src" distrib: have to match LIC/NOT pair > with bin, no "surprise" > 1.b) not shipping these in the "src" distrb: different LIC/NOT pair > for src, potential surprise when building with maven I don't think 1b is an option. If they're in svn, they need to be in the source distribution. > > * case 2: not having 3rd party Jars checked into SVN >different LIC/NOT pair for src, potential surprise when building with > maven > > Do you prefer approach 1.a? That's what I'm now thinking is best. I > had been thinking 1.b) because I didn't think through the reasons to > ship the Jars with the source distribution. > > -Marshall > >> --Thilo >> >> >>> BR, >>> >>> Jukka Zitting >>> >> >>
Re: A common approach to sandbox projects distribution of 3rd party jars
Jukka Zitting wrote: ... > The LICENSE/NOTICE point that Thilo brought up is a valid one, though > especially when the default build embeds external dependencies to the > build target, it's quite OK to include also their licenses in the > licensing metadata even if those dependencies strictly speaking aren't > being shipped as a part of the source distribution. You think so? Even with all the "nothing goes into a NOTICE file unless it has to" hubbub? We don't want to create a new maven flame war when we take this release to the IPMC :-) However in that case I guess I would also prefer to have maven fetch the dependencies. Seems wasteful to have them in svn. Not sure how much work it is to change the build, though... --Thilo
Re: Making sandbox documentation available on our website
Michael Baessler wrote: > Some time ago we discussed another way to access the current "trunk" version > of the documentation. > For some projects this was already enabled, but it seems that it never works > :-( > > We agreed to check-in the current pdf version of the documentation for a > component and link this > file directly in the Sandbox description. This was done for example for the > RegexAnnotator, > DictionaryAnnotator, SimpleServer, ... > > Not sure if we need both ways, I don't think so. So I'm fine with Marshall's > suggestion but in that > case we should remove the old links that for some reasons are broken for some > components. > > -- Michael > > Marshall Schor wrote: >> I plan to make a modification to the web-site to host all the sandbox >> documentation, similar to how we host the base UIMA documentation. Any >> objections? >> >> In preparation for this I'll be updating the builds for the sandbox >> documentation to update a directory in the uima-website project. I plan >> to add a directory named >> uima-website/docs/downloads/next-release/sandbox/. >> >> After the release is approved, we can move the stuff in next-release to >> the current place: uima-website/docs/downloads/sandbox/. >> >> The website will only host the "current" release. People wanting older >> ones, can always download the distribution. >> >> -Marshall +1 to Marshall's plan in principle. I think one reason we created this special sandbox documentation that Michael refers to is that we have sandbox projects that have not seen a release yet; but we still want people to be able to get to the documentation so we can possibly get early adopters and feedback. What's your thought on that issue? Create a subsection for non-released sandbox artifacts, where we follow the "link to checked in docs" procedure that Michael is alluding to? --Thilo
Re: A common approach to sandbox projects distribution of 3rd party jars
Jukka Zitting wrote: > Hi, > > On Sun, Sep 20, 2009 at 10:19 PM, Marshall Schor wrote: >> After thinking about this for a while, and considering both methods, I >> think the most reliable way to handle 3rd party Jars is to manually put >> them into the lib/ directory, once, and then check the lib/ directory >> into SVN. This avoids build issues in the future which could occur if >> the Jar obtained from the maven dependency plugin is somehow corrupted, >> or changes level, etc. Also, having the Jars in SVN insures that >> whatever work we do to update the LICENSE/NOTICE files for those Jars >> remains valid (because the Jar doesn't (potentially) change). > > By policy non-SNAPSHOT artifact in the Maven repository never change, > and each artifact is accompanied by checksums that guard against > corruption. It's possible for a user to mess up the files in their > local Maven repository, but it's probably just as likely that they'd > mess up any files in ./lib. > > To me the proposed solution sounds like extra effort with little or no > benefit. One benefit I see is that you have only one NOTICE/LICENSE file for the source and binary distribution. What's more, if your source distribution does not include the dependencies and you therefore don't mention them in your NOTICE/LICENSE files, it might come as a surprise to users that the build pulls in all those files they didn't know about (or they don't even notice, which would be even worse). --Thilo > > BR, > > Jukka Zitting
Re: [jira] Created: (UIMA-1552) Lucas: does not compile with Java 1.5
Marshall Schor wrote: > > Thilo Goetz wrote: >> Thilo Goetz (JIRA) wrote: >> >>> Lucas: does not compile with Java 1.5 >>> - >>> >>> Key: UIMA-1552 >>> URL: https://issues.apache.org/jira/browse/UIMA-1552 >>> Project: UIMA >>> Issue Type: Bug >>> Components: Sandbox-Lucas >>> Reporter: Thilo Goetz >>> Assignee: Thilo Goetz >>> Fix For: 2.3S >>> >>> >>> Lucas uses IOException constructors that are not in Java 1.5. >>> >>> >> This reminds me: Marshall, please remember to build our >> release with Java 1.5. Otherwise people may not be able >> to run our binaries with 1.5. Thanks. >> > hmmm, I think this is supposed to be automatic. IIRC, the way it is > supposed to work is the top level parent, uimaj/pom.xml, has java 1.5 > specified: > > > > > > org.apache.maven.plugins > maven-compiler-plugin > > 1.5 > 1.5 > UTF-8 > > > > The eclipse:eclipse maven plugin which generates the Eclipse stuff from > the POMs, takes this and sets 1.5 in the ".settings". file for the > Eclipse project. > > Any idea what is going wrong? -Marshall What this switch controls (and this is true in Eclipse as well) is the language level and the class file level. I.e., this ensures that no new language features of 1.6 are used in the code. These are switches that the Java compiler itself offers, so this is easy to implement. What this switch does not control is the level of the libraries that you compile against. If you use Java 1.6 for compilation, it will contain 1.6 versions of the libraries. If there are new features in there, you can use those features, the 1.5 compiler switches notwithstanding. That's the issue we face here. So to be sure you're not compiling against _library_ features that are only available in 1.6, you will always need to compile with 1.5 anyway. In that sense, the source and target switches are misleading and not that useful, except for documentation purposes. --Thilo > > >> --Thilo >> >> >> >>
[jira] Commented: (UIMA-1273) Pear runtime pulls in all jar files in pear lib directory, no matter if they're on the classpath or not
[ https://issues.apache.org/jira/browse/UIMA-1273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12757853#action_12757853 ] Thilo Goetz commented on UIMA-1273: --- The change only affects the pear runtime, not the pear builder. Despite what the documentation says, the pear builder adds all jars in the lib directory to the classpath it generates for the install.xml. This will only affect pear files where people have manually deleted jars from the classpath specified in the install.xml. I stand by this change, even if it may theoretically break existing pear files. > Pear runtime pulls in all jar files in pear lib directory, no matter if > they're on the classpath or not > --- > > Key: UIMA-1273 > URL: https://issues.apache.org/jira/browse/UIMA-1273 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.2.2 >Reporter: Thilo Goetz > Fix For: 2.3 > > > The pear runtime will not only use the classpath as defined in > metadata/install.xml, it will also pick up any jar in the lib directory. It > even recurses down into subdirectories. This is undocumented, and most > unexpected. > I chatted with Michael about this. He thinks it may be because the same code > that creates the classpath in the pear packager is used in the runtime. The > packager does collect all jar files it can find and puts them in the > classpath, and the pear file. That's fine for the packager, but not the > runtime. We should *either* have an explicit classpath, *or* use all jar > files in the lib dir, but not both. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CPM test case hang
Works fine with UIMA 2.2.2. I guess it's time to nuke the maven repo, do a clean extract from svn and see what happens. And do a reboot in the bargain :-) --Thilo Thilo Goetz wrote: > Jaroslaw Cwiklik wrote: >> I've applied a patch to VinciCasProcessorDeployer.java. Build with a version >> before the patch was applied and see if this problem goes away. > > No luck. I went back as far as I could so it would still compile, > and still had the same problem. I guess the next thing to do would > be to try our last release on that machine with that jvm and see > if I have the same issue. I'll do that when I have time. > > --Thilo > >> JC >> >> On Fri, Sep 4, 2009 at 11:44 AM, Thilo Goetz wrote: >> >>> Jaroslaw Cwiklik wrote: >>>> Ran on the command line multiple times with IBM 1.5 and Sun's 1.5 and no >>>> hang. >>> Yes, I can't reproduce it either on my laptop. Same code level, >>> same jvm, both dual core processors, same maven version even. Still >>> hangs reliably on my workstation, though. Some subtle synchronization >>> issue, undoubtedly. Let me know if you want me to go back to an >>> earlier code level and try there, or if there's anything else I can >>> do to help. >>> >>> --Thilo >>> >>>> JC >>>> >>>> On Fri, Sep 4, 2009 at 10:26 AM, Thilo Goetz wrote: >>>> >>>>> Jaroslaw Cwiklik wrote: >>>>>> Thilo, I've tried IBM's 1.5.8 and Sun's 1.5 and I cant recreate the >>> hang. >>>>> I >>>>>> run the test cases in eclipse. Is anyone else having this problem? >>>>> Please try it on the command line, that's where I had the problem. >>>>> >>>>> --Thilo >>>>> >>>>>> Jerry >>>>>> >>>>>> On Thu, Sep 3, 2009 at 9:19 AM, Jaroslaw Cwiklik >>>>> wrote: >>>>>>> Thilo, recently I applied a patch attached to JIRA UIMA-1304. I only >>>>> tested >>>>>>> this with JDK1.6. I will look into this today. >>>>>>> >>>>>>> Jerry >>>>>>> >>>>>>> >>>>>>> On Thu, Sep 3, 2009 at 5:00 AM, Thilo Goetz wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> has anything changed in the CPM recently? I get >>>>>>>> a reliable test case hang here (no cpu activity): >>>>>>>> >>>>>>>> --- >>>>>>>> T E S T S >>>>>>>> --- >>>>>>>> Running org.apache.uima.collection.impl.cpm.CpmProcessingTest >>>>>>>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.344 >>>>> sec >>>>>>>> Running org.apache.uima.collection.impl.cpm.CasPoolTest >>>>>>>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.125 >>>>> sec >>>>>>>> Running org.apache.uima.collection.impl.cpm.CpmInitTest >>>>>>>> Initialize was called: true >>>>>>>> Sep 3, 2009 10:50:48 AM >>> org.apache.uima.collection.impl.cpm.BaseCPMImpl >>>>>>>> process >>>>>>>> WARNING: Processing the request to stop the CPM. (Thread Name: main) >>>>>>>> Sep 3, 2009 10:50:48 AM >>>>>>>> org.apache.uima.collection.impl.cpm.engine.CPMEngine process >>>>>>>> INFO: The collection reader thread state is: 2007 (Thread Name: main) >>>>>>>> >>>>>>>> I have to kill the process, so I don't have more info than this. >>>>>>>> It only happens with this jvm (on windows): >>>>>>>> >>>>>>>> java version "1.5.0" >>>>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>>> pwi32dev-20090707 >>>>>>>> (SR10 )) >>>>>>>> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 >>>>>>>> j9vmwi3223-20090707 (JIT enabled) >>>>>>>> J9VM - 20090706_38445_lHdSMr >>>>>>>> JIT - 20090623_1334_r8 >>>>>>>> GC - 200906_09) >>>>>>>> JCL - 20090705 >>>>>>>> >>>>>>>> I tried 3 others, and it goes through with all of them: >>>>>>>> >>>>>>>> java version "1.6.0" >>>>>>>> Java(TM) SE Runtime Environment (build pwi3260sr5-20090529_04(SR5)) >>>>>>>> IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 >>>>>>>> jvmwi3260sr5-20090519_35743 (JIT enabled, AOT enabled) >>>>>>>> J9VM - 20090519_035743_lHdSMr >>>>>>>> JIT - r9_20090518_2017 >>>>>>>> GC - 20090417_AA) >>>>>>>> JCL - 20090529_01 >>>>>>>> >>>>>>>> java version "1.5.0_11" >>>>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) >>>>>>>> Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode) >>>>>>>> >>>>>>>> java version "1.6.0_13" >>>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_13-b03) >>>>>>>> Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode) >>>>>>>> >>>>>>>> Let me know if you need more information. >>>>>>>> >>>>>>>> --Thilo >>>>>>>>
Re: CPM test case hang
Jaroslaw Cwiklik wrote: > I've applied a patch to VinciCasProcessorDeployer.java. Build with a version > before the patch was applied and see if this problem goes away. No luck. I went back as far as I could so it would still compile, and still had the same problem. I guess the next thing to do would be to try our last release on that machine with that jvm and see if I have the same issue. I'll do that when I have time. --Thilo > > JC > > On Fri, Sep 4, 2009 at 11:44 AM, Thilo Goetz wrote: > >> Jaroslaw Cwiklik wrote: >>> Ran on the command line multiple times with IBM 1.5 and Sun's 1.5 and no >>> hang. >> Yes, I can't reproduce it either on my laptop. Same code level, >> same jvm, both dual core processors, same maven version even. Still >> hangs reliably on my workstation, though. Some subtle synchronization >> issue, undoubtedly. Let me know if you want me to go back to an >> earlier code level and try there, or if there's anything else I can >> do to help. >> >> --Thilo >> >>> JC >>> >>> On Fri, Sep 4, 2009 at 10:26 AM, Thilo Goetz wrote: >>> >>>> Jaroslaw Cwiklik wrote: >>>>> Thilo, I've tried IBM's 1.5.8 and Sun's 1.5 and I cant recreate the >> hang. >>>> I >>>>> run the test cases in eclipse. Is anyone else having this problem? >>>> Please try it on the command line, that's where I had the problem. >>>> >>>> --Thilo >>>> >>>>> Jerry >>>>> >>>>> On Thu, Sep 3, 2009 at 9:19 AM, Jaroslaw Cwiklik >>>> wrote: >>>>>> Thilo, recently I applied a patch attached to JIRA UIMA-1304. I only >>>> tested >>>>>> this with JDK1.6. I will look into this today. >>>>>> >>>>>> Jerry >>>>>> >>>>>> >>>>>> On Thu, Sep 3, 2009 at 5:00 AM, Thilo Goetz wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> has anything changed in the CPM recently? I get >>>>>>> a reliable test case hang here (no cpu activity): >>>>>>> >>>>>>> --- >>>>>>> T E S T S >>>>>>> --- >>>>>>> Running org.apache.uima.collection.impl.cpm.CpmProcessingTest >>>>>>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.344 >>>> sec >>>>>>> Running org.apache.uima.collection.impl.cpm.CasPoolTest >>>>>>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.125 >>>> sec >>>>>>> Running org.apache.uima.collection.impl.cpm.CpmInitTest >>>>>>> Initialize was called: true >>>>>>> Sep 3, 2009 10:50:48 AM >> org.apache.uima.collection.impl.cpm.BaseCPMImpl >>>>>>> process >>>>>>> WARNING: Processing the request to stop the CPM. (Thread Name: main) >>>>>>> Sep 3, 2009 10:50:48 AM >>>>>>> org.apache.uima.collection.impl.cpm.engine.CPMEngine process >>>>>>> INFO: The collection reader thread state is: 2007 (Thread Name: main) >>>>>>> >>>>>>> I have to kill the process, so I don't have more info than this. >>>>>>> It only happens with this jvm (on windows): >>>>>>> >>>>>>> java version "1.5.0" >>>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >>>> pwi32dev-20090707 >>>>>>> (SR10 )) >>>>>>> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 >>>>>>> j9vmwi3223-20090707 (JIT enabled) >>>>>>> J9VM - 20090706_38445_lHdSMr >>>>>>> JIT - 20090623_1334_r8 >>>>>>> GC - 200906_09) >>>>>>> JCL - 20090705 >>>>>>> >>>>>>> I tried 3 others, and it goes through with all of them: >>>>>>> >>>>>>> java version "1.6.0" >>>>>>> Java(TM) SE Runtime Environment (build pwi3260sr5-20090529_04(SR5)) >>>>>>> IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 >>>>>>> jvmwi3260sr5-20090519_35743 (JIT enabled, AOT enabled) >>>>>>> J9VM - 20090519_035743_lHdSMr >>>>>>> JIT - r9_20090518_2017 >>>>>>> GC - 20090417_AA) >>>>>>> JCL - 20090529_01 >>>>>>> >>>>>>> java version "1.5.0_11" >>>>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) >>>>>>> Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode) >>>>>>> >>>>>>> java version "1.6.0_13" >>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_13-b03) >>>>>>> Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode) >>>>>>> >>>>>>> Let me know if you need more information. >>>>>>> >>>>>>> --Thilo >>>>>>> >> >
[jira] Assigned: (UIMA-1546) Fix sandbox notice and license files
[ https://issues.apache.org/jira/browse/UIMA-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thilo Goetz reassigned UIMA-1546: - Assignee: (was: Thilo Goetz) I have checked all sandbox projects that will go into the next release and updated all notice and license files except the CFE. I won't have time to do that, so somebody else please take over. Look at the BSF and Tika annotators for role models. I have also created top-level notice and license files for the sandbox. These will need to be updated with the outstanding changes to the CFE. > Fix sandbox notice and license files > > > Key: UIMA-1546 > URL: https://issues.apache.org/jira/browse/UIMA-1546 > Project: UIMA > Issue Type: Bug > Components: Sandbox > Reporter: Thilo Goetz > Fix For: 2.3S > > > Review all sandbox notice and license files. Make sure top-level notice and > license files are aggregates of the component ones. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CPM test case hang
Jaroslaw Cwiklik wrote: > Ran on the command line multiple times with IBM 1.5 and Sun's 1.5 and no > hang. Yes, I can't reproduce it either on my laptop. Same code level, same jvm, both dual core processors, same maven version even. Still hangs reliably on my workstation, though. Some subtle synchronization issue, undoubtedly. Let me know if you want me to go back to an earlier code level and try there, or if there's anything else I can do to help. --Thilo > > JC > > On Fri, Sep 4, 2009 at 10:26 AM, Thilo Goetz wrote: > >> Jaroslaw Cwiklik wrote: >>> Thilo, I've tried IBM's 1.5.8 and Sun's 1.5 and I cant recreate the hang. >> I >>> run the test cases in eclipse. Is anyone else having this problem? >> Please try it on the command line, that's where I had the problem. >> >> --Thilo >> >>> Jerry >>> >>> On Thu, Sep 3, 2009 at 9:19 AM, Jaroslaw Cwiklik >> wrote: >>>> Thilo, recently I applied a patch attached to JIRA UIMA-1304. I only >> tested >>>> this with JDK1.6. I will look into this today. >>>> >>>> Jerry >>>> >>>> >>>> On Thu, Sep 3, 2009 at 5:00 AM, Thilo Goetz wrote: >>>> >>>>> Hi all, >>>>> >>>>> has anything changed in the CPM recently? I get >>>>> a reliable test case hang here (no cpu activity): >>>>> >>>>> --- >>>>> T E S T S >>>>> --- >>>>> Running org.apache.uima.collection.impl.cpm.CpmProcessingTest >>>>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.344 >> sec >>>>> Running org.apache.uima.collection.impl.cpm.CasPoolTest >>>>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.125 >> sec >>>>> Running org.apache.uima.collection.impl.cpm.CpmInitTest >>>>> Initialize was called: true >>>>> Sep 3, 2009 10:50:48 AM org.apache.uima.collection.impl.cpm.BaseCPMImpl >>>>> process >>>>> WARNING: Processing the request to stop the CPM. (Thread Name: main) >>>>> Sep 3, 2009 10:50:48 AM >>>>> org.apache.uima.collection.impl.cpm.engine.CPMEngine process >>>>> INFO: The collection reader thread state is: 2007 (Thread Name: main) >>>>> >>>>> I have to kill the process, so I don't have more info than this. >>>>> It only happens with this jvm (on windows): >>>>> >>>>> java version "1.5.0" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build >> pwi32dev-20090707 >>>>> (SR10 )) >>>>> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 >>>>> j9vmwi3223-20090707 (JIT enabled) >>>>> J9VM - 20090706_38445_lHdSMr >>>>> JIT - 20090623_1334_r8 >>>>> GC - 200906_09) >>>>> JCL - 20090705 >>>>> >>>>> I tried 3 others, and it goes through with all of them: >>>>> >>>>> java version "1.6.0" >>>>> Java(TM) SE Runtime Environment (build pwi3260sr5-20090529_04(SR5)) >>>>> IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 >>>>> jvmwi3260sr5-20090519_35743 (JIT enabled, AOT enabled) >>>>> J9VM - 20090519_035743_lHdSMr >>>>> JIT - r9_20090518_2017 >>>>> GC - 20090417_AA) >>>>> JCL - 20090529_01 >>>>> >>>>> java version "1.5.0_11" >>>>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) >>>>> Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode) >>>>> >>>>> java version "1.6.0_13" >>>>> Java(TM) SE Runtime Environment (build 1.6.0_13-b03) >>>>> Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode) >>>>> >>>>> Let me know if you need more information. >>>>> >>>>> --Thilo >>>>> >> >
Re: [jira] Created: (UIMA-1554) Fix CFE notice and license file
Thilo Goetz (JIRA) wrote: > Fix CFE notice and license file > --- > > Key: UIMA-1554 > URL: https://issues.apache.org/jira/browse/UIMA-1554 > Project: UIMA > Issue Type: Bug > Components: Sandbox-CFE > Reporter: Thilo Goetz > Fix For: 2.3S > > > The CFE notice and license file only contains Apache boilerplate. I see some > eclipse stuff being pulled in. Need to check all dependencies that we > distribute. For each dependency, check if it requires one or more > attributions in the NOTICE file. For each dependency, list it together with > its license in the LICENSE file. > I won't have time to fix this. It needs to be taken care of before the release. --Thilo
[jira] Created: (UIMA-1554) Fix CFE notice and license file
Fix CFE notice and license file --- Key: UIMA-1554 URL: https://issues.apache.org/jira/browse/UIMA-1554 Project: UIMA Issue Type: Bug Components: Sandbox-CFE Reporter: Thilo Goetz Fix For: 2.3S The CFE notice and license file only contains Apache boilerplate. I see some eclipse stuff being pulled in. Need to check all dependencies that we distribute. For each dependency, check if it requires one or more attributions in the NOTICE file. For each dependency, list it together with its license in the LICENSE file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CPM test case hang
Jaroslaw Cwiklik wrote: > Thilo, I've tried IBM's 1.5.8 and Sun's 1.5 and I cant recreate the hang. I > run the test cases in eclipse. Is anyone else having this problem? Please try it on the command line, that's where I had the problem. --Thilo > > Jerry > > On Thu, Sep 3, 2009 at 9:19 AM, Jaroslaw Cwiklik wrote: > >> Thilo, recently I applied a patch attached to JIRA UIMA-1304. I only tested >> this with JDK1.6. I will look into this today. >> >> Jerry >> >> >> On Thu, Sep 3, 2009 at 5:00 AM, Thilo Goetz wrote: >> >>> Hi all, >>> >>> has anything changed in the CPM recently? I get >>> a reliable test case hang here (no cpu activity): >>> >>> --- >>> T E S T S >>> --- >>> Running org.apache.uima.collection.impl.cpm.CpmProcessingTest >>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.344 sec >>> Running org.apache.uima.collection.impl.cpm.CasPoolTest >>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.125 sec >>> Running org.apache.uima.collection.impl.cpm.CpmInitTest >>> Initialize was called: true >>> Sep 3, 2009 10:50:48 AM org.apache.uima.collection.impl.cpm.BaseCPMImpl >>> process >>> WARNING: Processing the request to stop the CPM. (Thread Name: main) >>> Sep 3, 2009 10:50:48 AM >>> org.apache.uima.collection.impl.cpm.engine.CPMEngine process >>> INFO: The collection reader thread state is: 2007 (Thread Name: main) >>> >>> I have to kill the process, so I don't have more info than this. >>> It only happens with this jvm (on windows): >>> >>> java version "1.5.0" >>> Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20090707 >>> (SR10 )) >>> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 >>> j9vmwi3223-20090707 (JIT enabled) >>> J9VM - 20090706_38445_lHdSMr >>> JIT - 20090623_1334_r8 >>> GC - 200906_09) >>> JCL - 20090705 >>> >>> I tried 3 others, and it goes through with all of them: >>> >>> java version "1.6.0" >>> Java(TM) SE Runtime Environment (build pwi3260sr5-20090529_04(SR5)) >>> IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 >>> jvmwi3260sr5-20090519_35743 (JIT enabled, AOT enabled) >>> J9VM - 20090519_035743_lHdSMr >>> JIT - r9_20090518_2017 >>> GC - 20090417_AA) >>> JCL - 20090529_01 >>> >>> java version "1.5.0_11" >>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) >>> Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode) >>> >>> java version "1.6.0_13" >>> Java(TM) SE Runtime Environment (build 1.6.0_13-b03) >>> Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode) >>> >>> Let me know if you need more information. >>> >>> --Thilo >>> >> >
[jira] Commented: (UIMA-1462) SimpleUimaAsService has checked in SimpleServer libraries as binaries
[ https://issues.apache.org/jira/browse/UIMA-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12751407#action_12751407 ] Thilo Goetz commented on UIMA-1462: --- The simple server tests currently do not work with a Sun 1.5 java. Should work with any 1.6 though. > SimpleUimaAsService has checked in SimpleServer libraries as binaries > - > > Key: UIMA-1462 > URL: https://issues.apache.org/jira/browse/UIMA-1462 > Project: UIMA > Issue Type: Bug > Components: Sandbox-SimpleUimaAsService >Affects Versions: 2.2.2S, 2.3S >Reporter: Thilo Goetz >Assignee: Tommaso Teofili > Fix For: 2.3S > > Attachments: patch1462.txt, patch1462b1.txt, patch1462b2.txt, > patch1462c1.txt, patch1462c2.txt, simpleServerDistributionPatch.txt, > simpleUimaAsServicePatch.txt > > > For the upcoming release, this should be changed so it depends on the > SimpleServer project directly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (UIMA-1535) Lucas POM issues
[
https://issues.apache.org/jira/browse/UIMA-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thilo Goetz reopened UIMA-1535:
---
This patch seems to have done a little too much clean-up. The lib directory of
the pear file is now empty. When I go back to Joern's latest revision, the
pear looks ok (though I did not install and run it).
> Lucas POM issues
>
>
> Key: UIMA-1535
> URL: https://issues.apache.org/jira/browse/UIMA-1535
> Project: UIMA
> Issue Type: Bug
> Components: Sandbox-Lucas
>Reporter: Marshall Schor
>Assignee: Rico Landefeld
>Priority: Minor
> Attachments: UIMA-1535.patch
>
>
> Some issues to resolve for the Lucas POM
> 1) it specifies in distributionManagement
> scp://login.coling.uni-jena.de/var/lib/maven/coling
> This looks like it might left over from its life elsewhere. I think the
> distributionManagement element should be deleted.
> 2) factor out ant executions for copying standard stuff - done in parent
> 3) There is a section of the POM specifying actions for the phase "site".
> We currently do not run a mvn site lifecycle as part of our build process, so
> I think this will never execute. Its purpose is to copy to the
> ${project.build.directory}/site/downloads the downloadable artifacts: the jar
> and the pear.
> I think we can leave this in as a comment reminding us in the future if we go
> to individually downloadable things from our main website, how we might want
> to do this.
> 4) There is an execution in the Ant-run for building the pear directories
> that will be bound up with the pear. This adds
> * doc/ with a copy of the generated html and pdf from the docbook sources,
> Should these be included in the PEAR? They are already included in the
> binary distribution of the Sandbox.
> * doc/downloads with 2 files: the lucas.xsd, and a sample CasConsumer
> descriptor. Do these belong in the PEAR? They are already included in the
> src and binary distribution of the Sandbox
> * resources dir for the PEAR is populated with the contents of
> src/test/resources. This seems a bit unusual - why are the test resources
> being included in the PEAR?
> 5) The PearPackagingMavenPlugin is setting a classpath that includes
> * $main_root/lib/cglib-nodep-2.1_3.jar - but this jar is not present. What
> is it? can this be deleted?
> * $main_root/lib/google-collect-snapshot-20080530.jar
> * $main_root/lib/log4j-1.2.14.jar
> * $main_root/lib/lucene-core-2.4.0.jar - needs updating to proper level
> * $main_root/lib/lucene-snowball-2.4.0.jar
> These need updating to proper level, which is no level since the level was
> stripped from the /lib
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (UIMA-1552) Lucas: does not compile with Java 1.5
Thilo Goetz (JIRA) wrote: > Lucas: does not compile with Java 1.5 > - > > Key: UIMA-1552 > URL: https://issues.apache.org/jira/browse/UIMA-1552 > Project: UIMA > Issue Type: Bug > Components: Sandbox-Lucas > Reporter: Thilo Goetz > Assignee: Thilo Goetz > Fix For: 2.3S > > > Lucas uses IOException constructors that are not in Java 1.5. > This reminds me: Marshall, please remember to build our release with Java 1.5. Otherwise people may not be able to run our binaries with 1.5. Thanks. --Thilo
[jira] Closed: (UIMA-1552) Lucas: does not compile with Java 1.5
[ https://issues.apache.org/jira/browse/UIMA-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thilo Goetz closed UIMA-1552. - Resolution: Fixed Changes are minor. Rico, you may want to review them anyway. > Lucas: does not compile with Java 1.5 > - > > Key: UIMA-1552 > URL: https://issues.apache.org/jira/browse/UIMA-1552 > Project: UIMA > Issue Type: Bug > Components: Sandbox-Lucas > Reporter: Thilo Goetz > Assignee: Thilo Goetz > Fix For: 2.3S > > > Lucas uses IOException constructors that are not in Java 1.5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Lucas NOTICE file
Rico Landefeld wrote: > I don't agree. There are also NotNullPredicates used in the > AnnotationTokenStream class, which avoid null checks of iterator > values. This is a really nice feature to clean up the code because > iterators are heavily used in this class. > > Rico I don't care either way. I'll update the notice file to be correct for the current version of Lucas, i.e., with the google collections stuff. If at some future point we decide to do without it, we'll just have to remember to take the mention out of the notice file. --Thilo > > On Thu, Sep 3, 2009 at 5:13 PM, Marshall Schor wrote: >> >> Thilo Goetz wrote: >>> The NOTICE file for Lucas currently does not list any >>> external dependencies. However, looking at Lucas after >>> it's been built, it seems to me we'll be shipping the >>> google-collections.jar. Is that correct? We ship >>> everything that ends up in lib, and nothing else? >>> >> I think so. There's already a Jira issue for fixing this: >> http://issues.apache.org/jira/browse/UIMA-1534 " >> >> >> Lucas build puts third-party jars into lib dir - need to review >> Licenses and update Notices for these" >> >> The Jira notes there are other things besides google collections: >> including lucene-snowball and lucene-core. >> >> -Marshall >> >>> Thanks, >>> Thilo >>> >>> >>>
[jira] Created: (UIMA-1552) Lucas: does not compile with Java 1.5
Lucas: does not compile with Java 1.5 - Key: UIMA-1552 URL: https://issues.apache.org/jira/browse/UIMA-1552 Project: UIMA Issue Type: Bug Components: Sandbox-Lucas Reporter: Thilo Goetz Assignee: Thilo Goetz Fix For: 2.3S Lucas uses IOException constructors that are not in Java 1.5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (UIMA-1535) Lucas POM issues
[
https://issues.apache.org/jira/browse/UIMA-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thilo Goetz resolved UIMA-1535.
---
Resolution: Fixed
Assignee: Rico Landefeld (was: Thilo Goetz)
Patch applied, thanks Rico. Please verify and close issue.
> Lucas POM issues
>
>
> Key: UIMA-1535
> URL: https://issues.apache.org/jira/browse/UIMA-1535
> Project: UIMA
> Issue Type: Bug
> Components: Sandbox-Lucas
>Reporter: Marshall Schor
>Assignee: Rico Landefeld
>Priority: Minor
> Attachments: UIMA-1535.patch
>
>
> Some issues to resolve for the Lucas POM
> 1) it specifies in distributionManagement
> scp://login.coling.uni-jena.de/var/lib/maven/coling
> This looks like it might left over from its life elsewhere. I think the
> distributionManagement element should be deleted.
> 2) factor out ant executions for copying standard stuff - done in parent
> 3) There is a section of the POM specifying actions for the phase "site".
> We currently do not run a mvn site lifecycle as part of our build process, so
> I think this will never execute. Its purpose is to copy to the
> ${project.build.directory}/site/downloads the downloadable artifacts: the jar
> and the pear.
> I think we can leave this in as a comment reminding us in the future if we go
> to individually downloadable things from our main website, how we might want
> to do this.
> 4) There is an execution in the Ant-run for building the pear directories
> that will be bound up with the pear. This adds
> * doc/ with a copy of the generated html and pdf from the docbook sources,
> Should these be included in the PEAR? They are already included in the
> binary distribution of the Sandbox.
> * doc/downloads with 2 files: the lucas.xsd, and a sample CasConsumer
> descriptor. Do these belong in the PEAR? They are already included in the
> src and binary distribution of the Sandbox
> * resources dir for the PEAR is populated with the contents of
> src/test/resources. This seems a bit unusual - why are the test resources
> being included in the PEAR?
> 5) The PearPackagingMavenPlugin is setting a classpath that includes
> * $main_root/lib/cglib-nodep-2.1_3.jar - but this jar is not present. What
> is it? can this be deleted?
> * $main_root/lib/google-collect-snapshot-20080530.jar
> * $main_root/lib/log4j-1.2.14.jar
> * $main_root/lib/lucene-core-2.4.0.jar - needs updating to proper level
> * $main_root/lib/lucene-snowball-2.4.0.jar
> These need updating to proper level, which is no level since the level was
> stripped from the /lib
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (UIMA-1535) Lucas POM issues
Jörn Kottmann (JIRA) wrote:
> [
> https://issues.apache.org/jira/browse/UIMA-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12751370#action_12751370
> ]
>
> Jörn Kottmann commented on UIMA-1535:
> -
>
> I was not aware of this issue, but 1) was solved in UIMA-1550.
Sorry, our paths crossed there. I didn't see your commit. However,
no harm done I think, things are still working for me. Let me know
if I screwed up somewhere.
--Thilo
>
>> Lucas POM issues
>>
>>
>> Key: UIMA-1535
>> URL: https://issues.apache.org/jira/browse/UIMA-1535
>> Project: UIMA
>> Issue Type: Bug
>> Components: Sandbox-Lucas
>>Reporter: Marshall Schor
>>Assignee: Rico Landefeld
>>Priority: Minor
>> Attachments: UIMA-1535.patch
>>
>>
>> Some issues to resolve for the Lucas POM
>> 1) it specifies in distributionManagement
>> scp://login.coling.uni-jena.de/var/lib/maven/coling
>> This looks like it might left over from its life elsewhere. I think the
>> distributionManagement element should be deleted.
>> 2) factor out ant executions for copying standard stuff - done in parent
>> 3) There is a section of the POM specifying actions for the phase "site".
>> We currently do not run a mvn site lifecycle as part of our build process,
>> so I think this will never execute. Its purpose is to copy to the
>> ${project.build.directory}/site/downloads the downloadable artifacts: the
>> jar and the pear.
>> I think we can leave this in as a comment reminding us in the future if we
>> go to individually downloadable things from our main website, how we might
>> want to do this.
>> 4) There is an execution in the Ant-run for building the pear directories
>> that will be bound up with the pear. This adds
>> * doc/ with a copy of the generated html and pdf from the docbook sources,
>> Should these be included in the PEAR? They are already included in the
>> binary distribution of the Sandbox.
>> * doc/downloads with 2 files: the lucas.xsd, and a sample CasConsumer
>> descriptor. Do these belong in the PEAR? They are already included in the
>> src and binary distribution of the Sandbox
>> * resources dir for the PEAR is populated with the contents of
>> src/test/resources. This seems a bit unusual - why are the test resources
>> being included in the PEAR?
>> 5) The PearPackagingMavenPlugin is setting a classpath that includes
>> * $main_root/lib/cglib-nodep-2.1_3.jar - but this jar is not present. What
>> is it? can this be deleted?
>> * $main_root/lib/google-collect-snapshot-20080530.jar
>> * $main_root/lib/log4j-1.2.14.jar
>> * $main_root/lib/lucene-core-2.4.0.jar - needs updating to proper level
>> * $main_root/lib/lucene-snowball-2.4.0.jar
>> These need updating to proper level, which is no level since the level was
>> stripped from the /lib
>
Re: [jira] Created: (UIMA-1551) Lucas PearPackagingMavenPlugin PEAR classpath is incorrect
Jörn Kottmann wrote: > Jörn Kottmann (JIRA) wrote: >> Lucas PearPackagingMavenPlugin PEAR classpath is incorrect >> -- >> >> Key: UIMA-1551 >> URL: https://issues.apache.org/jira/browse/UIMA-1551 >> Project: UIMA >> Issue Type: Bug >> Components: Sandbox-Lucas >> Reporter: Jörn Kottmann >> Assignee: Rico Landefeld >> Fix For: 2.3S >> >> >> The classpath entry says currently: >> >> >> $main_root/lib/cglib-nodep-2.1_3.jar;$main_root/lib/google-collect-snapshot-20080530.jar;$main_root/lib/log4j-1.2.14.jar;$main_root/lib/lucene-core-2.4.0.jar;$main_root/lib/lucene-snowball-2.4.0.jar >> >> >> >> Which is incorrect because, Lucas does not depend anymore on the >> google-collections snapshot and lucene 2.4.0. >> >> > Maybe we should consider opening a jira issue to improve the > PearPackagingMavenPlugin > to automatically create the classpath. > > Jörn +1, that would be great. The dual maintenance of classpaths in pear projects is a constant source of errors. --Thilo
[jira] Closed: (UIMA-1550) Remove the uni-jena.de repository from lucas pom
[ https://issues.apache.org/jira/browse/UIMA-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thilo Goetz closed UIMA-1550. - Resolution: Fixed Fixed with https://issues.apache.org/jira/browse/UIMA-1535. > Remove the uni-jena.de repository from lucas pom > > > Key: UIMA-1550 > URL: https://issues.apache.org/jira/browse/UIMA-1550 > Project: UIMA > Issue Type: Improvement > Components: Sandbox-Lucas >Reporter: Jörn Kottmann >Assignee: Jörn Kottmann >Priority: Trivial > Fix For: 2.3S > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1551) Lucas PearPackagingMavenPlugin PEAR classpath is incorrect
[ https://issues.apache.org/jira/browse/UIMA-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thilo Goetz closed UIMA-1551. - Resolution: Fixed Fixed with https://issues.apache.org/jira/browse/UIMA-1535. > Lucas PearPackagingMavenPlugin PEAR classpath is incorrect > -- > > Key: UIMA-1551 > URL: https://issues.apache.org/jira/browse/UIMA-1551 > Project: UIMA > Issue Type: Bug > Components: Sandbox-Lucas >Reporter: Jörn Kottmann >Assignee: Rico Landefeld > Fix For: 2.3S > > > The classpath entry says currently: > > > $main_root/lib/cglib-nodep-2.1_3.jar;$main_root/lib/google-collect-snapshot-20080530.jar;$main_root/lib/log4j-1.2.14.jar;$main_root/lib/lucene-core-2.4.0.jar;$main_root/lib/lucene-snowball-2.4.0.jar > > Which is incorrect because, Lucas does not depend anymore on the > google-collections snapshot and lucene 2.4.0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-1535) Lucas POM issues
[
https://issues.apache.org/jira/browse/UIMA-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thilo Goetz reassigned UIMA-1535:
-
Assignee: Thilo Goetz (was: Marshall Schor)
> Lucas POM issues
>
>
> Key: UIMA-1535
> URL: https://issues.apache.org/jira/browse/UIMA-1535
> Project: UIMA
> Issue Type: Bug
> Components: Sandbox-Lucas
>Reporter: Marshall Schor
> Assignee: Thilo Goetz
>Priority: Minor
> Attachments: UIMA-1535.patch
>
>
> Some issues to resolve for the Lucas POM
> 1) it specifies in distributionManagement
> scp://login.coling.uni-jena.de/var/lib/maven/coling
> This looks like it might left over from its life elsewhere. I think the
> distributionManagement element should be deleted.
> 2) factor out ant executions for copying standard stuff - done in parent
> 3) There is a section of the POM specifying actions for the phase "site".
> We currently do not run a mvn site lifecycle as part of our build process, so
> I think this will never execute. Its purpose is to copy to the
> ${project.build.directory}/site/downloads the downloadable artifacts: the jar
> and the pear.
> I think we can leave this in as a comment reminding us in the future if we go
> to individually downloadable things from our main website, how we might want
> to do this.
> 4) There is an execution in the Ant-run for building the pear directories
> that will be bound up with the pear. This adds
> * doc/ with a copy of the generated html and pdf from the docbook sources,
> Should these be included in the PEAR? They are already included in the
> binary distribution of the Sandbox.
> * doc/downloads with 2 files: the lucas.xsd, and a sample CasConsumer
> descriptor. Do these belong in the PEAR? They are already included in the
> src and binary distribution of the Sandbox
> * resources dir for the PEAR is populated with the contents of
> src/test/resources. This seems a bit unusual - why are the test resources
> being included in the PEAR?
> 5) The PearPackagingMavenPlugin is setting a classpath that includes
> * $main_root/lib/cglib-nodep-2.1_3.jar - but this jar is not present. What
> is it? can this be deleted?
> * $main_root/lib/google-collect-snapshot-20080530.jar
> * $main_root/lib/log4j-1.2.14.jar
> * $main_root/lib/lucene-core-2.4.0.jar - needs updating to proper level
> * $main_root/lib/lucene-snowball-2.4.0.jar
> These need updating to proper level, which is no level since the level was
> stripped from the /lib
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (UIMA-1462) SimpleUimaAsService has checked in SimpleServer libraries as binaries
[ https://issues.apache.org/jira/browse/UIMA-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thilo Goetz reopened UIMA-1462: --- Tommaso, could you check that again? With the current version, the simple server has test case failures (strange error messages that must have to do with classpath issues). I need to go back to revision 807268 to make it work for me. Does mvn install go through for you? > SimpleUimaAsService has checked in SimpleServer libraries as binaries > - > > Key: UIMA-1462 > URL: https://issues.apache.org/jira/browse/UIMA-1462 > Project: UIMA > Issue Type: Bug > Components: Sandbox-SimpleUimaAsService >Affects Versions: 2.2.2S, 2.3S > Reporter: Thilo Goetz >Assignee: Tommaso Teofili > Fix For: 2.3S > > Attachments: patch1462.txt, patch1462b1.txt, patch1462b2.txt, > patch1462c1.txt, patch1462c2.txt, simpleServerDistributionPatch.txt, > simpleUimaAsServicePatch.txt > > > For the upcoming release, this should be changed so it depends on the > SimpleServer project directly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Lucas NOTICE file
The NOTICE file for Lucas currently does not list any external dependencies. However, looking at Lucas after it's been built, it seems to me we'll be shipping the google-collections.jar. Is that correct? We ship everything that ends up in lib, and nothing else? Thanks, Thilo
Re: [jira] Closed: (UIMA-1548) Include LICENSE/NOTICE/DISCLAIMER files from local sources ahead of common sources
Marshall Schor (JIRA) wrote: > [ > https://issues.apache.org/jira/browse/UIMA-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Marshall Schor closed UIMA-1548. > > > Resolution: Fixed > >> Include LICENSE/NOTICE/DISCLAIMER files from local sources ahead of common >> sources >> -- >> >> Key: UIMA-1548 >> URL: https://issues.apache.org/jira/browse/UIMA-1548 >> Project: UIMA >> Issue Type: Bug >> Components: Build, Packaging and Test >>Reporter: Marshall Schor >>Assignee: Marshall Schor >> Fix For: 2.3 >> >> >> Some of our sub-projects, e.g., the ones in the Sandbox, have individual >> LICENSE/NOTICE/DISCLAIMER files, that may differ from the common ones for >> the project because the sub-projects have particular other things they're >> distributing. >> Change the antrun configuration to use these in preference to the common >> ones. >> Also, change this to support alternate names for these - some of our >> projects use a suffix of ".txt", others don't. > We use no suffix in the core, and that seems to be the preferred Apache way. Should I just change all sandbox LICENSE/NOTICE/DISCLAIMER files not to use an extension? I'm in there anyway. --Thilo
Re: Compiling project in sandbox (was: Can we update the version of Tika in the TikaAnnotator to 0.4)
Marshall Schor wrote: > > Thilo Goetz wrote: >> Marshall Schor wrote: [...] >>> >>> So, all you have to do is build the uimaj POM and install it to your >>> local repository. (Note that after things are released, any user would >>> automatically get the parent POM downloaded from the release >>> repositories, assuming they had maven set up to find these repositories). >>> >> Doesn't work for me. I do "mvn install" in the core, and I >> still have to manually copy over the uimaj project (or maybe >> just the pom, I never tried that) to build the sandbox. Is >> there another incantation I need to utter for this to work? >> > Hmmm. Here's my guess: > > 1) the mvn install does "work", but > > 2) there are *other* dependencies that use relative paths. It would be > great if someone tried this and reported exactly what the errors are... > then, perhaps we could solve these. You're right, I no longer get the missing parent error. Thanks for fixing that. Now the only error is: [INFO] An Ant BuildException has occurred: C:\build\uimaj-distr\src\main\readme not found. This goes away when I copy uimaj-distr, obviously. --Thilo > > I think there are some issues with copying the LIC/NOT/DISC files - > because the source is located by relative links. That might be able to > be fixed. > > I am planning to change the source directory for these files shortly > (modifying only the uimaj pom) so that > if the LIC/NOT/DISC files are found in the dir of the project being > built, those are used (useful for sandbox projects which have different > LIC/NOT/DISC files to go in their JARs), and only if they are not found > there, then the main ones for the UIMA project are used as the source. > > That may help this one issue (#2) if that's all that's left by way of > "relative" path dependencies. > > -Marshall >> >>> There is a "trick" to building the uimaj POM - if you just say "mvn >>> install" in the directory of the uimaj project, it will build, but it >>> will also build all of the base UIMA. If all you want to do is just >>> install the POM, without building all of UIMA, you can do that using the >>> -N parameter: type "mvn -N install". The -N parameter stops maven from >>> processing the submodules. >>> >>> HTH. -Marshall >>> >> >> >>
Re: svn commit: r810863 - in /incubator/uima/sandbox/trunk: SimpleServer/ SimpleServer/src/main/assembly/ SimpleUimaAsService/ SimpleUimaAsService/src/main/java/org/apache/uima/simpleserver/as/
Tommaso Teofili wrote:
> Marhsall, I am afraid, you are right, some lines have not been merged
> properly.
> Do you know how can I fix it without changing revision?
I don't think you can (not sure though).
There's no problem with creating another revision. Just
fix the problem, and commit with the same jira issue in
the comment. The transactional scope is the Jira issue,
so to speak.
--Thilo
> Tommaso
>
> 2009/9/3 Marshall Schor
>
>> Tommaso, I see some issues with this commit.
>>
>> Looking at the SimpleServer/pom.xml changes, it looks like your changes
>> undid the previous-to-yours changes, done in revision 807268. Did you
>> do that on purpose?
>>
>> -Marshall
>>
>> tomm...@apache.org wrote:
>>> Author: tommaso
>>> Date: Thu Sep 3 10:16:17 2009
>>> New Revision: 810863
>>>
>>> URL: http://svn.apache.org/viewvc?rev=810863&view=rev
>>> Log:
>>> [UIMA-1462] SimpleUimaAsService has checked in SimpleServer libraries as
>> binaries
>>> Added:
>>> incubator/uima/sandbox/trunk/SimpleServer/src/main/assembly/
>>>
>> incubator/uima/sandbox/trunk/SimpleServer/src/main/assembly/distribution.xml
>>> Modified:
>>> incubator/uima/sandbox/trunk/SimpleServer/pom.xml
>>> incubator/uima/sandbox/trunk/SimpleUimaAsService/pom.xml
>>>
>> incubator/uima/sandbox/trunk/SimpleUimaAsService/src/main/java/org/apache/uima/simpleserver/as/UimaAsSerive.java
>>> Modified: incubator/uima/sandbox/trunk/SimpleServer/pom.xml
>>> URL:
>> http://svn.apache.org/viewvc/incubator/uima/sandbox/trunk/SimpleServer/pom.xml?rev=810863&r1=810862&r2=810863&view=diff
>> ==
>>> --- incubator/uima/sandbox/trunk/SimpleServer/pom.xml (original)
>>> +++ incubator/uima/sandbox/trunk/SimpleServer/pom.xml Thu Sep 3 10:16:17
>> 2009
>>> @@ -1,103 +1,244 @@
>>> -
>>>
>>> -http://maven.apache.org/POM/4.0.0";
>>> - xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>> +
>>> +
>>> +http://maven.apache.org/POM/4.0.0"; xmlns:xsi="
>> http://www.w3.org/2001/XMLSchema-instance";
>>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/maven-v4_0_0.xsd";>
>>> 4.0.0
>>> org.apache.uima
>>> SimpleServer
>>> jar
>>> - 2.3.0-incubating-SNAPSHOT
>>> + 2.3.0-incubating-SNAPSHOT
>>> Apache UIMA Simple Server
>>> -
>>> -
>>> -org.apache.uima
>>> -SandboxDistr
>>> -2.3.0-incubating-SNAPSHOT
>>> -../SandboxDistr
>>> -
>>> -
>>> -
>>> -
>>> -
>>> - org.apache.uima
>>> - uimaj-core
>>> -
>>> -
>>> - org.apache.uima
>>> - uimaj-test-util
>>> -
>>> -
>>> - org.apache.uima
>>> - uimaj-component-test-util
>>> -
>>> -
>>> -
>>> - javax.servlet
>>> - servlet-api
>>> - 2.4
>>> -
>>> -
>>> - org.apache.uima.xmlbeans
>>> - xbean
>>> - 1.0
>>> - system
>>> - ${basedir}/lib/xbean.jar
>>> -
>>> -
>>> - org.apache.uima.xmlbeans
>>> - jsr-173-api
>>> - 1.0
>>> - system
>>> - ${basedir}/lib/jsr173_1.0_api.jar
>>> -
>>> -
>>> - org.apache.uima.xmlbeans
>>> - uima-simple-server-xbean
>>> - 1.0
>>> - system
>>> -
>> ${basedir}/lib/uima-simple-server-xbean.jar
>>> -
>>> -
>>> - junit
>>> - junit
>>> - 4.0
>>> - compile
>>> -
>>> -
>>> - org.mortbay.jetty
>>> - jetty
>>> - 6.1.8
>>> - compile
>>> -
>>> -
>>> - org.apache.httpcomponents
>>> - httpclient
>>> - 4.0-alpha2
>>> - compile
>>> -
>>> -
>>> -
>>> + http://incubator.apache.org/uima
>>> +
>>> +
>>> + org.apache.uima
>>> + uimaj-core
>>> + 2.3.0-incubating-SNAPSHOT
>>> + compile
>>> +
>>> +
>>> + org.apache.uima
>>> + uimaj-test-util
>>> + 2.3.0-incubating-SNAPSHOT
>>> + compile
>>> +
>>> +
>>> + org.apache.uima
>>> + uimaj-component-test-util
>>> + 2.3.0-incubating-SNAPSHOT
>>> + compile
>>> +
>>> +
>>> + javax.servlet
>>> + servlet-api
>>> + 2.4
>>> + compile
>>> +
>>> +
>>> + org.apache.uima.xmlbeans
>>> + uima-simple-server-xbean
>>> + 1.0
>>> + system
>>> +
>> ${basedir}/lib/uima-simple-server-xbean.jar
>>> +
>>> +
>>> + junit
>>> + junit
>>> + 4.0
>>> + test
>>> +
>>> +
>>> + org.mortbay.jetty
>>> +
[jira] Closed: (UIMA-1547) XML problems with simple server test cases
[ https://issues.apache.org/jira/browse/UIMA-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thilo Goetz closed UIMA-1547. - Resolution: Fixed Fixed for most jvms. Test cases still fail with at least one Sun Java 1.5 on windows. If that's a problem, we need to get more sophisticated when comparing xml files. > XML problems with simple server test cases > -- > > Key: UIMA-1547 > URL: https://issues.apache.org/jira/browse/UIMA-1547 > Project: UIMA > Issue Type: Bug > Components: Sandbox-SimpleServer > Reporter: Thilo Goetz >Assignee: Thilo Goetz > Fix For: 2.3S > > > Simple server test cases fail in various JVMs due to various issues with XML > generation in those JVMs. This would not be problem if we had some sort of > semantic XML comparison capability (anybody know if there is such a thing out > there?). Since we compare the files literally, little things like whitespace > and standalone="no" declarations matter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1547) XML problems with simple server test cases
XML problems with simple server test cases -- Key: UIMA-1547 URL: https://issues.apache.org/jira/browse/UIMA-1547 Project: UIMA Issue Type: Bug Components: Sandbox-SimpleServer Reporter: Thilo Goetz Assignee: Thilo Goetz Fix For: 2.3S Simple server test cases fail in various JVMs due to various issues with XML generation in those JVMs. This would not be problem if we had some sort of semantic XML comparison capability (anybody know if there is such a thing out there?). Since we compare the files literally, little things like whitespace and standalone="no" declarations matter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Compiling project in sandbox (was: Can we update the version of Tika in the TikaAnnotator to 0.4)
Marshall Schor wrote: [...] > Here's the story. > > For this release, we are planning to release uima (base), uima-as, > sandbox, and uima-cpp together as one release. > > The parent POMs were re-arranged so that the uimaj pom is now the parent > of the sandboxDistr pom. > > Parent POMs are found via 2 mechanims. One is looking them up using the > information in the element of the POM - and as you have > seen, that requires that the sandbox be located within the main uima > directory. (This perhaps unusual requirement comes from working with > Eclipse, which does not support hierarchical directories for projects). That's only true if you want to extract both the core and the sandbox from within eclipse into a single workspace. The only reason this doesn't give you svn troubles is because the eclipse svn client checks out every project individually. I like to check out things on the command line. Then you can import the projects into eclipse, all of them into the same workspace, if you want. When you want to do an update, you just need to say "svn up" on the command line, and do a refresh in eclipse. I also usually have the sandbox and core in two separate workspaces so I don't have so many projects in one workspace (yes I know what working sets are). However, for this approach to work you need to copy some resources from the core to the sandbox: uimaj and the docbook stuff. So if you update those from svn, you must not forget to copy them again. In linux, you could probably just create a link. On windows, we don't have that luxury. > > But there is another way too - maven (if it doesn't find the POM using > the relative-path link) looks up the POM using the "maven coordinates" > in the various maven repositories, starting with your local .m2 > repository. > > So, all you have to do is build the uimaj POM and install it to your > local repository. (Note that after things are released, any user would > automatically get the parent POM downloaded from the release > repositories, assuming they had maven set up to find these repositories). Doesn't work for me. I do "mvn install" in the core, and I still have to manually copy over the uimaj project (or maybe just the pom, I never tried that) to build the sandbox. Is there another incantation I need to utter for this to work? > > There is a "trick" to building the uimaj POM - if you just say "mvn > install" in the directory of the uimaj project, it will build, but it > will also build all of the base UIMA. If all you want to do is just > install the POM, without building all of UIMA, you can do that using the > -N parameter: type "mvn -N install". The -N parameter stops maven from > processing the submodules. > > HTH. -Marshall
Re: Compiling project in sandbox (was: Can we update the version of Tika in the TikaAnnotator to 0.4)
Julien Nioche wrote:
> Hi,
>
> I was having the same problem as Jorn using the default version of Maven
> from Ubuntu. I have upgraded it to 2.2.1 and can now build UIMA but still
> cannot build the TikaAnnotator.
>
> When doing svn install in the TikaAnnotator directory I am getting :
> *Reason: Cannot find parent: org.apache.uima:SandboxDistr for project:
> org.apache.uima:TikaAnnotator:jar:2.3.0-incubating-SNAPSHOT for project
> org.apache.uima:TikaAnnotator:jar:2.3.0-incubating-SNAPSHOT*
>
> I then tried to build SandboxDistr but am getting :
>
> *antrun:run {execution: CopyLicenseNoticeDisclaimer}]
> [INFO] Executing tasks
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] An Ant BuildException has occured:
> /usr/local/bin/uimaj-distr/src/main/readme not found.*
>
> whereas my uimaj-distr is actually located in a different directory (*
> /usr/local/bin/uima-svn/uimaj-distr* with the sandbox
> in*/usr/local/bin/uima-sandbox-svn
> *). Is there an implicit requirement for the sandbox to be located within
> the main UIMA directory?
Short answer: yes. For the long answer, see Marshall's note.
>
> Once the sandbox is put inside the main uima dir everything compiles OK.
>
> Thanks
>
> Julien
>
>
>
>>> Won't have time to look into this in the short term but can try at some
>>> point next week. Maybe someone with more experience of Maven can give it
>> a
>>> try first and see if it compiles OK?
>>>
>> I tried this and it compiled OK.
>> I had success with the following (requires maven to be installed):
>>
>> cd to directory TikaAnnotator
>> mvn install
>>
>> That builds it, builds any docbook documentation (there is none) and
>> runs the test cases (there are none, I think).
>>
>>
>
CPM test case hang
Hi all, has anything changed in the CPM recently? I get a reliable test case hang here (no cpu activity): --- T E S T S --- Running org.apache.uima.collection.impl.cpm.CpmProcessingTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.344 sec Running org.apache.uima.collection.impl.cpm.CasPoolTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.125 sec Running org.apache.uima.collection.impl.cpm.CpmInitTest Initialize was called: true Sep 3, 2009 10:50:48 AM org.apache.uima.collection.impl.cpm.BaseCPMImpl process WARNING: Processing the request to stop the CPM. (Thread Name: main) Sep 3, 2009 10:50:48 AM org.apache.uima.collection.impl.cpm.engine.CPMEngine process INFO: The collection reader thread state is: 2007 (Thread Name: main) I have to kill the process, so I don't have more info than this. It only happens with this jvm (on windows): java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20090707 (SR10 )) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20090707 (JIT enabled) J9VM - 20090706_38445_lHdSMr JIT - 20090623_1334_r8 GC - 200906_09) JCL - 20090705 I tried 3 others, and it goes through with all of them: java version "1.6.0" Java(TM) SE Runtime Environment (build pwi3260sr5-20090529_04(SR5)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260sr5-20090519_35743 (JIT enabled, AOT enabled) J9VM - 20090519_035743_lHdSMr JIT - r9_20090518_2017 GC - 20090417_AA) JCL - 20090529_01 java version "1.5.0_11" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode) java version "1.6.0_13" Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode) Let me know if you need more information. --Thilo
Re: Fwd: Committer info
Redirecting this thread to uima-dev, may be useful information for other people as well. Tommaso Teofili wrote: > Thanks a lot Marshall for being so helpful. > > > Recently I was reading something related to svn log, is there > > something to do related to it? > I don't think so - but maybe I'm not following... Can you be more > specific? or give a pointer? > > > in a previous email on uima-commits I saw something like: > > Author: schor > Revision: 719734 > Modified property: svn:log > > Modified: svn:log at Fri Jul 31 11:55:39 2009 > -- > > --- svn:log (original) > +++ svn:log Fri Jul 31 11:55:39 2009 > @@ -1 +1 @@ > > .. > > > > Tommaso That just means that the commit log was modified after the fact. If you have forgotten to add a commit comment with the jira number or some other important information, you can later add that. The most important information in the commit log is, as Marshall said, the Jira issue number like UIMA-1234. This allows us to go back to Jira and look at the discussion surrounding a commit. Conversely, this number allows Jira to associate subversion commits with an issue. So you can click on the "Subversion Commits" tab in a Jira issue and see all the commits for an issue. I also like to put the URL to a Jira issue in the commit comment, because I'm lazy and this allows me to just click on the link in the commit message and I don't have to copy and paste the issue number into the Jira search field: https://issues.apache.org/jira/browse/UIMA-1234 But that's just me, it's not a general rule. --Thilo
[jira] Created: (UIMA-1546) Fix sandbox notice and license files
Fix sandbox notice and license files Key: UIMA-1546 URL: https://issues.apache.org/jira/browse/UIMA-1546 Project: UIMA Issue Type: Bug Components: Sandbox Reporter: Thilo Goetz Assignee: Thilo Goetz Fix For: 2.3S Review all sandbox notice and license files. Make sure top-level notice and license files are aggregates of the component ones. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Build error after updating to latest uimaj/pom.xml (rev. 807808)
Jörn Kottmann wrote: > Tommaso Teofili wrote: >> Hi Jorn, >> which Maven version are you using? >> > 2.0.9 on Ubuntu linux > > Jörn I'm using Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100) on windows. I think maven is at 2.2.x now? --Thilo
Re: Build error after updating to latest uimaj/pom.xml (rev. 807808)
Have you tried deleting m2 repository? I did an svn up and build yesterday, and it worked for me. --Thilo Jörn Kottmann wrote: > After updating to the newest uimaj/pom.xml file the build fails, > with the following error message: > > jo...@karkand:~/uima-dev3/uimaj$ mvn -e install > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] Apache UIMA Java SDK > [INFO] Apache UIMA Utility Classes For JUnit Tests > [INFO] Apache UIMA Java Framework Core > [INFO] Apache UIMA - Java Vinci Transport Library > [INFO] Apache UIMA Java Vinci Adapter > [INFO] Apache UIMA Java Collection Processing Engine > [INFO] Apache UIMA Java Framework - Document Annotation > [INFO] Apache UIMA Java SDK Tools > [INFO] Apache UIMA Java SDK Examples > [INFO] Apache UIMA Java SOAP Adapter > [INFO] Apache UIMA Utility Classes For Component JUnit Tests > [INFO] Apache UIMA Java SDK common Eclipse plugin settings > [INFO] Apache UIMA Debug Eclipse Plugin > [INFO] Apache UIMA JCasGen Eclipse Plugin > [INFO] Apache UIMA Configurator Eclipse Plugin > [INFO] Apache UIMA PEAR Packager Eclipse Plugin > [INFO] Apache UIMA Cas Editor Eclipse Plugin > [INFO] Apache UIMA Runtime Plugin > [INFO] Apache UIMA - PearPackagingMavenPlugin > [INFO] Apache UIMA internal Tools > [INFO] > > [INFO] Building Apache UIMA Java SDK > [INFO]task-segment: [install] > [INFO] > > [FATAL ERROR] > org.codehaus.plexus.component.configurator.BasicComponentConfigurator#configureComponent(...) > caused a linkage error (java.lang.NoSuchMethodError) and may be > out-of-date. Check the realms: > [FATAL ERROR] Plugin realm = > app0.child-container[org.apache.maven.plugins:maven-antrun-plugin] > urls[0] = > file:/home/joern/.m2/repository/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.jar > > urls[1] = > file:/home/joern/.m2/repository/ant-contrib/ant-contrib/1.0b3/ant-contrib-1.0b3.jar > > urls[2] = file:/home/joern/.m2/repository/ant/ant/1.5/ant-1.5.jar > urls[3] = > file:/home/joern/.m2/repository/org/apache/ant/ant/1.7.1/ant-1.7.1.jar > urls[4] = > file:/home/joern/.m2/repository/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar > > urls[5] = > file:/home/joern/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar > > [FATAL ERROR] Container realm = plexus.core > urls[0] = file:/usr/share/maven2/lib/wagon-ssh-common.jar > urls[1] = file:/usr/share/maven2/lib/jsch.jar > urls[2] = file:/usr/share/maven2/lib/wagon-http-shared.jar > urls[3] = file:/usr/share/maven2/lib/wagon-ssh.jar > urls[4] = file:/usr/share/maven2/lib/wagon-ssh-external.jar > urls[5] = file:/usr/share/maven2/lib/xml-apis.jar > urls[6] = file:/usr/share/maven2/lib/plexus-utils.jar > urls[7] = file:/usr/share/maven2/lib/plexus-container-default.jar > urls[8] = file:/usr/share/maven2/lib/wagon-provider-api.jar > urls[9] = file:/usr/share/maven2/lib/wagon-http-lightweight.jar > urls[10] = file:/usr/share/maven2/lib/jtidy.jar > urls[11] = file:/usr/share/maven2/lib/doxia-sink-api.jar > urls[12] = file:/usr/share/maven2/lib/wagon-file.jar > urls[13] = file:/usr/share/maven2/lib/plexus-interactivity-api.jar > urls[14] = file:/usr/share/maven2/lib/maven2.jar > urls[15] = file:/usr/share/maven2/lib/commons-cli.jar > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error configuring: org.apache.maven.plugins:maven-antrun-plugin. > Reason: java.lang.NoSuchMethodError: > org.apache.tools.ant.util.FileUtils.close(Ljava/io/InputStream;)V > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error > configuring: org.apache.maven.plugins:maven-antrun-plugin. Reason: > java.lang.NoSuchMethodError: > org.apache.tools.ant.util.FileUtils.close(Ljava/io/InputStream;)V >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:587) > >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) > >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) > >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > >at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) >at org.apache.maven.DefaultMaven.execute(De
Re: Projects are not synchronized after building
Jörn Kottmann wrote: > Hi, > > after building uima there are lots of empty src/main/resource/META-INF > folders > created in different projects. > Can these be added to svn:ignore ? > > After building the docbook there are .db files created, why these are > checked in ? > Must they be checked in again when they change during the build ? > Could we ignore these files, since they are generated ? > > Jörn History repeating itself: http://www.mail-archive.com/uima-dev@incubator.apache.org/msg03700.html and surrounding discussion. I think Marshall deleted some generated files, but not all of them. I think the docbook .db files are used for resolving cross-references. They change every time you change sections and such. I don't pretend to understand the docbook build, but imho those files should not be in svn. --Thilo
[jira] Commented: (UIMA-1326) Remove EMF dependency from uimaj-ep-runtime plugin
[ https://issues.apache.org/jira/browse/UIMA-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12750287#action_12750287 ] Thilo Goetz commented on UIMA-1326: --- We provide a lot of code where users first have to download something else before they can make it work. I'd vote for not including the ecore jars. > Remove EMF dependency from uimaj-ep-runtime plugin > -- > > Key: UIMA-1326 > URL: https://issues.apache.org/jira/browse/UIMA-1326 > Project: UIMA > Issue Type: Improvement > Components: Eclipse plugins >Affects Versions: 2.3 >Reporter: Jörn Kottmann >Assignee: Jörn Kottmann > Fix For: 2.3 > > Attachments: uima-as-distr_1326.patch, uimaj-distr_1326.patch, > uimaj-examples_1326.patch > > > The uimaj-ep-runtime plugin depends on EMF, this dependency makes deploying in > an non eclipse OSGI environment difficult since EMF depends on > org.eclipse.core.runtime, > which depends on many other eclipse plugins. > Since EMF is only really used in the examples project, the dependency is > removed > from uimaj-core and the classes Ecore2UimaTypeSystem and > UimaTypeSystem2Ecore.java > are moved to uimaj-examples. > The uimaj-ep-runtime plugin contains currently uimaj-examples, that > could be moved to a seperate plugin or shipped with an OSGI bundle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-629) Default file names produced by XmiWriterCasConsumer don't have .xmi extension and can't be read by XmiCollectionReader
[ https://issues.apache.org/jira/browse/UIMA-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12750048#action_12750048 ] Thilo Goetz commented on UIMA-629: -- +1 for going ahead with the fix. > Default file names produced by XmiWriterCasConsumer don't have .xmi extension > and can't be read by XmiCollectionReader > -- > > Key: UIMA-629 > URL: https://issues.apache.org/jira/browse/UIMA-629 > Project: UIMA > Issue Type: Bug > Components: Examples, Tools >Affects Versions: 2.2 >Reporter: Adam Lally >Priority: Minor > > If the original source file name is not present in the CAS, the > XmiWriterCasConsumer names the output file "doc0","doc1", etc,, with no .xmi > extension. The XmiCollectionReader will only read files with .xmi extensions. > > This is quite annoying if you're trying to break up a pipeline into two > parts, writing and reading XMI files in the middle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r808996 - /incubator/uima/uimaj/trunk/uimaj-bootstrap/
Burn Lewis wrote: > We have a very long list of jars in setUimaClassPath largely because we are > uncertain how many ActiveMQ jars to include ... currently we specify only 14 > of the 31 that AMQ loads. And one of ours is wrong as we specify > commons-collections-3.1.jar while the library has > commons-collections-2.1.jar ... which causes an apparently innocuous message > that is usually suppressed: > > 8/28/09 3:49:54 PM - 0: org.springframework.util.ClassUtils.isPresent: FINE: > Class [org.apache.commons.collections.map.LinkedMap] or one of its > dependencies is not present: java.lang.ClassNotFoundException: > org.apache.commons.collections.map.LinkedMap > > I was hoping that using a jar loader would avoid such mistakes, and also > make it easier for users to switch ActiveMQ versions by merely renaming the > parent directory. We could perhaps use AMQ's run.jar for these uima-as > scripts and load everything that their scripts load. If there are some uima > jars that should not be loaded perhaps they should be in an optional > directory. > > -Burn > That's up to you of course. It has been my experience that manually maintaining your startup scripts may be painful, but it costs less time in the long run. Loads of fun when these sorts of problems crop up on a customer's machine that you don't have access to and you need to remote debug what the issue might be. It's a different story if this is just for yourself and you always have a developer next door who can help you out. --Thilo
Re: Still a uima-as directory in the sandbox
I would prefer to delete the directory. However, if we do want to keep it, how about adding a (very short) readme that directs people to the new location? An empty directory seems a bit confusing. --Thilo Marshall Schor wrote: > > Thilo Goetz wrote: >> Marshall Schor wrote: >> >>> Thilo Goetz wrote: >>> >>>> I expect this is just a left-over and can be deleted? >>>> >>>> >>> Here's a possible reason to leave this: users can get the "history" of >>> this folder, and find older releases, where they might expect them. >>> >> I'm no subversion expert, but I think since you moved >> uima-as in subversion, all the history is there and >> keeping this folder serves no purpose. >> > This is true. It's more a question of the user-interface. If we keep > this, then a user who "remembers" or has some reference here, will find > this in SVN and can right click the folder (say with TortiseSVN > installed) and have a look at the history. > > With it removed, the user has to experience some confusion - where did > it go? - and then (maybe slowly - unless they're an SVN expert) realize > that they could go to the containing folder, and ask for the history on > that folder, and search for what happened to this one. > > At least, that's my imagination of what has to happen - but - perhaps > there's even a better way? > > -Marshall >> >>> I'm ok with removing it though, if that's the more normal, less >>> confusing approach. >>> >>> -Marshall >>> >>>> --Thilo >>>> >>>> >>>> >>>> >> >>
Re: svn commit: r808996 - /incubator/uima/uimaj/trunk/uimaj-bootstrap/
Marshall Schor wrote: > > Thilo Goetz wrote: >> Marshall Schor wrote: >> >>> The reason for a new project was to isolate the classes in the "normal" >>> -cp class path to just this one class :-). >>> >>> This is a general purpose launcher, that could also be used to simplify >>> our base launching scripts. >>> >> I think we would be doing our users a disservice. I just fixed >> the pear runner not to go ahead an use any jar file it finds >> in the lib directory. That kind of defaulty behavior has surprising >> and undesirable effects. >> >> > > Well, at least this is "optional" in some sense. But other projects I > see are using this approach (ActiveMQ for instance). > > Is there another simple approach to "aggregating" lots of Jar files, > other than long lists of them in some file? You have to balance convenience vs. safety here. I like to come down on the safety side because I have witnessed many times how much time can be wasted by an error caused by this kind of "convenience". This kind of behavior is ok for app servers/runtime containers that have dedicated directories where you drop your jars or class files and they pick them up, maybe without even having to restart your app. For startup scripts, the safety concerns imo outweigh the desire for convenience. We manage to create enough classpath problems without needing to aggravate them with fancy classloading utilities. --Thilo > > -Marshall >>> -Marshall >>> >>> Thilo Goetz wrote: >>> >>>> sc...@apache.org wrote: >>>> >>>> >>>>> Author: schor >>>>> Date: Fri Aug 28 19:28:58 2009 >>>>> New Revision: 808996 >>>>> >>>>> URL: http://svn.apache.org/viewvc?rev=808996&view=rev >>>>> Log: >>>>> [UIMA-1536] initial import, moved from uimaj-tools >>>>> >>>>> Added: >>>>> incubator/uima/uimaj/trunk/uimaj-bootstrap/ >>>>> >>>>> >>>> We create a new project just for this? Am I correct >>>> in assuming that only UIMA-AS needs this? Why don't >>>> we put it there then? >>>> >>>> --Thilo >>>> >>>> >>>> >>>> >> >> >>
Re: Still a uima-as directory in the sandbox
Marshall Schor wrote: > > Thilo Goetz wrote: >> I expect this is just a left-over and can be deleted? >> > Here's a possible reason to leave this: users can get the "history" of > this folder, and find older releases, where they might expect them. I'm no subversion expert, but I think since you moved uima-as in subversion, all the history is there and keeping this folder serves no purpose. > > I'm ok with removing it though, if that's the more normal, less > confusing approach. > > -Marshall >> --Thilo >> >> >>
[jira] Closed: (UIMA-1152) Match group counting does not work properly with escaped open bracket within variables.
[ https://issues.apache.org/jira/browse/UIMA-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thilo Goetz closed UIMA-1152. - Resolution: Invalid I created some more tests, and they all run as expected. Maybe there's some misunderstanding here about the escaping rules in character classes? [\s,\.:;\[\]\(\)] doesn't make much sense, all the backslashes don't have their probably intended effect, except for \] and \[. If this is really a problem, please create a test case that allows us to understand what's going wrong here. Thanks. > Match group counting does not work properly with escaped open bracket within > variables. > --- > > Key: UIMA-1152 > URL: https://issues.apache.org/jira/browse/UIMA-1152 > Project: UIMA > Issue Type: Bug > Components: Sandbox-RegexAnnotator >Affects Versions: 2.2.2S, 2.3S > Environment: Windows XP >Reporter: Mateusz Wiacek >Priority: Minor > > Example: > > Escaped open bracket should not be recognized as matching group, but it does. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Still a uima-as directory in the sandbox
I expect this is just a left-over and can be deleted? --Thilo
[jira] Closed: (UIMA-1457) SimpleServer: docs need updating for Tomcat 6
[ https://issues.apache.org/jira/browse/UIMA-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thilo Goetz closed UIMA-1457. - Resolution: Fixed Improved, but still documentation missing. > SimpleServer: docs need updating for Tomcat 6 > - > > Key: UIMA-1457 > URL: https://issues.apache.org/jira/browse/UIMA-1457 > Project: UIMA > Issue Type: Bug > Components: Sandbox-SimpleServer >Affects Versions: 2.2.2S > Reporter: Thilo Goetz >Assignee: Thilo Goetz > Fix For: 2.3S > > > The current instructions do not work out of the box with Tomcat 6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (UIMA-1462) SimpleUimaAsService has checked in SimpleServer libraries as binaries
[ https://issues.apache.org/jira/browse/UIMA-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749770#action_12749770 ] Thilo Goetz edited comment on UIMA-1462 at 8/31/09 10:36 PM: - Sorry, I misspoke. There's no need to rush this for the release. was (Author: twgoetz): Tommaso, do you think this is something you could get integrated in time for the release? I never got around to checking your latest patch, I'm afraid. > SimpleUimaAsService has checked in SimpleServer libraries as binaries > - > > Key: UIMA-1462 > URL: https://issues.apache.org/jira/browse/UIMA-1462 > Project: UIMA > Issue Type: Bug > Components: Sandbox-SimpleUimaAsService >Affects Versions: 2.2.2S, 2.3S >Reporter: Thilo Goetz > Attachments: patch1462.txt, patch1462b1.txt, patch1462b2.txt, > patch1462c1.txt, patch1462c2.txt, simpleServerDistributionPatch.txt, > simpleUimaAsServicePatch.txt > > > For the upcoming release, this should be changed so it depends on the > SimpleServer project directly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
