binary builds in addons

[Marshall Schor <ms...@schor.com>]

Now that I've prototyped the osgi build (not yet checked in), and revisited the
other binary builds, it seems there's a lot of similarity among these.

I think there are 3 kinds:

1) single-project build - like FsVariables, and SimpleServer
2) PEARs
3) OSGi

The single-project and PEARs seem almost identical, except the PEARs have a
special install.xml file (for installing the PEAR).  (One superficial difference
is that the docs directory in PEARs is "doc", and in single-projects, is 'docs').

They both include documentation in "built" form (PDFs and HTML files), and javadocs.

The OSGi form has a special MANIFEST.MF file, and doesn't include documentation
or javadocs.

The zip/tar-ing of these is somewhat different:  single-project has a zip/tar
assembly, PEAR has a zip (the *.PEAR file), and the OSGi has a JAR (which is of
course, a zip).  In addition, the addons "aggregate" of all the addon projects
has all of them zipped/tarred up together.

There is also for most things, a standard JAR packaging of just the core
annotator, containing class/ directory.

The OSGi build as far as I can tell *requires* (by which I mean that I couldn't
figure out how to override this) that the main set of classes be in the standard
${project.build.outputDirectory}.  In contrast, the PEAR and single-project
build are packaging the main set of classes by letting the standard JAR plugin
package them as a jar, and then including that JAR in the lib/ of the zip/tar. 
So the lib/ of those packagings is slightly different from the lib/ of the OSGi
packaging - in that the OSGi doesn't have the main set of classes as a separate
inside its lib/ directory.

The build logic for these eventually should be in the build/ part, in the
overall parent-pom, and in the related uima-build-resources project.  But for
now we are having addons-level overrides for this in the uima-addons-parent pom,
and for uima-addons aggregate assembly, in the src/main/assembly directory.

It seems that a small bit of restructuring would help in the overall building of
things.  This would have a common part of these build steps do the collection of
all the parts that are destined to go into the zip/tar etc. 

The single-project build and the PEAR have the most in common, the OSGi the least.

I'm currently thinking that all addons should include a single-project build
(zip/tar).
Those marked as PEARs should also have a PEAR build.
Those marked as OSGi should also have an OSGi build.

The binary addons aggregate I think should drop the individual single-project
zip/tar - there's little value to having this done 2x.

For uploading to Maven repository: the main Jar is uploaded, the source-release
is uploaded, and it would seem to make sense to upload the PEAR and the OSGi
zips, too. So the only thing not uploaded would be the single-project zip/tar.

Does this seem right to others?

I'll work on refactoring the addons build to take advantage of all this
commonality :-)

-Marshall

Re: binary builds in addons

[Tommaso Teofili <to...@gmail.com>]

Nice news Marshall!!
Let me know if you need any help :)
Tommaso

2011/7/28 Marshall Schor <ms...@schor.com>

