You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Jeff McAffer <Je...@ca.ibm.com> on 2006/06/01 04:48:07 UTC
Re: [Maven Plugin] Additional fixes...
Niclas Hedhman <he...@gmail.com> wrote on 05/31/2006 12:30:41 AM:
> On Tuesday 30 May 2006 23:16, Jeff McAffer wrote:
> > As pointed out above, we can certainly look at supporting '-' in the
JAR
> > file name. The only place we care is in some of the boot code that
needs
> > to search for bundles. We try to avoid doing this at all costs and
are
> > generally successful but given that our version numbers change very
> > frequently (every build) some level of searching at boot time seems
> > unavoidable.
>
> Yep, I happened to have investigated the scanning for the use in
osgi.bundles
> property, as it took me quite a while to figure out a problem a few
months
> ago with the dash character... ;o)
Side note but Equinox does handle bundles with arbitrary filenames if you
spec the actual filename. The typical use of the osgi.bundles property
involves just spec'ing the bundle symbolic name. For example,
osgi.bundles=org.eclipse.core.runtime
In this case, as a convenience, the framework searches for jars that have
the form org.eclipse.core.runtime_x.y.z.q.jar etc. If it finds several of
those it chooses the one with the highest version number. This is stictly
a convenience and is intended for managing bootstrap bundles. If however
you spec something like
osgi.bundles=scr-1.0.2.jar
then the framework will not search and will load the given JAR with
whatever chars you want in the filename.
> > This works well as long as you have a repo (local or remote) structure
> > that includes groupids. When shipping a product (either on the media
or
> > on the provisioning server) you may not have this level of control and
> > maintaining this structure complicates management agents. The crux of
the
> > problem is that the bundle jar itself is not standalone since its name
is
> > not unique. The JAR is only unique in a context (i.e., group).
>
> I understand your point, but I have no particular reason to neither
> endorse it
> nor condemn it. There are arguments in both directions.
> Eclipse's solution is only one of many possible paths, and I hope you
agree
> that Eclipse is a bit of overkill to be required for OSGi development in
> general.
I'm assuming that by "Eclipse being overkill" you mean the Eclipse
filenaming scheme outlined earlier? I actually believe that the Eclipes
approach is demanded precisely for "general" OSGi development. For very
specific small scale OSGi development you will never have more than one
log-1.0.0.jar so sure, use simple names. As soon as you start using OSGi
to its full potential (i.e., as a framework for dynamically composing
independently developed components) you get naming collisions. Assuming
that consumers/provisioning agents/repo managers/... will/should/must
physically organize their bundles to avoid these collisions puts the
burden on the many to save some effort by the few (developers).
Without exception, every time I have taken a shortcut like this I have
come to regret it.
> I have made a Maven compatible product in the past, named Transit, which
> allowed for protocol based retrieval and local caching of artifacts,
with a
> format of;
>
> artifact:jar:[group]/[artifact]#[version]
>
> Transit allows for many "repository hosts" and each such host has a
"Layout",
> which could be maven1, maven2 or eclipse. And to obtain the content one
just
> do the;
> new URL( "artifact:jar:log4j/log4j#1.2.8" ).openStream();
>
> In that perspective, "files" didn't exist from the developers
perspective,
> only the artifacts, and whether the structure is flat or not became
totally
> irrelevant.
> So, therefor, I am somewhat less inclined to "play along" with the
statement
> that "flat" == "easiest". "flat" just brings a different set of issues,
and
> then a subjective priority has to take place of which issues are better
than
> others.
Yup this is a nice abstraction. As a point of interest, how does the
layout get inferred from the information given above? That is, how is it
known that "artifact:jar:log4j/log4j#1.2.8" is a Maven repo path?
The issue I'm trying to raise is the unfortunate situation where choices
made at development time (e.g., use short names for the artifact) impact
how people actually ship their bundle-based products/offerings. For
exmaple, if you use short names in the Maven repo and when you get things
out of the repo they come with short names then you are obliged to layout
those bundles (in your product, provisioning server, ...) in some related
form to avoid collisions. In effect, you have to ship part of the
development setup. If you happen to have 3 or 4 different sources for
bundles that go into your product (OBR, Felix Commons, Equinox, ...) then
you may end up shipping several different layouts.
To avoid this you can rename or reconfigure artifacts as they come out of
the related repos. This is the extraction application you mentioned
earlier. This can work but then you have the added confusion of having
the same thing with multiple names, issues of duplication (the same thing
from different sources might map to different names), figuring out, given
a mapped name, what the original was, ...
I keep coming back to the Java package name analogy. Java needed a
simple, robust naming scheme for classes. Since domain names are
universally understood, globally managed and unambiguous they make a fine
choice.
Anyway, I've likely said the same thing more than enough times now...
Jeff
Re[2]: [Maven Plugin] Additional fixes...
Posted by Peter Kriens <Pe...@aQute.se>.
Why is everybody so worried about the filename of the JAR?? It is
trivial to find the BSN + version by looking in the manifest. With
this information anybody can use his own scheme.
Trying to align JAR file names seems a rather useless exercise. An
almost trivial program can rename them to any style you want.
Kind regards,
Peter Kriens
JM> Niclas Hedhman <he...@gmail.com> wrote on 06/01/2006 02:10:08 AM:
>> On Thursday 01 June 2006 10:48, Jeff McAffer wrote:
>>
>> > I'm assuming that by "Eclipse being overkill" you mean the Eclipse
>> > filenaming scheme outlined earlier? I
>>
>> Nah... I meant, that I must use Eclipse IDE or I can't develop OSGi
JM> systems.
>> Eclipse meaning the entire thing, that I personally am not very fond of
JM> as a
>> development tool, although I think Eclipse as an RCP for my own
JM> applications
>> make total sense.
JM> We've had this discussion before. No one in this discussion is proposing
JM> that Eclipse the IDE has to be used for anything. We are talking about
JM> bundle JAR naming conventions.
>> > If you happen to have 3 or 4 different sources for
>> > bundles that go into your product (OBR, Felix Commons, Equinox, ...)
JM> then
>> > you may end up shipping several different layouts.
>>
>> The general approach is in Maven camps the opposite. Any needed artifact
JM> gets
>> published to a repository. Last time I checked 13000 something Jars was
>> available in Mavens central repository, then plus many projects having
JM> their
>> own to fill some remaining gaps. There can't be many Java OSS projects
JM> that
>> is not present...
>>
>> There is indeed a huge investment in standardizing this issue, and
JM> Eclipse is
>> the significant exception, rather than the rule, at least from my angle
JM> of
>> view.
JM> In this part of the discussion I am focused on shipping
JM> products/offerings/... I am not aware of any products that, upon
JM> installation to the user's machine, go and fetch JARs from a Maven repo.
JM> Local or remote. The issue is that if JARs are named for the convenience
JM> of the development time repo and these names are not unique, then people
JM> deploying products have to replicate the repository structure in their
JM> offerings or rename the artifacts to ensure uniqueness. Neither is much
JM> fun.
>> > I keep coming back to the Java package name analogy. Java needed a
>> > simple, robust naming scheme for classes. Since domain names are
>> > universally understood, globally managed and unambiguous they make a
JM> fine
>> > choice.
>>
>> Well, if you bring the analogy full circle, you will quickly discover
JM> that
>> Maven follows this (now) more than you want to think, and Eclipse less
JM> than
>> you argue;
>> Java Package == Maven Group
>> Java Class == Maven Artifact.
>> Java did not say that the Filename of the class must be FQDN, but
JM> instead
>> stored hierarchically on the file system according to the package name.
>> Uhhhhh.... Maybe a quick look at
JM> http://www.ibiblio.org/maven2/org/apache/
>> gives you a hint (the many non hierarchical items in the root are
JM> unfortunate
>> legacy)
JM> yes, I confess that this has been confusing me greatly (being a Maven
JM> newbie). In the repo you point out there seems to be several different
JM> approaches and conventions. Even in some of the examples that have been
JM> bandied around here there are things like log4j/log4j/1.1.3. The
JM> hierarchical package form you described in your other post is more
JM> intersting/consistent. Some clarifying questions then...
JM> Can you express a clear bi-directional mapping of BSN and version onto
JM> groupId, artifactId, version and ultimate JAR name?
JM> Is it true that all '.' in groupIds are converted to '/' (i.e., dirs) in
JM> the Maven repo?
JM> Is this true for '.' in the artifactId?
JM> In any event, the issues of robustness and confusion remain. For example,
JM> take a look at
JM> http://www.ibiblio.org/maven2/org/eclipse/equinox/osgi/3.1.1/
JM> You will see that it contains osgi-3.1.1.jar. This is what we named as
JM> org.eclipse.osgi_3.1.1.jar. Notice that the groupId does not match the
JM> BSN and the JAR has been renamed. So there is ambiguity in the groupId
JM> (perhaps the person who did this just did it wrong?). The JAR itself has
JM> a nice simple name (osgi-3.1.1.jar) but this is hardly unique. So, now
JM> when you go to ship a product you have to replicate the dir structure or
JM> do other things to avoid collisions.
>> You just choose to require that it has to be on the filename, and
JM> creating a
>> non-existing analogy.
JM> Certainly filenames are just one way.
JM> As for the analogy, perhaps it is poor. Dunno, it still works for me.
JM> There are a couple differences being glossed over
JM> - people generally speaking do not have to manipulate individual class
JM> files. They manage whole dirs or whole JARs. Ideally perhaps one would
JM> not have to manipulate bundle JARs but that is our unit of delivery so its
JM> hard to see that need going away.
JM> - in the package/class structure
JM> <root>/org/apache/felix/Framework.class
JM> the actual class is org.apache.felix.Framework. There is a very clear and
JM> simple mapping to the file structure. This seems to come back to whether
JM> or not there is a simple rule for mapping BSN and version onto the dir
JM> based file structure.
JM> Jeff
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: [Maven Plugin] Additional fixes...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 03 June 2006 02:22, Jeff McAffer wrote:
> Niclas Hedhman <he...@gmail.com> wrote on 06/01/2006 11:47:52 PM:
> > On Friday 02 June 2006 00:07, Jeff McAffer wrote:
> > > Can you express a clear bi-directional mapping of BSN and version onto
> > > groupId, artifactId, version and ultimate JAR name?
> >
> > <root>/<groupId>/<artifactId>/<version>/<artifactId>-<version>-
> > <classifier>.<type>
> >
> > where <groupId> has the dots exchanged for slashes to map into the file
> > system.
> > <classifier> refers to non versioning subtypes, e.g. javadocs, source or
> >
> > platform. This is used indirectly by the plugins producing these
>
> associated
>
> > or derived types of the artifact.
>
> I'm looking for a mapping between Bundle-SymbolicName and Bundle-Version
> and the Maven concepts of groupId, artifactId, ...
My 'default' for Symbolic name in the patch for the Maven plugin is that it
takes
${pom.groupId}.${pom.artifactId}
But that doesn't make sense if you stack the artifactId with the grouping
information...
I am out of ideas of what to do with "jar-filename", "artifactId", "eclipse
conformance" and "repository names"...
IMHO, both the Maven and the Eclipse organization are solving the same
problem, but in different ways that are not too easy to bridge. I don't have
much of a preference of one over the other, but I think Jeff is right that
whatever Felix does, will be watched by future non-Eclipse, OSGi developers.
FWIW, if we stack groupId into the artifactId, I suspect that one is quickly
reaching Windows limits on path names when running in some app servers (JBoss
coming to mind).
A 'middle ground' *could* be;
<groupId>org.apache.felix</groupId> <!-- to satisfy Maven repos -->
<artifactId>felix.framework<artifactId> <!-- to satisfy flat directories -->
and then like;
<groupId>org.apache.felix</groupId>
<artifactId>felix.tool.mangen<artifactId>
<groupId>org.apache.felix</groupId>
<artifactId>felix.shell.gui<artifactId>
<groupId>org.apache.felix</groupId>
<artifactId>felix.upnp.sample.clock<artifactId>
Cheers
Niclas
Re: [Maven Plugin] Additional fixes...
Posted by Jeff McAffer <Je...@ca.ibm.com>.
Niclas Hedhman <he...@gmail.com> wrote on 06/01/2006 11:47:52 PM:
> On Friday 02 June 2006 00:07, Jeff McAffer wrote:
>
> > Can you express a clear bi-directional mapping of BSN and version onto
> > groupId, artifactId, version and ultimate JAR name?
>
> <root>/<groupId>/<artifactId>/<version>/<artifactId>-<version>-
> <classifier>.<type>
>
> where <groupId> has the dots exchanged for slashes to map into the file
> system.
> <classifier> refers to non versioning subtypes, e.g. javadocs, source or
> platform. This is used indirectly by the plugins producing these
associated
> or derived types of the artifact.
I'm looking for a mapping between Bundle-SymbolicName and Bundle-Version
and the Maven concepts of groupId, artifactId, ...
Jeff
Re: [Maven Plugin] Additional fixes...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 02 June 2006 00:07, Jeff McAffer wrote:
> Can you express a clear bi-directional mapping of BSN and version onto
> groupId, artifactId, version and ultimate JAR name?
<root>/<groupId>/<artifactId>/<version>/<artifactId>-<version>-<classifier>.<type>
where <groupId> has the dots exchanged for slashes to map into the file
system.
<classifier> refers to non versioning subtypes, e.g. javadocs, source or
platform. This is used indirectly by the plugins producing these associated
or derived types of the artifact.
> Is it true that all '.' in groupIds are converted to '/' (i.e., dirs) in
> the Maven repo?
Yes, in Maven2.
> Is this true for '.' in the artifactId?
No. The dots in artifactIDs are kept.
> In any event, the issues of robustness and confusion remain. For example,
> take a look at
> http://www.ibiblio.org/maven2/org/eclipse/equinox/osgi/3.1.1/
> You will see that it contains osgi-3.1.1.jar. This is what we named as
> org.eclipse.osgi_3.1.1.jar. Notice that the groupId does not match the
> BSN and the JAR has been renamed. So there is ambiguity in the groupId
> (perhaps the person who did this just did it wrong?). The JAR itself has
> a nice simple name (osgi-3.1.1.jar) but this is hardly unique. So, now
> when you go to ship a product you have to replicate the dir structure or
> do other things to avoid collisions.
Personally, I make the "lib/" dir the "<root>" and replicate the structure.
Difficult? Not found it troublesome yet, but always worked with tools that
can deal with it. ;o)
You are saying that we are not in control of the deployment scenarios, and we
have to adopt to other people's wishes and work patterns.
I have only come across this once, but in that case the requirement was to be
compatible with Solaris pkg system, automatic re-installs, and stepping
backwards and forwards in versioning. Very heavy, and this discussion would
have no effect one way or the other. All other cases; "here is the tar, zip,
installer or whatever, and read the INSTALL doc"... has been more than
sufficient.
Perhaps you could provide a more elaborate usecase of where this enforcement
happens.
Also, an interesting note is that Linux manages to stick 2400 (my system)
files from different sources into /usr/bin ... Why are we so concerned, and
they are not?
Cheers
Niclas
Re: [Maven Plugin] Additional fixes...
Posted by Jeff McAffer <Je...@ca.ibm.com>.
Niclas Hedhman <he...@gmail.com> wrote on 06/01/2006 02:10:08 AM:
> On Thursday 01 June 2006 10:48, Jeff McAffer wrote:
>
> > I'm assuming that by "Eclipse being overkill" you mean the Eclipse
> > filenaming scheme outlined earlier? I
>
> Nah... I meant, that I must use Eclipse IDE or I can't develop OSGi
systems.
> Eclipse meaning the entire thing, that I personally am not very fond of
as a
> development tool, although I think Eclipse as an RCP for my own
applications
> make total sense.
We've had this discussion before. No one in this discussion is proposing
that Eclipse the IDE has to be used for anything. We are talking about
bundle JAR naming conventions.
> > If you happen to have 3 or 4 different sources for
> > bundles that go into your product (OBR, Felix Commons, Equinox, ...)
then
> > you may end up shipping several different layouts.
>
> The general approach is in Maven camps the opposite. Any needed artifact
gets
> published to a repository. Last time I checked 13000 something Jars was
> available in Mavens central repository, then plus many projects having
their
> own to fill some remaining gaps. There can't be many Java OSS projects
that
> is not present...
>
> There is indeed a huge investment in standardizing this issue, and
Eclipse is
> the significant exception, rather than the rule, at least from my angle
of
> view.
In this part of the discussion I am focused on shipping
products/offerings/... I am not aware of any products that, upon
installation to the user's machine, go and fetch JARs from a Maven repo.
Local or remote. The issue is that if JARs are named for the convenience
of the development time repo and these names are not unique, then people
deploying products have to replicate the repository structure in their
offerings or rename the artifacts to ensure uniqueness. Neither is much
fun.
> > I keep coming back to the Java package name analogy. Java needed a
> > simple, robust naming scheme for classes. Since domain names are
> > universally understood, globally managed and unambiguous they make a
fine
> > choice.
>
> Well, if you bring the analogy full circle, you will quickly discover
that
> Maven follows this (now) more than you want to think, and Eclipse less
than
> you argue;
> Java Package == Maven Group
> Java Class == Maven Artifact.
> Java did not say that the Filename of the class must be FQDN, but
instead
> stored hierarchically on the file system according to the package name.
> Uhhhhh.... Maybe a quick look at
http://www.ibiblio.org/maven2/org/apache/
> gives you a hint (the many non hierarchical items in the root are
unfortunate
> legacy)
yes, I confess that this has been confusing me greatly (being a Maven
newbie). In the repo you point out there seems to be several different
approaches and conventions. Even in some of the examples that have been
bandied around here there are things like log4j/log4j/1.1.3. The
hierarchical package form you described in your other post is more
intersting/consistent. Some clarifying questions then...
Can you express a clear bi-directional mapping of BSN and version onto
groupId, artifactId, version and ultimate JAR name?
Is it true that all '.' in groupIds are converted to '/' (i.e., dirs) in
the Maven repo?
Is this true for '.' in the artifactId?
In any event, the issues of robustness and confusion remain. For example,
take a look at
http://www.ibiblio.org/maven2/org/eclipse/equinox/osgi/3.1.1/
You will see that it contains osgi-3.1.1.jar. This is what we named as
org.eclipse.osgi_3.1.1.jar. Notice that the groupId does not match the
BSN and the JAR has been renamed. So there is ambiguity in the groupId
(perhaps the person who did this just did it wrong?). The JAR itself has
a nice simple name (osgi-3.1.1.jar) but this is hardly unique. So, now
when you go to ship a product you have to replicate the dir structure or
do other things to avoid collisions.
> You just choose to require that it has to be on the filename, and
creating a
> non-existing analogy.
Certainly filenames are just one way.
As for the analogy, perhaps it is poor. Dunno, it still works for me.
There are a couple differences being glossed over
- people generally speaking do not have to manipulate individual class
files. They manage whole dirs or whole JARs. Ideally perhaps one would
not have to manipulate bundle JARs but that is our unit of delivery so its
hard to see that need going away.
- in the package/class structure <root>/org/apache/felix/Framework.class
the actual class is org.apache.felix.Framework. There is a very clear and
simple mapping to the file structure. This seems to come back to whether
or not there is a simple rule for mapping BSN and version onto the dir
based file structure.
Jeff
Re: [Maven Plugin] Additional fixes...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 01 June 2006 10:48, Jeff McAffer wrote:
> I'm assuming that by "Eclipse being overkill" you mean the Eclipse
> filenaming scheme outlined earlier? I
Nah... I meant, that I must use Eclipse IDE or I can't develop OSGi systems.
Eclipse meaning the entire thing, that I personally am not very fond of as a
development tool, although I think Eclipse as an RCP for my own applications
make total sense.
> Yup this is a nice abstraction. As a point of interest, how does the
> layout get inferred from the information given above? That is, how is it
> known that "artifact:jar:log4j/log4j#1.2.8" is a Maven repo path?
artifact: is by Transit's definition an artifact available on a repository
host. The configuration in Transit of the repository host (base URL), defines
how the layout of that host is organized, hence both Maven2, Maven1, Eclipse
and others are supported. Trygve have highlighted that Maven2 also supports
this now.
> If you happen to have 3 or 4 different sources for
> bundles that go into your product (OBR, Felix Commons, Equinox, ...) then
> you may end up shipping several different layouts.
The general approach is in Maven camps the opposite. Any needed artifact gets
published to a repository. Last time I checked 13000 something Jars was
available in Mavens central repository, then plus many projects having their
own to fill some remaining gaps. There can't be many Java OSS projects that
is not present...
There is indeed a huge investment in standardizing this issue, and Eclipse is
the significant exception, rather than the rule, at least from my angle of
view.
> I keep coming back to the Java package name analogy. Java needed a
> simple, robust naming scheme for classes. Since domain names are
> universally understood, globally managed and unambiguous they make a fine
> choice.
Well, if you bring the analogy full circle, you will quickly discover that
Maven follows this (now) more than you want to think, and Eclipse less than
you argue;
Java Package == Maven Group
Java Class == Maven Artifact.
Java did not say that the Filename of the class must be FQDN, but instead
stored hierarchically on the file system according to the package name.
Uhhhhh.... Maybe a quick look at http://www.ibiblio.org/maven2/org/apache/
gives you a hint (the many non hierarchical items in the root are unfortunate
legacy)
You just choose to require that it has to be on the filename, and creating a
non-existing analogy.
I DO agree with the principal of formalized names. I don not agree that
filename is the only way to achieve this.
> Anyway, I've likely said the same thing more than enough times now...
Yep, me too.... ;o)
Everybody else have fallen asleep.
Cheers
Niclas