org.apache.geronimo.specs API modules for ivy

9 views
Skip to first unread message

Martin Weber

unread,
Oct 24, 2012, 4:35:53 PM10/24/12
to ivyro...@googlegroups.com
Hi all,

as I´m in the process of adding the JavaEE 6 APIs to IvyRoundup, I ran into a
question of how to set the revisions for Ivy properly.
For example, the org.apache.geronimo.specs module contining the classes of the
EJB API (JSR-318) Version 3.1 on maven central has the API version in the
module name itself and provides three different revisions 1.0, 1.0.1 and
1.0.2.
(See <http://mirrors.ibiblio.org/maven2/org/apache/geronimo/specs/geronimo-
ejb_3.1_spec/>)

My question is: How should those API versions and revisions be mapped in order
to make the Ivy latest-revision? resolver handle the 'lastest.release' revison
properly? AFAIK, that resolver cannot reolve a 'lastest.release' revison if
the actual revision of the module is sth. like 1.2-v2012beta.3.

I see the following types of revision mapping from Maven to Ivy:
1) Module geronimo-ejb_3.1_spec v 1.1 becomes module ejb_3.1 rev 1.1 in
Ivyroundup. This mapping would make the latest revison resolver work, if newer
revisions of the module are added to ivyroundup. It also is close to the
module name in maven (which the original authos choose).

Resulting modules & revisions in Ivyroundup:
org.apache.geronimo.specs#ejb_3.1;1.0
org.apache.geronimo.specs#ejb_3.1;1.0.1
org.apache.geronimo.specs#ejb_3.1;1.0.2


2) geronimo-ejb_3.1_spec v 1.1 --> module ejb rev 3.1 in ivy. If newer
versions arrive, the packager.xml in ivyroundup has to be updated accordingly;
ivyroungup consumer have no choice to select older revisions after update.
This mapping does not respect the module name chosen by the original authors.

Resulting modules & revisions in Ivyroundup:
org.apache.geronimo.specs#ejb;3.1

3) geronimo-ejb_3.1_spec v 1.1 --> module ejb rev 3.1-1.1 in ivy. Does the ivy
resolver handle the latest.release case here?

Resulting modules & revisions in Ivyroundup:
org.apache.geronimo.specs#ejb;3.1-1.0
org.apache.geronimo.specs#ejb;3.1-1.0.1
org.apache.geronimo.specs#ejb;3.1-1.0.2


4) Some tricks with classifier in Ivy?


5) Some tricks with extra attributes in Ivy?


Awaiting your ideas,
Martin

--
Cd wrttn wtht vwls s mch trsr.

Zac Jacobson

unread,
May 29, 2014, 4:34:00 PM5/29/14
to ivyro...@googlegroups.com
I know this is an old topic, but I find myself asking this same question this week. I liked your options 1 or 2.. I prefer 1 because then it's obvious there's been updates (up to now, we have not synced our local repo against the roundup unless there's something new we need).

I would add my observation that while org.apache.geronimo.specs is publishing these artifacts to Maven, the artifacts themselves tend to be in the javax. namespace, so should the ivy roundup org be, eg for jta, javax.transaction? There's a module already called that that happens to have been pulled from hibernate, but really is just the API. Does the jta spec needs to be in the roundup from 2 different orgs?

Also, I see that some modules are named with "-api" suffix, while others are not. If I could go back to 2012, I would have recommended that some consistent approach be decided on in this regard.

Zac
Reply all
Reply to author
Forward
0 new messages