> more good news -
>
> The bundle plugin was reporting 2 warnings - one was the one noted below,
> and
> another was when the <Bundle-Exports> instruction was left off of the
> individual
> component pom.  In this last case, it is supposed to "default" - by looking
> in
> the project's src/java (I think) and finding the "packages" other than ones
> with
> "impl" in them - see the bundle docs, where it says:
>
> <Export-Package> is now assumed to be the set of packages in your local
> Java
> sources, excluding the default package '.' and any packages containing
> 'impl' or
> 'internal'.
> /(before version 2 of the bundleplugin it was based on the symbolic name)/
>
> I tried upgrading from our default version 2.1.0 to the latest 2.3.5, and
> it
> made all these problems go away :-)
>
> -Marshall
>
> On 7/27/2011 5:23 PM, Marshall Schor wrote:
> > some better progress - I was able to get the maven bundle plugin to build
> the
> > osgi manifest, and then jar everything up from a copy of the base binary
> build
> > spot I used for (1) and (4).  So I have "sharing" of things among 1, 3,
> and 4.
> > And I'll fix the PEAR build to share too, for some of this
> >
> > The maven bundle plugin, when run with the manifest goal, seems to:
> >
> > 1) use the bundle classpath, which includes the target/classes dir, plus
> the
> > dependency artifact jars, to do its work.
> > 2) It "checks" this against what is specified for its Bundle-ClassPath,
> which I
> > have now set to:
> >
> >
> <Bundle-ClassPath>.,lib/${project.build.finalName}.jar,{maven-dependencies}</Bundle-ClassPath>
> >
> > where {maven-dependencies} is a bundle plugin thing set from combining
> the
> > setting of Embed-Directory (set to "lib") and the pom's dependencies.
>  This
> > results in the classpath coming out in the manifest to be:
> >
> >
> .,lib/uimaj-an-bsf.jar,lib/log4j-1.2.14.jar,lib/bsf-2.4.0.jar,lib/commons-logging-api-1.1.jar,lib/js-1.7R2.jar,lib/bsh-2.
> > 0b4.jar
> >
> > which is how the following maven jar plugin step will construct things.
> >
> > The bundle plugin does check, however, if this lib/xxx structure
> currently
> > exists under target/classes - which of course it doesn't.  So it issues
> some
> > warnings.  But nevertheless, it creates the proper manifest and stores it
> in the
> > right place for the next Jar step to work.
> >
> > So I think OSGi builds may be working :-)  Now to fix the PEAR build (to
> share
> > the same common build.  Then, I'll try it on all the other addons and if
> that
> > all works, I'll check in the changes...  (maybe tomorrow).
> >
> > -Marshall
> >
> > On 7/27/2011 3:40 PM, Marshall Schor wrote:
> >> An update, after spending some time on this.
> >>
> >>
> >> There are 4 kinds of builds:
> >>
> >> 1) single-project build
> >> 2) PEARs
> >> 3) OSGi
> >> 4) The aggregation of all the addons into one binary zip/tar
> >>
> >> The PEAR build uses the PearPackaginMavenPlugin which does a lot of
> local
> >> copying from the source tree, presumed to be layed out in standard PEAR
> format,
> >> and a special, hard-coded subdirectory of target, called pearPackaging.
> >>
> >> So - it's going to populate this anyways from the source tree.
> >>
> >> The OSGi maven bundle plugin I can't make work unless I have it jar up
> things in
> >> the standard place, and place the lib/ for dependencies in the
> target/classes
> >> directory.
> >>
> >> So the commonality I was hoping for seems hard to get.  I can get some
> from
> >> sharing the build for (1) and (4), though.
> >>
> >> -Marshall (making slow progress)
> >>
> >>
> >> On 7/26/2011 4:48 PM, Marshall Schor wrote:
> >>> Now that I've prototyped the osgi build (not yet checked in), and
> revisited the
> >>> other binary builds, it seems there's a lot of similarity among these.
> >>>
> >>> I think there are 3 kinds:
> >>>
> >>> 1) single-project build - like FsVariables, and SimpleServer
> >>> 2) PEARs
> >>> 3) OSGi
> >>>
> >>> The single-project and PEARs seem almost identical, except the PEARs
> have a
> >>> special install.xml file (for installing the PEAR).  (One superficial
> difference
> >>> is that the docs directory in PEARs is "doc", and in single-projects,
> is 'docs').
> >>>
> >>> They both include documentation in "built" form (PDFs and HTML files),
> and javadocs.
> >>>
> >>> The OSGi form has a special MANIFEST.MF file, and doesn't include
> documentation
> >>> or javadocs.
> >>>
> >>> The zip/tar-ing of these is somewhat different:  single-project has a
> zip/tar
> >>> assembly, PEAR has a zip (the *.PEAR file), and the OSGi has a JAR
> (which is of
> >>> course, a zip).  In addition, the addons "aggregate" of all the addon
> projects
> >>> has all of them zipped/tarred up together.
> >>>
> >>> There is also for most things, a standard JAR packaging of just the
> core
> >>> annotator, containing class/ directory.
> >>>
> >>> The OSGi build as far as I can tell *requires* (by which I mean that I
> couldn't
> >>> figure out how to override this) that the main set of classes be in the
> standard
> >>> ${project.build.outputDirectory}.  In contrast, the PEAR and
> single-project
> >>> build are packaging the main set of classes by letting the standard JAR
> plugin
> >>> package them as a jar, and then including that JAR in the lib/ of the
> zip/tar.
> >>> So the lib/ of those packagings is slightly different from the lib/ of
> the OSGi
> >>> packaging - in that the OSGi doesn't have the main set of classes as a
> separate
> >>> inside its lib/ directory.
> >>>
> >>> The build logic for these eventually should be in the build/ part, in
> the
> >>> overall parent-pom, and in the related uima-build-resources project.
>  But for
> >>> now we are having addons-level overrides for this in the
> uima-addons-parent pom,
> >>> and for uima-addons aggregate assembly, in the src/main/assembly
> directory.
> >>>
> >>> It seems that a small bit of restructuring would help in the overall
> building of
> >>> things.  This would have a common part of these build steps do the
> collection of
> >>> all the parts that are destined to go into the zip/tar etc.
> >>>
> >>> The single-project build and the PEAR have the most in common, the OSGi
> the least.
> >>>
> >>> I'm currently thinking that all addons should include a single-project
> build
> >>> (zip/tar).
> >>> Those marked as PEARs should also have a PEAR build.
> >>> Those marked as OSGi should also have an OSGi build.
> >>>
> >>> The binary addons aggregate I think should drop the individual
> single-project
> >>> zip/tar - there's little value to having this done 2x.
> >>>
> >>> For uploading to Maven repository: the main Jar is uploaded, the
> source-release
> >>> is uploaded, and it would seem to make sense to upload the PEAR and the
> OSGi
> >>> zips, too. So the only thing not uploaded would be the single-project
> zip/tar.
> >>>
> >>> Does this seem right to others?
> >>>
> >>> I'll work on refactoring the addons build to take advantage of all this
> >>> commonality :-)
> >>>
> >>> -Marshall
> >>>
> >>>
>

