Re: Sandbox OSGi runtime
Nice one! It seems a nice effort from the Felix community and it looks like it's perfectly aligned with what we are trying to do (a POM with a dependency on the library to bundle and the Maven Felix plugin for the configuration of the bundle), so we may choose one of two ways: contribute such POMs to Felix Commons (but we'd need to change the group-id to org.apache.felix.commons) or have them deployed inside our SVN and linked (having UIMA listed as one of the supporting libraries) to the Felix Commons project. Since we already have OSGi versions of core framework inside our SVN to support Eclipse plugins we may go for the second option. So if we agree I could start a thread on Felix ML to let them know about this effort. What do you think? Have a nice day. Tommaso 2010/4/4 Marshall Schor m...@schor.com +1. I think there is a (slowly?) growing interest in OSGi - see, for instance, the latest info in the apache felix project [1] and in particular, the newer, possibly unreleased subprojects [2]. There are efforts there in the Apache Felix Commons subproject [3] to do more or less what you are trying to do here - it would be good to confirm these approaches are aligned :-). -Marshall [1] http://felix.apache.org/site/index.html [2] http://felix.apache.org/site/subprojects.html [3] http://felix.apache.org/site/apache-felix-commons.html
Re: [Informal Vote] please express your opinion on using Nexus and Hudson: see https://issues.apache.org/jira/browse/UIMA-1717
Marshall Schor wrote: Here's my vision of automation (achieved over time :-) ), and why CI could be important - it is building the potential releases from source checkout. We have CI going on Hudson; we decide at some point that things merit a release; so we push some button on the CI or Nexus interface and get a particular snapshot release tagged, checked out and built as a candidate. We do some additional integration testing, and then vote on the thing in the nexus repo, where it look like a release but is in some held state. After the vote succeeds, we log onto the Nexus web interface and push another button, and the release happens. +1 sounds nice Jörn
[jira] Created: (UIMA-1755) Improve Maven build
Improve Maven build --- Key: UIMA-1755 URL: https://issues.apache.org/jira/browse/UIMA-1755 Project: UIMA Issue Type: Task Components: Build, Packaging and Test Affects Versions: 2.3 Reporter: Marshall Schor Assignee: Marshall Schor Do this work in a branch (mavenAlign), because it is extensive and may take some time to get it working the way people want it to work. Improve the maven build with the goal of making it more aligned with the maven way, being simpler, and following Apache conventions. Subtasks will track individual parts of this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1756) Maven-align: POM work
Maven-align: POM work - Key: UIMA-1756 URL: https://issues.apache.org/jira/browse/UIMA-1756 Project: UIMA Issue Type: Sub-task Components: Build, Packaging and Test Reporter: Marshall Schor Assignee: Marshall Schor 1) eliminate need for any individual project checkout to depend on another project being checked out simultaneously. This includes: * switching to docbkx maven plugin instead of our own docbook tooling * using maven-remote-resources plugin for including common, shared things, rather than referring to other projects * use POM dependencies from the repositories 2) make POMs inherit from Apache master POM. 3) separate *parent* poms from *aggregation* poms. 4) make POMs inherit from Apache common POM 5) make parent poms separately releasable, using the apache/maven convention for version numbering (single digit). 6) position aggregator poms in the conventional position (not flat structure) to enable some plugins (assembly and release) to function better. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1757) use docbkx to create docbooks in place of current docbook tools project
use docbkx to create docbooks in place of current docbook tools project --- Key: UIMA-1757 URL: https://issues.apache.org/jira/browse/UIMA-1757 Project: UIMA Issue Type: Sub-task Reporter: Marshall Schor Assignee: Marshall Schor 1) align target dir structures with the way docbkx conventionally does this 2) update docbooks to 4.4 from 4.5 DTD (4.5 not in maven repo, 5.0 is, but may require more changes) 3) write parent pom for docbkx 4) change poms doing docbook to add docbkx in the pre-site phase 5) figure out olink database strategy - this should probably be remote resources, pulled in via maven dependencies (i.e., when a docbook links to another one, it has a dependency on that other docbook's olink database). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1758) remove dependency on checked-out other projects
remove dependency on checked-out other projects --- Key: UIMA-1758 URL: https://issues.apache.org/jira/browse/UIMA-1758 Project: UIMA Issue Type: Sub-task Reporter: Marshall Schor Assignee: Marshall Schor use maven-remote-resources plugin for including common, shared things, rather than referring to other checked-out projects -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1756) Maven-align: POM work
[ https://issues.apache.org/jira/browse/UIMA-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1756: - Description: 1) eliminate need for any individual project checkout to depend on another project being checked out simultaneously. This includes: * switching to docbkx maven plugin instead of our own docbook tooling (see other subtask) * using maven-remote-resources plugin for including common, shared things, rather than referring to other projects (see other subtask) * use POM dependencies from the repositories 2) make POMs inherit from Apache master POM. 3) separate *parent* poms from *aggregation* poms. 4) make POMs inherit from Apache common POM 5) make parent poms separately releasable, using the apache/maven convention for version numbering (single digit). 6) position aggregator poms in the conventional position (not flat structure) to enable some plugins (assembly and release) to function better. was: 1) eliminate need for any individual project checkout to depend on another project being checked out simultaneously. This includes: * switching to docbkx maven plugin instead of our own docbook tooling * using maven-remote-resources plugin for including common, shared things, rather than referring to other projects * use POM dependencies from the repositories 2) make POMs inherit from Apache master POM. 3) separate *parent* poms from *aggregation* poms. 4) make POMs inherit from Apache common POM 5) make parent poms separately releasable, using the apache/maven convention for version numbering (single digit). 6) position aggregator poms in the conventional position (not flat structure) to enable some plugins (assembly and release) to function better. Maven-align: POM work - Key: UIMA-1756 URL: https://issues.apache.org/jira/browse/UIMA-1756 Project: UIMA Issue Type: Sub-task Components: Build, Packaging and Test Reporter: Marshall Schor Assignee: Marshall Schor 1) eliminate need for any individual project checkout to depend on another project being checked out simultaneously. This includes: * switching to docbkx maven plugin instead of our own docbook tooling (see other subtask) * using maven-remote-resources plugin for including common, shared things, rather than referring to other projects (see other subtask) * use POM dependencies from the repositories 2) make POMs inherit from Apache master POM. 3) separate *parent* poms from *aggregation* poms. 4) make POMs inherit from Apache common POM 5) make parent poms separately releasable, using the apache/maven convention for version numbering (single digit). 6) position aggregator poms in the conventional position (not flat structure) to enable some plugins (assembly and release) to function better. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1759) make project versioning more conventional
make project versioning more conventional - Key: UIMA-1759 URL: https://issues.apache.org/jira/browse/UIMA-1759 Project: UIMA Issue Type: Sub-task Components: Build, Packaging and Test Reporter: Marshall Schor Assignee: Marshall Schor 1) make aggregator poms distinct from parent poms 2) aggregator poms to specify which version(s) of modules they are including (some may not change release to release) 3) Eliminate the use of properties in values for versions (these cause warning messages when used with maven 3 - saying this support will not work in the future) 4) align project versioning with the way the maven release plugin works. 5) make parent poms separately releasable, using the apache/maven convention for version numbering of these kinds of artifacts (e.g., simple number, starting with 1). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
starting in on updating our maven build process
This task has lots of parts; I plan to do the work in a branch. I put the various parts into a Jira Task with subtasks. Questions / Comments / discussion on improving things beyond this attempt are welcome :-). Overall goal: when it's finished, we should be able to check out a project and do mvn install to build it , and mvn site to build its documentation. -Marshall
