You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Peter Klügl <pk...@uni-wuerzburg.de> on 2012/06/15 16:08:10 UTC
TextMarker maven build process update
Hi,
Just a short update, why there isn't a working TextMarker build yet.
I am still stuck with defining a working build process for the
TextMarker bundles. The problem is that the combination of
manifest-first and pom-first bundles does not work correctly (as it
should), and I haven't found my error yet.
After a lot of reading, I am sure that the normal Eclipse plugins should
be built with a manifest-first approach. However, there is a limitation
that pom-first and manifest-first projects cannot be mixed in the same
reactor build. Will this be a problem in future for building/releasing
the TextMarker projects?
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 Peter Klügl <pk...@uni-wuerzburg.de>.
I searched there for the missing bundles when I created the current
build process, but haven't found them. I'll take a look again...
Peter
Am 28.06.2012 20:29, schrieb Marshall Schor:
> I'm not sure what Eclipse artifacts you need; did you try seeing if they are in
> this repository:
>
> http://maven.eclipse.org/nexus/index.html#welcome?
>
> -Marshall
> On 6/28/2012 12:58 PM, Peter Klügl wrote:
>> On 28.06.2012 17:44, Marshall Schor wrote:
>>> If a public repo can't be found, do you use the
>>> http://maven.apache.org/plugins/maven-eclipse-plugin/to-maven-mojo.html plugin
>>> for adding the eclipse plugins to the local repo, as part of your build?
>>>
>>> -Marshall
>>>
>> Yes, I am doing this right now manually with eclipse:make-artifacts
>> (http://maven.apache.org/plugins/maven-eclipse-plugin/make-artifacts-mojo.html).
>> My maven knowledge isn't yet good enough to get the idea to include that in
>> the build process. That a good idea, but won't we get problems for an
>> automatic build in future since you have to provide the Eclipse installation
>> dir? Could we provide that on a build server some time in future?
>>
>> Peter
>>
>>
>>
>>> On 6/28/2012 11:38 AM, Marshall Schor wrote:
>>>> Is there not a "public" repository for the bundles you need? I'm looking
>>>> around
>>>> for one...
>>>>
>>>> -Marshall
>>>> On 6/28/2012 11:34 AM, Peter Klügl wrote:
>>>>> Hi,
>>>>>
>>>>>> Hi Peter,
>>>>>>
>>>>>> I'm sorry if I've missed the thread - has it been discussed why the Eclipse
>>>>>> plugins can't be built with the pom-first approach that our current Eclipse
>>>>>> plugins are built with?
>>>>>>
>>>>> No, they can be and are actually built this way right now. Everything works
>>>>> fine, if you add a complete Eclipse Indigo release with DLTK Core 3.0
>>>>> installed to your local maven repository. I think that the pom-first build is
>>>>> only reasonable if the user does not have to do that, but we can provide a
>>>>> repository like that somehow.
>>>>>
>>>>> Building the bundles the manifest-first way does not have such problems
>>>>> because the dependencies are automatically resolved using p2 repositories. In
>>>>> my opinion, that is a much nicer solution and should work just fine. However,
>>>>> after the time I spent with this problem and with hardly any progress, I must
>>>>> admit that I don't care too much anymore about how the bundles are built.
>>>>>
>>>>> Is a repository for the bundles an option for us?
>>>>>
>>>>> Best,
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>
Re: TextMarker maven build process update
Posted by Marshall Schor <ms...@schor.com>.
I'm not sure what Eclipse artifacts you need; did you try seeing if they are in
this repository:
http://maven.eclipse.org/nexus/index.html#welcome?
-Marshall
On 6/28/2012 12:58 PM, Peter Klügl wrote:
> On 28.06.2012 17:44, Marshall Schor wrote:
>> If a public repo can't be found, do you use the
>> http://maven.apache.org/plugins/maven-eclipse-plugin/to-maven-mojo.html plugin
>> for adding the eclipse plugins to the local repo, as part of your build?
>>
>> -Marshall
>>
>
> Yes, I am doing this right now manually with eclipse:make-artifacts
> (http://maven.apache.org/plugins/maven-eclipse-plugin/make-artifacts-mojo.html).
> My maven knowledge isn't yet good enough to get the idea to include that in
> the build process. That a good idea, but won't we get problems for an
> automatic build in future since you have to provide the Eclipse installation
> dir? Could we provide that on a build server some time in future?
>
> Peter
>
>
>
>> On 6/28/2012 11:38 AM, Marshall Schor wrote:
>>> Is there not a "public" repository for the bundles you need? I'm looking
>>> around
>>> for one...
>>>
>>> -Marshall
>>> On 6/28/2012 11:34 AM, Peter Klügl wrote:
>>>> Hi,
>>>>
>>>>> Hi Peter,
>>>>>
>>>>> I'm sorry if I've missed the thread - has it been discussed why the Eclipse
>>>>> plugins can't be built with the pom-first approach that our current Eclipse
>>>>> plugins are built with?
>>>>>
>>>> No, they can be and are actually built this way right now. Everything works
>>>> fine, if you add a complete Eclipse Indigo release with DLTK Core 3.0
>>>> installed to your local maven repository. I think that the pom-first build is
>>>> only reasonable if the user does not have to do that, but we can provide a
>>>> repository like that somehow.
>>>>
>>>> Building the bundles the manifest-first way does not have such problems
>>>> because the dependencies are automatically resolved using p2 repositories. In
>>>> my opinion, that is a much nicer solution and should work just fine. However,
>>>> after the time I spent with this problem and with hardly any progress, I must
>>>> admit that I don't care too much anymore about how the bundles are built.
>>>>
>>>> Is a repository for the bundles an option for us?
>>>>
>>>> Best,
>>>>
>>>> Peter
>>>>
>>>>
>>>
>
>
Re: TextMarker maven build process update
Posted by Marshall Schor <ms...@schor.com>.
It seems to me that of the many possible alternatives, we should do either the
automated build or find the needed artifacts on some stable server somewhere
(e.g. maven central or ???)
We already require a "local" eclipse installation for building the Eclipse
update site - the pointer to that is specified in your maven settings file (see:
http://uima.apache.org/one-time-release-setup.htmlin particular the lines:
<properties>
<uima-maven-build-eclipse-home>C:/p/eclipse/3.5/eclipse</uima-maven-build-eclipse-home>
I don't think getting another shared public maven repo just for our project is
the right direction.
-Marshall
On 6/28/2012 12:58 PM, Peter Klügl wrote:
> On 28.06.2012 17:44, Marshall Schor wrote:
>> If a public repo can't be found, do you use the
>> http://maven.apache.org/plugins/maven-eclipse-plugin/to-maven-mojo.html plugin
>> for adding the eclipse plugins to the local repo, as part of your build?
>>
>> -Marshall
>>
>
> Yes, I am doing this right now manually with eclipse:make-artifacts
> (http://maven.apache.org/plugins/maven-eclipse-plugin/make-artifacts-mojo.html).
> My maven knowledge isn't yet good enough to get the idea to include that in
> the build process. That a good idea, but won't we get problems for an
> automatic build in future since you have to provide the Eclipse installation
> dir? Could we provide that on a build server some time in future?
>
> Peter
>
>
>
>> On 6/28/2012 11:38 AM, Marshall Schor wrote:
>>> Is there not a "public" repository for the bundles you need? I'm looking
>>> around
>>> for one...
>>>
>>> -Marshall
>>> On 6/28/2012 11:34 AM, Peter Klügl wrote:
>>>> Hi,
>>>>
>>>>> Hi Peter,
>>>>>
>>>>> I'm sorry if I've missed the thread - has it been discussed why the Eclipse
>>>>> plugins can't be built with the pom-first approach that our current Eclipse
>>>>> plugins are built with?
>>>>>
>>>> No, they can be and are actually built this way right now. Everything works
>>>> fine, if you add a complete Eclipse Indigo release with DLTK Core 3.0
>>>> installed to your local maven repository. I think that the pom-first build is
>>>> only reasonable if the user does not have to do that, but we can provide a
>>>> repository like that somehow.
>>>>
>>>> Building the bundles the manifest-first way does not have such problems
>>>> because the dependencies are automatically resolved using p2 repositories. In
>>>> my opinion, that is a much nicer solution and should work just fine. However,
>>>> after the time I spent with this problem and with hardly any progress, I must
>>>> admit that I don't care too much anymore about how the bundles are built.
>>>>
>>>> Is a repository for the bundles an option for us?
>>>>
>>>> Best,
>>>>
>>>> Peter
>>>>
>>>>
>>>
>
>
Re: TextMarker maven build process update
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
On 28.06.2012 17:44, Marshall Schor wrote:
> If a public repo can't be found, do you use the
> http://maven.apache.org/plugins/maven-eclipse-plugin/to-maven-mojo.html plugin
> for adding the eclipse plugins to the local repo, as part of your build?
>
> -Marshall
>
Yes, I am doing this right now manually with eclipse:make-artifacts
(http://maven.apache.org/plugins/maven-eclipse-plugin/make-artifacts-mojo.html).
My maven knowledge isn't yet good enough to get the idea to include that
in the build process. That a good idea, but won't we get problems for an
automatic build in future since you have to provide the Eclipse
installation dir? Could we provide that on a build server some time in
future?
Peter
> On 6/28/2012 11:38 AM, Marshall Schor wrote:
>> Is there not a "public" repository for the bundles you need? I'm looking around
>> for one...
>>
>> -Marshall
>> On 6/28/2012 11:34 AM, Peter Klügl wrote:
>>> Hi,
>>>
>>>> Hi Peter,
>>>>
>>>> I'm sorry if I've missed the thread - has it been discussed why the Eclipse
>>>> plugins can't be built with the pom-first approach that our current Eclipse
>>>> plugins are built with?
>>>>
>>> No, they can be and are actually built this way right now. Everything works
>>> fine, if you add a complete Eclipse Indigo release with DLTK Core 3.0
>>> installed to your local maven repository. I think that the pom-first build is
>>> only reasonable if the user does not have to do that, but we can provide a
>>> repository like that somehow.
>>>
>>> Building the bundles the manifest-first way does not have such problems
>>> because the dependencies are automatically resolved using p2 repositories. In
>>> my opinion, that is a much nicer solution and should work just fine. However,
>>> after the time I spent with this problem and with hardly any progress, I must
>>> admit that I don't care too much anymore about how the bundles are built.
>>>
>>> Is a repository for the bundles an option for us?
>>>
>>> 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>.
If a public repo can't be found, do you use the
http://maven.apache.org/plugins/maven-eclipse-plugin/to-maven-mojo.html plugin
for adding the eclipse plugins to the local repo, as part of your build?
-Marshall
On 6/28/2012 11:38 AM, Marshall Schor wrote:
> Is there not a "public" repository for the bundles you need? I'm looking around
> for one...
>
> -Marshall
> On 6/28/2012 11:34 AM, Peter Klügl wrote:
>> Hi,
>>
>>> Hi Peter,
>>>
>>> I'm sorry if I've missed the thread - has it been discussed why the Eclipse
>>> plugins can't be built with the pom-first approach that our current Eclipse
>>> plugins are built with?
>>>
>> No, they can be and are actually built this way right now. Everything works
>> fine, if you add a complete Eclipse Indigo release with DLTK Core 3.0
>> installed to your local maven repository. I think that the pom-first build is
>> only reasonable if the user does not have to do that, but we can provide a
>> repository like that somehow.
>>
>> Building the bundles the manifest-first way does not have such problems
>> because the dependencies are automatically resolved using p2 repositories. In
>> my opinion, that is a much nicer solution and should work just fine. However,
>> after the time I spent with this problem and with hardly any progress, I must
>> admit that I don't care too much anymore about how the bundles are built.
>>
>> Is a repository for the bundles an option for us?
>>
>> Best,
>>
>> Peter
>>
>>
>
>
Re: TextMarker maven build process update
Posted by Marshall Schor <ms...@schor.com>.
Is there not a "public" repository for the bundles you need? I'm looking around
for one...
-Marshall
On 6/28/2012 11:34 AM, Peter Klügl wrote:
> Hi,
>
>> Hi Peter,
>>
>> I'm sorry if I've missed the thread - has it been discussed why the Eclipse
>> plugins can't be built with the pom-first approach that our current Eclipse
>> plugins are built with?
>>
>
> No, they can be and are actually built this way right now. Everything works
> fine, if you add a complete Eclipse Indigo release with DLTK Core 3.0
> installed to your local maven repository. I think that the pom-first build is
> only reasonable if the user does not have to do that, but we can provide a
> repository like that somehow.
>
> Building the bundles the manifest-first way does not have such problems
> because the dependencies are automatically resolved using p2 repositories. In
> my opinion, that is a much nicer solution and should work just fine. However,
> after the time I spent with this problem and with hardly any progress, I must
> admit that I don't care too much anymore about how the bundles are built.
>
> Is a repository for the bundles an option for us?
>
> Best,
>
> Peter
>
>
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/
---------------------------------------------------------------------
Re: TextMarker maven build process update
Posted by Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de>.
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>.
Hi,
> Hi Peter,
>
> I'm sorry if I've missed the thread - has it been discussed why the Eclipse
> plugins can't be built with the pom-first approach that our current Eclipse
> plugins are built with?
>
No, they can be and are actually built this way right now. Everything
works fine, if you add a complete Eclipse Indigo release with DLTK Core
3.0 installed to your local maven repository. I think that the pom-first
build is only reasonable if the user does not have to do that, but we
can provide a repository like that somehow.
Building the bundles the manifest-first way does not have such problems
because the dependencies are automatically resolved using p2
repositories. In my opinion, that is a much nicer solution and should
work just fine. However, after the time I spent with this problem and
with hardly any progress, I must admit that I don't care too much
anymore about how the bundles are built.
Is a repository for the bundles an option for us?
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 6/15/2012 10:08 AM, Peter Klügl wrote:
> Hi,
>
> Just a short update, why there isn't a working TextMarker build yet.
>
> I am still stuck with defining a working build process for the TextMarker
> bundles. The problem is that the combination of manifest-first and pom-first
> bundles does not work correctly (as it should), and I haven't found my error yet.
>
> After a lot of reading, I am sure that the normal Eclipse plugins should be
> built with a manifest-first approach. However, there is a limitation that
> pom-first and manifest-first projects cannot be mixed in the same reactor
> build. Will this be a problem in future for building/releasing the TextMarker
> projects?
Hi Peter,
I'm sorry if I've missed the thread - has it been discussed why the Eclipse
plugins can't be built with the pom-first approach that our current Eclipse
plugins are built with?
-Marshall
>
> Best,
>
> Peter
>