Re: binary builds in addons

[Marshall Schor <ms...@schor.com>]

more good news -

The bundle plugin was reporting 2 warnings - one was the one noted below, and
another was when the <Bundle-Exports> instruction was left off of the individual
component pom.  In this last case, it is supposed to "default" - by looking in
the project's src/java (I think) and finding the "packages" other than ones with
"impl" in them - see the bundle docs, where it says:

<Export-Package> is now assumed to be the set of packages in your local Java
sources, excluding the default package '.' and any packages containing 'impl' or
'internal'.
/(before version 2 of the bundleplugin it was based on the symbolic name)/

I tried upgrading from our default version 2.1.0 to the latest 2.3.5, and it
made all these problems go away :-)

-Marshall

On 7/27/2011 5:23 PM, Marshall Schor wrote:
> some better progress - I was able to get the maven bundle plugin to build the
> osgi manifest, and then jar everything up from a copy of the base binary build
> spot I used for (1) and (4).  So I have "sharing" of things among 1, 3, and 4. 
> And I'll fix the PEAR build to share too, for some of this
>
> The maven bundle plugin, when run with the manifest goal, seems to:
>
> 1) use the bundle classpath, which includes the target/classes dir, plus the
> dependency artifact jars, to do its work.
> 2) It "checks" this against what is specified for its Bundle-ClassPath, which I
> have now set to:
>
> <Bundle-ClassPath>.,lib/${project.build.finalName}.jar,{maven-dependencies}</Bundle-ClassPath>
>
> where {maven-dependencies} is a bundle plugin thing set from combining the
> setting of Embed-Directory (set to "lib") and the pom's dependencies.  This
> results in the classpath coming out in the manifest to be:
>
> .,lib/uimaj-an-bsf.jar,lib/log4j-1.2.14.jar,lib/bsf-2.4.0.jar,lib/commons-logging-api-1.1.jar,lib/js-1.7R2.jar,lib/bsh-2.
> 0b4.jar
>
> which is how the following maven jar plugin step will construct things. 
>
> The bundle plugin does check, however, if this lib/xxx structure currently
> exists under target/classes - which of course it doesn't.  So it issues some
> warnings.  But nevertheless, it creates the proper manifest and stores it in the
> right place for the next Jar step to work.
>
> So I think OSGi builds may be working :-)  Now to fix the PEAR build (to share
> the same common build.  Then, I'll try it on all the other addons and if that
> all works, I'll check in the changes...  (maybe tomorrow).
>
> -Marshall
>
> On 7/27/2011 3:40 PM, Marshall Schor wrote:
>> An update, after spending some time on this.
>>
>>
>> There are 4 kinds of builds:
>>
>> 1) single-project build
>> 2) PEARs
>> 3) OSGi
>> 4) The aggregation of all the addons into one binary zip/tar
>>
>> The PEAR build uses the PearPackaginMavenPlugin which does a lot of local
>> copying from the source tree, presumed to be layed out in standard PEAR format,
>> and a special, hard-coded subdirectory of target, called pearPackaging.
>>
>> So - it's going to populate this anyways from the source tree.
>>
>> The OSGi maven bundle plugin I can't make work unless I have it jar up things in
>> the standard place, and place the lib/ for dependencies in the target/classes
>> directory.
>>
>> So the commonality I was hoping for seems hard to get.  I can get some from
>> sharing the build for (1) and (4), though.
>>
>> -Marshall (making slow progress)
>>
>>
>> On 7/26/2011 4:48 PM, Marshall Schor wrote:
>>> Now that I've prototyped the osgi build (not yet checked in), and revisited the
>>> other binary builds, it seems there's a lot of similarity among these.
>>>
>>> I think there are 3 kinds:
>>>
>>> 1) single-project build - like FsVariables, and SimpleServer
>>> 2) PEARs
>>> 3) OSGi
>>>
>>> The single-project and PEARs seem almost identical, except the PEARs have a
>>> special install.xml file (for installing the PEAR).  (One superficial difference
>>> is that the docs directory in PEARs is "doc", and in single-projects, is 'docs').
>>>
>>> They both include documentation in "built" form (PDFs and HTML files), and javadocs.
>>>
>>> The OSGi form has a special MANIFEST.MF file, and doesn't include documentation
>>> or javadocs.
>>>
>>> The zip/tar-ing of these is somewhat different:  single-project has a zip/tar
>>> assembly, PEAR has a zip (the *.PEAR file), and the OSGi has a JAR (which is of
>>> course, a zip).  In addition, the addons "aggregate" of all the addon projects
>>> has all of them zipped/tarred up together.
>>>
>>> There is also for most things, a standard JAR packaging of just the core
>>> annotator, containing class/ directory.
>>>
>>> The OSGi build as far as I can tell *requires* (by which I mean that I couldn't
>>> figure out how to override this) that the main set of classes be in the standard
>>> ${project.build.outputDirectory}.  In contrast, the PEAR and single-project
>>> build are packaging the main set of classes by letting the standard JAR plugin
>>> package them as a jar, and then including that JAR in the lib/ of the zip/tar. 
>>> So the lib/ of those packagings is slightly different from the lib/ of the OSGi
>>> packaging - in that the OSGi doesn't have the main set of classes as a separate
>>> inside its lib/ directory.
>>>
>>> The build logic for these eventually should be in the build/ part, in the
>>> overall parent-pom, and in the related uima-build-resources project.  But for
>>> now we are having addons-level overrides for this in the uima-addons-parent pom,
>>> and for uima-addons aggregate assembly, in the src/main/assembly directory.
>>>
>>> It seems that a small bit of restructuring would help in the overall building of
>>> things.  This would have a common part of these build steps do the collection of
>>> all the parts that are destined to go into the zip/tar etc. 
>>>
>>> The single-project build and the PEAR have the most in common, the OSGi the least.
>>>
>>> I'm currently thinking that all addons should include a single-project build
>>> (zip/tar).
>>> Those marked as PEARs should also have a PEAR build.
>>> Those marked as OSGi should also have an OSGi build.
>>>
>>> The binary addons aggregate I think should drop the individual single-project
>>> zip/tar - there's little value to having this done 2x.
>>>
>>> For uploading to Maven repository: the main Jar is uploaded, the source-release
>>> is uploaded, and it would seem to make sense to upload the PEAR and the OSGi
>>> zips, too. So the only thing not uploaded would be the single-project zip/tar.
>>>
>>> Does this seem right to others?
>>>
>>> I'll work on refactoring the addons build to take advantage of all this
>>> commonality :-)
>>>
>>> -Marshall
>>>
>>>

