I don't know of any specific reason why not to do this, but just be
sure to review the history of this to make sure we aren't going around
in circles. It used to be that way, and it changed along with issue
https://issues.apache.org/jira/browse/UIMA-355. Also look for
discussion of UIMA-355 in the email archives.
-Adam
On Jan 21, 2008 4:58 AM, Michael Baessler <[EMAIL PROTECTED]> wrote:
> I don't know if that change cause any issues in our plugins, but I would
> prefer to do the change. It minimize the errors and the manual effort
> when doing a release.
>
> -- Michael
>
>
> Marshall Schor wrote:
> > The basic maven build creates Jars in the target with alternate names:
> > project uimaj-core => drop the "j" from uimaj, and don't suffix the
> > version -> uima-core.jar
> >
> > An exception to this is jVinci - jVinci becomes jVinci.jar (no version)
> >
> > Another exception: when the uimaj-ep-runtime plugin is built, it has
> > Jars in with the names:
> > project uimaj-core => uimaj-core-{version}.jar
> >
> > These names have to match entries in the manifest.
> >
> > I'm working on improvements to our maven POMs to more automate the
> > builds. I've been able to build the uimaj-ep-runtime jar so it
> > contains the other jars, but it puts in the jars as named by the other
> > projects, so it has, e.g., uima-core.jar (no j, and no version).
> >
> > This would make our uimaj-ep-plugin internal jars follow our other jar
> > naming conventions, and would reduce the need to have uimaj-ep-runtime
> > manifest updated to change version numbers.
> >
> > Is this OK to do, or is there a reason we keep the uimaj-ep-runtime
> > inner jars naming conventions different?
> >
> > -Marshall
> >
> >
>
>
