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: [email protected]
http://www.is.informatik.uni-wuerzburg.de/en/staff/kluegl_peter/
---------------------------------------------------------------------