Re: binary builds in addons

[Marshall Schor <ms...@schor.com>]

some better progress - I was able to get the maven bundle plugin to build the
osgi manifest, and then jar everything up from a copy of the base binary build
spot I used for (1) and (4).  So I have "sharing" of things among 1, 3, and 4. 
And I'll fix the PEAR build to share too, for some of this

The maven bundle plugin, when run with the manifest goal, seems to:

1) use the bundle classpath, which includes the target/classes dir, plus the
dependency artifact jars, to do its work.
2) It "checks" this against what is specified for its Bundle-ClassPath, which I
have now set to:

<Bundle-ClassPath>.,lib/${project.build.finalName}.jar,{maven-dependencies}</Bundle-ClassPath>

where {maven-dependencies} is a bundle plugin thing set from combining the
setting of Embed-Directory (set to "lib") and the pom's dependencies.  This
results in the classpath coming out in the manifest to be:

.,lib/uimaj-an-bsf.jar,lib/log4j-1.2.14.jar,lib/bsf-2.4.0.jar,lib/commons-logging-api-1.1.jar,lib/js-1.7R2.jar,lib/bsh-2.
0b4.jar

which is how the following maven jar plugin step will construct things. 

The bundle plugin does check, however, if this lib/xxx structure currently
exists under target/classes - which of course it doesn't.  So it issues some
warnings.  But nevertheless, it creates the proper manifest and stores it in the
right place for the next Jar step to work.

