You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de> on 2012/07/01 12:05:50 UTC
Re: TextMarker maven build process update
Am 28.06.2012 um 17:34 schrieb Peter Klügl:
> Is a repository for the bundles an option for us?
How about doing a third-party deploy to Maven Central?
https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository
Apache also runs a Nexus instance, maybe that would be an option?
I'm not sure if there is any strict policy for Maven Repositories to keep normal JARs and OSGi JARs separate from each other.
-- Richard
--
-------------------------------------------------------------------
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab (UKP-TUD)
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
eckart@ukp.informatik.tu-darmstadt.de
www.ukp.tu-darmstadt.de
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
-------------------------------------------------------------------
Re: TextMarker maven build process update
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
On 04.07.2012 18:00, Peter Klügl wrote:
> On 04.07.2012 17:23, Marshall Schor wrote:
>> On 7/4/2012 7:27 AM, Peter Klügl wrote:
>>> On 03.07.2012 23:27, Marshall Schor wrote:
>>>> On 7/3/2012 8:39 AM, Peter Klügl wrote:
>>>>> Hi,
>>>>>
>>>>> I don't know. On the one side, this would of course solve our
>>>>> problems. On the
>>>>> other side, this approach does not scale well with the amount of
>>>>> plugins the
>>>>> TextMarker IDE depends on.
>>>> I'm thinking that if we went this way, you would take some level of
>>>> Eclipse
>>>> release and post *all* of its parts (if that was allowed). I
>>>> thought that's
>>>> what the maven-eclipse-plugin -- to maven mojo did (but I haven't
>>>> used it, so
>>>> that's just a guess...). If that was the case, then no further
>>>> updates would be
>>>> needed unless or until you decided to "depend" on some more recent
>>>> Eclipse
>>>> plugin version / feature.
>>>>
>>>> So, I'm not understanding why it would not scale well...
>>>>
>>> I thought that you have to provide a bundle with eight files for
>>> each jar you
>>> want to add to the Maven Central (I interpreted Richard's link that
>>> way).
>>> Those also cover javadoc and sources. Gathering all that stuff
>>> manually for
>>> each dependency would be some work. "eclipse:to-maven" adds the
>>> artifacts to
>>> the local repository. Maybe I missed something or we are talking about
>>> something different.
>> OK - I haven't used eclipse:to-maven myself. I thought it might
>> gather all the
>> stuff needed automatically, and put it into the local repo, but
>> could, just as
>> easily, deliver it to maven central. But, I don't know...
>>
>
> That option would come handy, but I don't know about it either.
There is of course the parameter "deployTo", which we (someone with
rights) could probably use to fill the maven repository of the build
server without touching the eclipse installation there. I don't know,
but I doubt that we could fill any repository.
Peter
Re: TextMarker maven build process update
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
On 04.07.2012 17:23, Marshall Schor wrote:
> On 7/4/2012 7:27 AM, Peter Klügl wrote:
>> On 03.07.2012 23:27, Marshall Schor wrote:
>>> On 7/3/2012 8:39 AM, Peter Klügl wrote:
>>>> Hi,
>>>>
>>>> I don't know. On the one side, this would of course solve our problems. On the
>>>> other side, this approach does not scale well with the amount of plugins the
>>>> TextMarker IDE depends on.
>>> I'm thinking that if we went this way, you would take some level of Eclipse
>>> release and post *all* of its parts (if that was allowed). I thought that's
>>> what the maven-eclipse-plugin -- to maven mojo did (but I haven't used it, so
>>> that's just a guess...). If that was the case, then no further updates would be
>>> needed unless or until you decided to "depend" on some more recent Eclipse
>>> plugin version / feature.
>>>
>>> So, I'm not understanding why it would not scale well...
>>>
>> I thought that you have to provide a bundle with eight files for each jar you
>> want to add to the Maven Central (I interpreted Richard's link that way).
>> Those also cover javadoc and sources. Gathering all that stuff manually for
>> each dependency would be some work. "eclipse:to-maven" adds the artifacts to
>> the local repository. Maybe I missed something or we are talking about
>> something different.
> OK - I haven't used eclipse:to-maven myself. I thought it might gather all the
> stuff needed automatically, and put it into the local repo, but could, just as
> easily, deliver it to maven central. But, I don't know...
>
That option would come handy, but I don't know about it either.
>> I think using "eclipse:to-maven" works well enough for now. If a user wants to
>> build the TextMarker plugins, we could mention in the documentation how to do
>> that. Can we install dltk 3.0 in the eclipse installation on the build server
>> and can we post all bundles to the local repository of the build server?
> By build server, do you mean "Jenkins"? If so, it's quite likely infra could
> instal dltk (Eclipse Dynamic Language Took Kit) 3.0 and an Eclipse installation
> of some level, on the Jenkins servers.
>
> What do you use the dltk for?
>
Hmm, yes, I probably meant Jenkins. I can build the TextMarker plugins
on my local machine. Then, the question is: Who else needs to be able to
build it (Jenkins some time in future maybe) and are the requirements
for that reasonable?
The TextMarker IDE is based on DLTK, e.g., project nature, editor
support, preferences, launch configuration and so on.
> -Marshall
>>
>>>> Additionally, I have the strong feeling that "really many" developers of
>>>> maven-built plugins propagte the p2 repositories and that doing the opposite
>>>> isn't the best way to go.
>>> Hi Peter, can you say a bit more here? Do you mean that there's a general move,
>>> for Eclipse plugin projects, to not be using repositories hosted by Maven
>>> Central, but instead to use some other "p2" repositories? Is there a "central"
>>> spot for p2 repositories - or are these just the many Eclipse update sites that
>>> are all around the internet?
>>>
>> I am still new to maven and I have actually no clue at all. But this was my
>> observation:
>> - there are no latest plugins in the central repositories, e.g.,
>> org.eclipse.ui.views only in version 3.2
>> - there are no artifacts available for eclipse plugins that were built with
>> maven, e.g., DLTK. Or I haven't found them.
> UIMA Eclipse plugin artifacts, e.g., the uimaj-ep-debug artifact, built with
> maven, are on maven central, for example, here:
> http://central.maven.org/maven2/org/apache/uima/uimaj-ep-debug/
>
> But perhaps that's not what you mean.
>
You are of course correct. I was thinking of the plugins TextMarker
depends on. I assume that there are several developers of eclipse
plugins that are using maven and whose plugins depend on, e.g.,
org.eclipse.ui.views in a version >3.3. If they are using Felix, they
all need some special solution to resolve their dependencies or I missed
something.
> Also, the "normal" way of consuming Eclipse plugins is to use Eclipse's "update
> site" mechanism,
Yes, and this was probably one motivation to resolve dependencies also
with update sites.
> so we have a post-build / post-release step that takes new
> Eclipse plugins and/or fragments (or new versions of existing ones) and packages
> them as an eclipse update site.
>> - the developers of eclipse plugins built with maven probably use p2
>> repositories, at least the DLTK developers do and recommended that
>>
>> In summary, this looks to me that there is a tendency towards p2 for
>> dependencies to eclipse plugins.
>>
>> You specify the p2 repository in the pom like any other maven repository (I
>> think):
>>
>> <repositories>
>> <repository>
>> <id>eclipse-indigo</id>
>> <layout>p2</layout>
>> <url>http://download.eclipse.org/releases/indigo</url>
>> </repository>
>> </repositories>
> I didn't know about this. There may be some special "version" of maven needed
> for this. A search on the web for maven model turned up this spec for the 3.0.4
> (current, I think) version: http://maven.apache.org/ref/3.0.4/maven-model/maven.html
>
> and if you search for<layout> it says the only values allowed are "default" and
> "legacy"; it doesn't mention p2. This might be an extension only usable by
> systems such as Tycho.
>
Yes, Tycho is able to use this. If Felix were able to resolve that, then
I would have (maybe) made more progress.
Peter
> -Marshall
>> I think p2 repositories and update sites are the same (update site is
>> deprecated). So you have a repository for each eclipse release.
>>
>> If the TextMarker IDE build the manifest-first way would work, or better if I
>> get it to work, the build process is easier and nicer.
>>
>> Another idea maybe: what if we decouple the build of the language/inferencer
>> (uimaj-textmarker) which you need to use TextMarker in any java project, from
>> the IDE for developing the rules and further tooling? We could build
>> uimaj-textmarker and manually add the jar as a library to the IDE plugin. It's
>> an ugly solution, but could work well enough.
>>
>> Best,
>>
>> Peter
>>
>>
--
---------------------------------------------------------------------
Dipl.-Inf. Peter Klügl
Universität Würzburg Tel.: +49-(0)931-31-86741
Am Hubland Fax.: +49-(0)931-31-86732
97074 Würzburg mail: pkluegl@informatik.uni-wuerzburg.de
http://www.is.informatik.uni-wuerzburg.de/en/staff/kluegl_peter/
---------------------------------------------------------------------
Re: TextMarker maven build process update
Posted by Marshall Schor <ms...@schor.com>.
On 7/4/2012 7:27 AM, Peter Klügl wrote:
> On 03.07.2012 23:27, Marshall Schor wrote:
>> On 7/3/2012 8:39 AM, Peter Klügl wrote:
>>> Hi,
>>>
>>> I don't know. On the one side, this would of course solve our problems. On the
>>> other side, this approach does not scale well with the amount of plugins the
>>> TextMarker IDE depends on.
>> I'm thinking that if we went this way, you would take some level of Eclipse
>> release and post *all* of its parts (if that was allowed). I thought that's
>> what the maven-eclipse-plugin -- to maven mojo did (but I haven't used it, so
>> that's just a guess...). If that was the case, then no further updates would be
>> needed unless or until you decided to "depend" on some more recent Eclipse
>> plugin version / feature.
>>
>> So, I'm not understanding why it would not scale well...
>>
>
> I thought that you have to provide a bundle with eight files for each jar you
> want to add to the Maven Central (I interpreted Richard's link that way).
> Those also cover javadoc and sources. Gathering all that stuff manually for
> each dependency would be some work. "eclipse:to-maven" adds the artifacts to
> the local repository. Maybe I missed something or we are talking about
> something different.
OK - I haven't used eclipse:to-maven myself. I thought it might gather all the
stuff needed automatically, and put it into the local repo, but could, just as
easily, deliver it to maven central. But, I don't know...
>
> I think using "eclipse:to-maven" works well enough for now. If a user wants to
> build the TextMarker plugins, we could mention in the documentation how to do
> that. Can we install dltk 3.0 in the eclipse installation on the build server
> and can we post all bundles to the local repository of the build server?
By build server, do you mean "Jenkins"? If so, it's quite likely infra could
instal dltk (Eclipse Dynamic Language Took Kit) 3.0 and an Eclipse installation
of some level, on the Jenkins servers.
What do you use the dltk for?
-Marshall
>
>
>>> Additionally, I have the strong feeling that "really many" developers of
>>> maven-built plugins propagte the p2 repositories and that doing the opposite
>>> isn't the best way to go.
>> Hi Peter, can you say a bit more here? Do you mean that there's a general move,
>> for Eclipse plugin projects, to not be using repositories hosted by Maven
>> Central, but instead to use some other "p2" repositories? Is there a "central"
>> spot for p2 repositories - or are these just the many Eclipse update sites that
>> are all around the internet?
>>
>
> I am still new to maven and I have actually no clue at all. But this was my
> observation:
> - there are no latest plugins in the central repositories, e.g.,
> org.eclipse.ui.views only in version 3.2
> - there are no artifacts available for eclipse plugins that were built with
> maven, e.g., DLTK. Or I haven't found them.
UIMA Eclipse plugin artifacts, e.g., the uimaj-ep-debug artifact, built with
maven, are on maven central, for example, here:
http://central.maven.org/maven2/org/apache/uima/uimaj-ep-debug/
But perhaps that's not what you mean.
Also, the "normal" way of consuming Eclipse plugins is to use Eclipse's "update
site" mechanism, so we have a post-build / post-release step that takes new
Eclipse plugins and/or fragments (or new versions of existing ones) and packages
them as an eclipse update site.
> - the developers of eclipse plugins built with maven probably use p2
> repositories, at least the DLTK developers do and recommended that
>
> In summary, this looks to me that there is a tendency towards p2 for
> dependencies to eclipse plugins.
>
> You specify the p2 repository in the pom like any other maven repository (I
> think):
>
> <repositories>
> <repository>
> <id>eclipse-indigo</id>
> <layout>p2</layout>
> <url>http://download.eclipse.org/releases/indigo</url>
> </repository>
> </repositories>
I didn't know about this. There may be some special "version" of maven needed
for this. A search on the web for maven model turned up this spec for the 3.0.4
(current, I think) version: http://maven.apache.org/ref/3.0.4/maven-model/maven.html
and if you search for <layout> it says the only values allowed are "default" and
"legacy"; it doesn't mention p2. This might be an extension only usable by
systems such as Tycho.
-Marshall
>
> I think p2 repositories and update sites are the same (update site is
> deprecated). So you have a repository for each eclipse release.
>
> If the TextMarker IDE build the manifest-first way would work, or better if I
> get it to work, the build process is easier and nicer.
>
> Another idea maybe: what if we decouple the build of the language/inferencer
> (uimaj-textmarker) which you need to use TextMarker in any java project, from
> the IDE for developing the rules and further tooling? We could build
> uimaj-textmarker and manually add the jar as a library to the IDE plugin. It's
> an ugly solution, but could work well enough.
>
> Best,
>
> Peter
>
>
Re: TextMarker maven build process update
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
On 03.07.2012 23:27, Marshall Schor wrote:
> On 7/3/2012 8:39 AM, Peter Klügl wrote:
>> Hi,
>>
>> I don't know. On the one side, this would of course solve our problems. On the
>> other side, this approach does not scale well with the amount of plugins the
>> TextMarker IDE depends on.
> I'm thinking that if we went this way, you would take some level of Eclipse
> release and post *all* of its parts (if that was allowed). I thought that's
> what the maven-eclipse-plugin -- to maven mojo did (but I haven't used it, so
> that's just a guess...). If that was the case, then no further updates would be
> needed unless or until you decided to "depend" on some more recent Eclipse
> plugin version / feature.
>
> So, I'm not understanding why it would not scale well...
>
I thought that you have to provide a bundle with eight files for each
jar you want to add to the Maven Central (I interpreted Richard's link
that way). Those also cover javadoc and sources. Gathering all that
stuff manually for each dependency would be some work.
"eclipse:to-maven" adds the artifacts to the local repository. Maybe I
missed something or we are talking about something different.
I think using "eclipse:to-maven" works well enough for now. If a user
wants to build the TextMarker plugins, we could mention in the
documentation how to do that. Can we install dltk 3.0 in the eclipse
installation on the build server and can we post all bundles to the
local repository of the build server?
>> Additionally, I have the strong feeling that "really many" developers of
>> maven-built plugins propagte the p2 repositories and that doing the opposite
>> isn't the best way to go.
> Hi Peter, can you say a bit more here? Do you mean that there's a general move,
> for Eclipse plugin projects, to not be using repositories hosted by Maven
> Central, but instead to use some other "p2" repositories? Is there a "central"
> spot for p2 repositories - or are these just the many Eclipse update sites that
> are all around the internet?
>
I am still new to maven and I have actually no clue at all. But this was
my observation:
- there are no latest plugins in the central repositories, e.g.,
org.eclipse.ui.views only in version 3.2
- there are no artifacts available for eclipse plugins that were built
with maven, e.g., DLTK. Or I haven't found them.
- the developers of eclipse plugins built with maven probably use p2
repositories, at least the DLTK developers do and recommended that
In summary, this looks to me that there is a tendency towards p2 for
dependencies to eclipse plugins.
You specify the p2 repository in the pom like any other maven repository
(I think):
<repositories>
<repository>
<id>eclipse-indigo</id>
<layout>p2</layout>
<url>http://download.eclipse.org/releases/indigo</url>
</repository>
</repositories>
I think p2 repositories and update sites are the same (update site is
deprecated). So you have a repository for each eclipse release.
If the TextMarker IDE build the manifest-first way would work, or better
if I get it to work, the build process is easier and nicer.
Another idea maybe: what if we decouple the build of the
language/inferencer (uimaj-textmarker) which you need to use TextMarker
in any java project, from the IDE for developing the rules and further
tooling? We could build uimaj-textmarker and manually add the jar as a
library to the IDE plugin. It's an ugly solution, but could work well
enough.
Best,
Peter
Re: TextMarker maven build process update
Posted by Marshall Schor <ms...@schor.com>.
On 7/3/2012 8:39 AM, Peter Klügl wrote:
> Hi,
>
> I don't know. On the one side, this would of course solve our problems. On the
> other side, this approach does not scale well with the amount of plugins the
> TextMarker IDE depends on.
I'm thinking that if we went this way, you would take some level of Eclipse
release and post *all* of its parts (if that was allowed). I thought that's
what the maven-eclipse-plugin -- to maven mojo did (but I haven't used it, so
that's just a guess...). If that was the case, then no further updates would be
needed unless or until you decided to "depend" on some more recent Eclipse
plugin version / feature.
So, I'm not understanding why it would not scale well...
> Additionally, I have the strong feeling that "really many" developers of
> maven-built plugins propagte the p2 repositories and that doing the opposite
> isn't the best way to go.
Hi Peter, can you say a bit more here? Do you mean that there's a general move,
for Eclipse plugin projects, to not be using repositories hosted by Maven
Central, but instead to use some other "p2" repositories? Is there a "central"
spot for p2 repositories - or are these just the many Eclipse update sites that
are all around the internet?
Marshall
>
> I'd propose that we keep the pom-first approach for the TextMarker plugins for
> now (however I'll switch to eclipse:to-maven). I boost first the status of
> the TextMarker projects so that a release is reasonable (remaining issues,
> documentation). Then, we could find a solution how to automatically build the
> projects, probably the way Marshall pointed out. In the meanwhile, I also work
> a bit more on the manifest-first approach when I find the time and I'm not too
> annoyed of it.
>
> Peter
>
>
> On 01.07.2012 12:05, Richard Eckart de Castilho wrote:
>> Am 28.06.2012 um 17:34 schrieb Peter Klügl:
>>
>>> Is a repository for the bundles an option for us?
>> How about doing a third-party deploy to Maven Central?
>>
>> https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository
>>
>>
>> Apache also runs a Nexus instance, maybe that would be an option?
>>
>> I'm not sure if there is any strict policy for Maven Repositories to keep
>> normal JARs and OSGi JARs separate from each other.
>>
>> -- Richard
>>
>
>
Re: TextMarker maven build process update
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Hi,
I don't know. On the one side, this would of course solve our problems.
On the other side, this approach does not scale well with the amount of
plugins the TextMarker IDE depends on. Additionally, I have the strong
feeling that "really many" developers of maven-built plugins propagte
the p2 repositories and that doing the opposite isn't the best way to go.
I'd propose that we keep the pom-first approach for the TextMarker
plugins for now (however I'll switch to eclipse:to-maven). I boost first
the status of the TextMarker projects so that a release is reasonable
(remaining issues, documentation). Then, we could find a solution how to
automatically build the projects, probably the way Marshall pointed out.
In the meanwhile, I also work a bit more on the manifest-first approach
when I find the time and I'm not too annoyed of it.
Peter
On 01.07.2012 12:05, Richard Eckart de Castilho wrote:
> Am 28.06.2012 um 17:34 schrieb Peter Klügl:
>
>> Is a repository for the bundles an option for us?
> How about doing a third-party deploy to Maven Central?
>
> https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository
>
> Apache also runs a Nexus instance, maybe that would be an option?
>
> I'm not sure if there is any strict policy for Maven Repositories to keep normal JARs and OSGi JARs separate from each other.
>
> -- Richard
>
--
---------------------------------------------------------------------
Dipl.-Inf. Peter Klügl
Universität Würzburg Tel.: +49-(0)931-31-86741
Am Hubland Fax.: +49-(0)931-31-86732
97074 Würzburg mail: pkluegl@informatik.uni-wuerzburg.de
http://www.is.informatik.uni-wuerzburg.de/en/staff/kluegl_peter/
---------------------------------------------------------------------