So I think OSGi builds may be working :-)  Now to fix the PEAR build (to share
the same common build.  Then, I'll try it on all the other addons and if that
all works, I'll check in the changes...  (maybe tomorrow).

-Marshall

On 7/27/2011 3:40 PM, Marshall Schor wrote:
> An update, after spending some time on this.
>
>
> There are 4 kinds of builds:
>
> 1) single-project build
> 2) PEARs
> 3) OSGi
> 4) The aggregation of all the addons into one binary zip/tar
>
> The PEAR build uses the PearPackaginMavenPlugin which does a lot of local
> copying from the source tree, presumed to be layed out in standard PEAR format,
> and a special, hard-coded subdirectory of target, called pearPackaging.
>
> So - it's going to populate this anyways from the source tree.
>
> The OSGi maven bundle plugin I can't make work unless I have it jar up things in
> the standard place, and place the lib/ for dependencies in the target/classes
> directory.
>
> So the commonality I was hoping for seems hard to get.  I can get some from
> sharing the build for (1) and (4), though.
>
> -Marshall (making slow progress)
>
>
> On 7/26/2011 4:48 PM, Marshall Schor wrote:
>> Now that I've prototyped the osgi build (not yet checked in), and revisited the
>> other binary builds, it seems there's a lot of similarity among these.
>>
>> I think there are 3 kinds:
>>
>> 1) single-project build - like FsVariables, and SimpleServer
>> 2) PEARs
>> 3) OSGi
>>
>> The single-project and PEARs seem almost identical, except the PEARs have a
>> special install.xml file (for installing the PEAR).  (One superficial difference
>> is that the docs directory in PEARs is "doc", and in single-projects, is 'docs').
>>
>> They both include documentation in "built" form (PDFs and HTML files), and javadocs.
>>
>> The OSGi form has a special MANIFEST.MF file, and doesn't include documentation
>> or javadocs.
>>
>> The zip/tar-ing of these is somewhat different:  single-project has a zip/tar
>> assembly, PEAR has a zip (the *.PEAR file), and the OSGi has a JAR (which is of
>> course, a zip).  In addition, the addons "aggregate" of all the addon projects
>> has all of them zipped/tarred up together.
>>
>> There is also for most things, a standard JAR packaging of just the core
>> annotator, containing class/ directory.
>>
>> The OSGi build as far as I can tell *requires* (by which I mean that I couldn't
>> figure out how to override this) that the main set of classes be in the standard
>> ${project.build.outputDirectory}.  In contrast, the PEAR and single-project
>> build are packaging the main set of classes by letting the standard JAR plugin
>> package them as a jar, and then including that JAR in the lib/ of the zip/tar. 
>> So the lib/ of those packagings is slightly different from the lib/ of the OSGi
>> packaging - in that the OSGi doesn't have the main set of classes as a separate
>> inside its lib/ directory.
>>
>> The build logic for these eventually should be in the build/ part, in the
>> overall parent-pom, and in the related uima-build-resources project.  But for
>> now we are having addons-level overrides for this in the uima-addons-parent pom,
>> and for uima-addons aggregate assembly, in the src/main/assembly directory.
>>
>> It seems that a small bit of restructuring would help in the overall building of
>> things.  This would have a common part of these build steps do the collection of
>> all the parts that are destined to go into the zip/tar etc. 
>>
>> The single-project build and the PEAR have the most in common, the OSGi the least.
>>
>> I'm currently thinking that all addons should include a single-project build
>> (zip/tar).
>> Those marked as PEARs should also have a PEAR build.
>> Those marked as OSGi should also have an OSGi build.
>>
>> The binary addons aggregate I think should drop the individual single-project
>> zip/tar - there's little value to having this done 2x.
>>
>> For uploading to Maven repository: the main Jar is uploaded, the source-release
>> is uploaded, and it would seem to make sense to upload the PEAR and the OSGi
>> zips, too. So the only thing not uploaded would be the single-project zip/tar.
>>
>> Does this seem right to others?
>>
>> I'll work on refactoring the addons build to take advantage of all this
>> commonality :-)
>>
>> -Marshall
>>
>>

Re: binary builds in addons

[Marshall Schor <ms...@schor.com>]

An update, after spending some time on this.


There are 4 kinds of builds:

1) single-project build
2) PEARs
3) OSGi
4) The aggregation of all the addons into one binary zip/tar

The PEAR build uses the PearPackaginMavenPlugin which does a lot of local
copying from the source tree, presumed to be layed out in standard PEAR format,
and a special, hard-coded subdirectory of target, called pearPackaging.

So - it's going to populate this anyways from the source tree.

The OSGi maven bundle plugin I can't make work unless I have it jar up things in
the standard place, and place the lib/ for dependencies in the target/classes
directory.

So the commonality I was hoping for seems hard to get.  I can get some from
sharing the build for (1) and (4), though.

-Marshall (making slow progress)


On 7/26/2011 4:48 PM, Marshall Schor wrote:
> Now that I've prototyped the osgi build (not yet checked in), and revisited the
> other binary builds, it seems there's a lot of similarity among these.
>
> I think there are 3 kinds:
>
> 1) single-project build - like FsVariables, and SimpleServer
> 2) PEARs
> 3) OSGi
>
> The single-project and PEARs seem almost identical, except the PEARs have a
> special install.xml file (for installing the PEAR).  (One superficial difference
> is that the docs directory in PEARs is "doc", and in single-projects, is 'docs').
>
> They both include documentation in "built" form (PDFs and HTML files), and javadocs.
>
> The OSGi form has a special MANIFEST.MF file, and doesn't include documentation
> or javadocs.
>
> The zip/tar-ing of these is somewhat different:  single-project has a zip/tar
> assembly, PEAR has a zip (the *.PEAR file), and the OSGi has a JAR (which is of
> course, a zip).  In addition, the addons "aggregate" of all the addon projects
> has all of them zipped/tarred up together.
>
> There is also for most things, a standard JAR packaging of just the core
> annotator, containing class/ directory.
>
> The OSGi build as far as I can tell *requires* (by which I mean that I couldn't
> figure out how to override this) that the main set of classes be in the standard
> ${project.build.outputDirectory}.  In contrast, the PEAR and single-project
> build are packaging the main set of classes by letting the standard JAR plugin
> package them as a jar, and then including that JAR in the lib/ of the zip/tar. 
> So the lib/ of those packagings is slightly different from the lib/ of the OSGi
> packaging - in that the OSGi doesn't have the main set of classes as a separate
> inside its lib/ directory.
>
> The build logic for these eventually should be in the build/ part, in the
> overall parent-pom, and in the related uima-build-resources project.  But for
> now we are having addons-level overrides for this in the uima-addons-parent pom,
> and for uima-addons aggregate assembly, in the src/main/assembly directory.
>
> It seems that a small bit of restructuring would help in the overall building of
> things.  This would have a common part of these build steps do the collection of
> all the parts that are destined to go into the zip/tar etc. 
>
> The single-project build and the PEAR have the most in common, the OSGi the least.
>
> I'm currently thinking that all addons should include a single-project build
> (zip/tar).
> Those marked as PEARs should also have a PEAR build.
> Those marked as OSGi should also have an OSGi build.
>
> The binary addons aggregate I think should drop the individual single-project
> zip/tar - there's little value to having this done 2x.
>
> For uploading to Maven repository: the main Jar is uploaded, the source-release
> is uploaded, and it would seem to make sense to upload the PEAR and the OSGi
> zips, too. So the only thing not uploaded would be the single-project zip/tar.
>
> Does this seem right to others?
>
> I'll work on refactoring the addons build to take advantage of all this
> commonality :-)
>
> -Marshall
>
>

Re: binary builds in addons

[Richard Eckart de Castilho <ec...@tk.informatik.tu-darmstadt.de>]

>> Unless somebody steps forward with a use-case in which PEARs are really resolved from a Maven Repository, I'd opt against uploading PEARs.
> 
> Hmmm, not uploading PEARs would break users who are using the technique
> described in the above thread (
> 
> http://uima.markmail.org/thread/ijq7adeiic6hpfta )  which seems might be worse than the confusion.

Maybe we could ask Greg if he actually did end up using the approach hinted at in this thread. If I understand the progress of the thread correctly, Greg wanted a zero-install approach and the discussion drifted towards OSGi after that. I can't see that the idea of downloading PEARs from a Maven Repository ended up in a success story.

-- Richard

-- 
------------------------------------------------------------------- 
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab 
FB 20 Computer Science Department      
Technische Universität Darmstadt 
Hochschulstr. 10, D-64289 Darmstadt, Germany 
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
eckartde@tk.informatik.tu-darmstadt.de 
www.ukp.tu-darmstadt.de 
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
------------------------------------------------------------------- 

Re: binary builds in addons

[Marshall Schor <ms...@schor.com>]

On 8/3/2011 10:23 AM, Richard Eckart de Castilho wrote:
>>>> For uploading to Maven repository: the main Jar is uploaded, the source-release
>>>> is uploaded, and it would seem to make sense to upload the PEAR and the OSGi
>>>> zips, too. So the only thing not uploaded would be the single-project zip/tar.
>>> Why would the PEARs go into Maven? As far as I know, it's not possible to add them as a dependency and use them in a Java project?
>> Thinking off the top of my head (so this may be a little off ...).
>>
>> You can use various maven plugins to "access" the PEAR artifact, and have a
>> build which "downloads" a particular version from a maven repo and "installs" it
>> on the local machine, after which it could be added to a pipeline, etc.
>>
>> This has also been discussed somewhat here:
>> http://uima.markmail.org/thread/ijq7adeiic6hpfta
> Sure, you can use Maven to resolve a GAV to a PEAR artifact and then install that. But the point is that you have to install it - it cannot work out-of-the-box. I think having the PEARs on Maven Central causes more confusion than it does good when people start searching for UIMA artifacts, e.g. using tooling like m2eclipse. On the other hand, I doubt that any serious build process would download PEARs and install them - a deploy process might.
>
> Unless somebody steps forward with a use-case in which PEARs are really resolved from a Maven Repository, I'd opt against uploading PEARs.

Hmmm, not uploading PEARs would break users who are using the technique
described in the above thread (

http://uima.markmail.org/thread/ijq7adeiic6hpfta )  which seems might be worse than the confusion.

-Marshall

<http://uima.markmail.org/thread/ijq7adeiic6hpfta>

>
> Cheers,
>
> Richard
>

Re: binary builds in addons

[Richard Eckart de Castilho <ec...@tk.informatik.tu-darmstadt.de>]

>>> For uploading to Maven repository: the main Jar is uploaded, the source-release
>>> is uploaded, and it would seem to make sense to upload the PEAR and the OSGi
>>> zips, too. So the only thing not uploaded would be the single-project zip/tar.
>> Why would the PEARs go into Maven? As far as I know, it's not possible to add them as a dependency and use them in a Java project?
> 
> Thinking off the top of my head (so this may be a little off ...).
> 
> You can use various maven plugins to "access" the PEAR artifact, and have a
> build which "downloads" a particular version from a maven repo and "installs" it
> on the local machine, after which it could be added to a pipeline, etc.
> 
> This has also been discussed somewhat here:
> http://uima.markmail.org/thread/ijq7adeiic6hpfta

Sure, you can use Maven to resolve a GAV to a PEAR artifact and then install that. But the point is that you have to install it - it cannot work out-of-the-box. I think having the PEARs on Maven Central causes more confusion than it does good when people start searching for UIMA artifacts, e.g. using tooling like m2eclipse. On the other hand, I doubt that any serious build process would download PEARs and install them - a deploy process might.

Unless somebody steps forward with a use-case in which PEARs are really resolved from a Maven Repository, I'd opt against uploading PEARs.

Cheers,

Richard

-- 
------------------------------------------------------------------- 
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab 
FB 20 Computer Science Department      
Technische Universität Darmstadt 
Hochschulstr. 10, D-64289 Darmstadt, Germany 
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
eckartde@tk.informatik.tu-darmstadt.de 
www.ukp.tu-darmstadt.de 
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
------------------------------------------------------------------- 

Re: binary builds in addons

[Marshall Schor <ms...@schor.com>]

On 7/27/2011 3:21 AM, Richard Eckart de Castilho wrote:
> Am 26.07.2011 um 22:48 schrieb Marshall Schor:
>
>> For uploading to Maven repository: the main Jar is uploaded, the source-release
>> is uploaded, and it would seem to make sense to upload the PEAR and the OSGi
>> zips, too. So the only thing not uploaded would be the single-project zip/tar.
> Why would the PEARs go into Maven? As far as I know, it's not possible to add them as a dependency and use them in a Java project?

Thinking off the top of my head (so this may be a little off ...).

You can use various maven plugins to "access" the PEAR artifact, and have a
build which "downloads" a particular version from a maven repo and "installs" it
on the local machine, after which it could be added to a pipeline, etc.

This has also been discussed somewhat here:
http://uima.markmail.org/thread/ijq7adeiic6hpfta

-Marshall
>
> Cheers,
>
> Richard
>

Re: binary builds in addons

[Richard Eckart de Castilho <ec...@tk.informatik.tu-darmstadt.de>]

Am 26.07.2011 um 22:48 schrieb Marshall Schor:

> For uploading to Maven repository: the main Jar is uploaded, the source-release
> is uploaded, and it would seem to make sense to upload the PEAR and the OSGi
> zips, too. So the only thing not uploaded would be the single-project zip/tar.

Why would the PEARs go into Maven? As far as I know, it's not possible to add them as a dependency and use them in a Java project?

Cheers,

Richard

-- 
------------------------------------------------------------------- 
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab 
FB 20 Computer Science Department      
Technische Universität Darmstadt 
Hochschulstr. 10, D-64289 Darmstadt, Germany 
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
eckartde@tk.informatik.tu-darmstadt.de 
www.ukp.tu-darmstadt.de 
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
------------------------------------------------------------------- 

Re: binary builds in addons

[Tommaso Teofili <to...@gmail.com>]

2011/7/26 Marshall Schor <ms...@schor.com>

> Now that I've prototyped the osgi build (not yet checked in), and revisited
> the
> other binary builds, it seems there's a lot of similarity among these.
>
> I think there are 3 kinds:
>
> 1) single-project build - like FsVariables, and SimpleServer
> 2) PEARs
> 3) OSGi
>
> The single-project and PEARs seem almost identical, except the PEARs have a
> special install.xml file (for installing the PEAR).  (One superficial
> difference
> is that the docs directory in PEARs is "doc", and in single-projects, is
> 'docs').
>
> They both include documentation in "built" form (PDFs and HTML files), and
> javadocs.
>
> The OSGi form has a special MANIFEST.MF file, and doesn't include
> documentation
> or javadocs.
>
> The zip/tar-ing of these is somewhat different:  single-project has a
> zip/tar
> assembly, PEAR has a zip (the *.PEAR file), and the OSGi has a JAR (which
> is of
> course, a zip).  In addition, the addons "aggregate" of all the addon
> projects
> has all of them zipped/tarred up together.
>
> There is also for most things, a standard JAR packaging of just the core
> annotator, containing class/ directory.
>
> The OSGi build as far as I can tell *requires* (by which I mean that I
> couldn't
> figure out how to override this) that the main set of classes be in the
> standard
> ${project.build.outputDirectory}.  In contrast, the PEAR and single-project
> build are packaging the main set of classes by letting the standard JAR
> plugin
> package them as a jar, and then including that JAR in the lib/ of the
> zip/tar.
> So the lib/ of those packagings is slightly different from the lib/ of the
> OSGi
> packaging - in that the OSGi doesn't have the main set of classes as a
> separate
> inside its lib/ directory.
>
> The build logic for these eventually should be in the build/ part, in the
> overall parent-pom, and in the related uima-build-resources project.  But
> for
> now we are having addons-level overrides for this in the uima-addons-parent
> pom,
> and for uima-addons aggregate assembly, in the src/main/assembly directory.
>
> It seems that a small bit of restructuring would help in the overall
> building of
> things.  This would have a common part of these build steps do the
> collection of
> all the parts that are destined to go into the zip/tar etc.
>
> The single-project build and the PEAR have the most in common, the OSGi the
> least.
>
> I'm currently thinking that all addons should include a single-project
> build
> (zip/tar).
> Those marked as PEARs should also have a PEAR build.
> Those marked as OSGi should also have an OSGi build.
>
> The binary addons aggregate I think should drop the individual
> single-project
> zip/tar - there's little value to having this done 2x.
>
> For uploading to Maven repository: the main Jar is uploaded, the
> source-release
> is uploaded, and it would seem to make sense to upload the PEAR and the
> OSGi
> zips, too. So the only thing not uploaded would be the single-project
> zip/tar.
>
> Does this seem right to others?
>
>
yes Marshall, that seems very nice to me and, by the way, thanks for taking
care of enhancing/refactoring this stuff.
Tommaso


> I'll work on refactoring the addons build to take advantage of all this
> commonality :-)
>
> -Marshall
>
>