You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2006/05/26 12:00:07 UTC
[Maven Plugin] Additional fixes...
Hi,
I think it would be good if one was allowed to use ${pom.version} for version
attribute in Export-Package. There are two issues as far as I can see;
1. -SNAPSHOT is not allowed at all.
2. Does the package version evolve at some other rate than the bundle? And
should one perhaps only use the first two digit groups for the package
version.
I also think that
* <bundleSymbolicName> should default to ${pom.artifactId}
* <bundleName> should default to ${pom.name}
* <bundleDescription> should default to ${pom.description}
* <bundleVendor> should default to ${pom.organization.name}
* <bundleVersion> should default to ${pom.version} (see above).
* bundleContactAddress should default to ${pom.organization.url}
* <bundleUrl> and/or <bundleUpdateLocation> should default to ${pom.url}
* <bundleCopyright should default to
Copyright ${pom.inceptionYear}, ${pom.organization.name}
* A whole bunch of other properties to read from file(s) in the project
directory instead, including <exportPackage>, <excludeImport>
Or perhaps utlize the <properties> tag in the pom main section...
If that is done, then one can move the whole <plugin> section of the POM to a
(grand)*parent pom, which I think simplifies 'standard cases', still allowing
for the current form.
Willing to do the work, but before wasting my time, I would like to get some
feedback.
WDYT?
Cheers
Niclas
Re: [Maven Plugin] Additional fixes...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 29 May 2006 18:45, Richard S. Hall wrote:
> Niclas Hedhman wrote:
> > Ok, here are a sequence of changes;
> >
> > * Bundle-Date defaults to "NOW", with a default format of
> > yyyy-MMM-dd HH:mm z
>
> I am not sure what this header even is or what it is supposed to refer
> to...I can't find a definition for it anywhere.
Me too. Notice the comment in the patched source;
setEntryDefaultValue(BUNDLE_DATE, date); // not mentioned in R4 Core Spec.
but I figured someone knows more than I do... ;o)
Cheers
Niclas
Re: [Maven Plugin] Additional fixes...
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Niclas Hedhman wrote:
> Ok, here are a sequence of changes;
>
> * Bundle-Date defaults to "NOW", with a default format of
> yyyy-MMM-dd HH:mm z
>
I am not sure what this header even is or what it is supposed to refer
to...I can't find a definition for it anywhere.
-> richard
Re: [Maven Plugin] Additional fixes...
Posted by Niclas Hedhman <ni...@hedhman.org>.
Ok, here are a sequence of changes;
* Any "version" and "specification-version" clauses found in import, export
and dynamic-import are having any dashes replaced by dots.
* Bundle-Copyright will default to
Copyright ${pom.inceptionYear} ${pom.organization.name}
unless any of those values are missing in which case there is no default.
* Bundle-Description defaults to ${pom.description}
* Bundle-Name defaults to ${pom.name}
* Bundle-Version defaults to ${pom.version}
* Bundle-DocURL defaults to ${pom.url}
* Bundle-ContactAddress defaults to ${pom.organization.url} provided an
organization and a url is declared.
* Bundle-SymbolicName defaults to ${pom.groupId}.${pom.artifactId}
* Bundle-Source defaults to ${pom.scm.connection} minus any leading
cvs:, svn: and scm:. If that doesn't exist, it also tries the
${pom.scm.developerConnection}
* Bundle-Date defaults to "NOW", with a default format of
yyyy-MMM-dd HH:mm z
* Bundle-ManifestVersion defaults to 2.
* One can declare some things under the <properties> element on the
POM.
- <osgi-IgnorePackage>
- <osgi-NativeCode>
- <osgi-ExportPackage>
- <osgi-ImportPackage>
- <osgi-DynamicImportPackage>
- <osgi-BundleActivator>
- <osgi-UpdateLocation>
- <osgi-Localization>
- <osgi-RequireBundle>
- <osgi-FragmentHost>
- <osgi-URL>
- <osgi-DateFormat>
So that one can declare these without the full <build><plugins> structure
in each sub-project.
* The OsgiManifest no longer holds class members, and instead
stores/retrieves the data straight into the entries map.
For me this works well, and I end up with simple sub-project bundle poms, such
as;
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<parent>
<artifactId>departmentstore</artifactId>
<groupId>org.ops4j.pax.wicket.samples</groupId>
<version>0.1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>org.ops4j.pax.wicket.samples.departmentstore</groupId>
<artifactId>model</artifactId>
<name>OPS4J - Pax Wicket Department Store Model</name>
<version>0.1.0-SNAPSHOT</version>
<packaging>osgi-bundle</packaging>
<description>Pax Wicket Samples Departmentstore - The model of the
department store, representing the business logic separated from the
view.</description>
<properties>
<osgi-ExportPackage>org.ops4j.pax.wicket.samples.departmentstore.model;version=${pom.version}</osgi-ExportPackage>
</properties>
<dependencies>
<dependency>
<groupId>org.osgi</groupId>
<artifactId>osgi_R4_core</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.osgi</groupId>
<artifactId>osgi_R4_compendium</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>
</project>
Feedback appreciated :o)
Cheers
Niclas
Re: [Maven Plugin] Additional fixes...
Posted by Niclas Hedhman <ni...@hedhman.org>.
Everyone, thanks for the positive feedback. I have implemented most defaults,
but will tomorrow doublecheck Richard's suggestions and take out any "in
discussion" items, to be added later when we have some consensus. Expect a
patch tomorrow Monday.
Cheers
Niclas
On Saturday 27 May 2006 00:21, John E. Conlon wrote:
> Niclas, have you seen the problem where the plugin now during the felix
> build creates a bad org.osgi.core-0.8.0-SNAPSHOT.jar bundle, by
> assigning the BundleActivator itself as the implemenation in the
> manifest? (Bundle-Activator: org.osgi.framework.BundleActivator)
>
> - John
>
> On Fri, 2006-05-26 at 18:00 +0800, Niclas Hedhman wrote:
> > Hi,
> >
> > I think it would be good if one was allowed to use ${pom.version} for
> > version attribute in Export-Package. There are two issues as far as I can
> > see;
> >
> > 1. -SNAPSHOT is not allowed at all.
> >
> > 2. Does the package version evolve at some other rate than the bundle?
> > And should one perhaps only use the first two digit groups for the
> > package version.
> >
> >
> > I also think that
> >
> > * <bundleSymbolicName> should default to ${pom.artifactId}
> >
> > * <bundleName> should default to ${pom.name}
> >
> > * <bundleDescription> should default to ${pom.description}
> >
> > * <bundleVendor> should default to ${pom.organization.name}
> >
> > * <bundleVersion> should default to ${pom.version} (see above).
> >
> > * bundleContactAddress should default to ${pom.organization.url}
> >
> > * <bundleUrl> and/or <bundleUpdateLocation> should default to
> > ${pom.url}
> >
> > * <bundleCopyright should default to
> > Copyright ${pom.inceptionYear}, ${pom.organization.name}
> >
> > * A whole bunch of other properties to read from file(s) in the
> > project directory instead, including <exportPackage>, <excludeImport> Or
> > perhaps utlize the <properties> tag in the pom main section...
> >
> > If that is done, then one can move the whole <plugin> section of the POM
> > to a (grand)*parent pom, which I think simplifies 'standard cases', still
> > allowing for the current form.
> >
> > Willing to do the work, but before wasting my time, I would like to get
> > some feedback.
> >
> > WDYT?
> >
> >
> > Cheers
> > Niclas
Re: [Maven Plugin] Additional fixes...
Posted by "John E. Conlon" <jc...@verticon.com>.
Good idea, less is good. +1.
Niclas, have you seen the problem where the plugin now during the felix
build creates a bad org.osgi.core-0.8.0-SNAPSHOT.jar bundle, by
assigning the BundleActivator itself as the implemenation in the
manifest? (Bundle-Activator: org.osgi.framework.BundleActivator)
- John
On Fri, 2006-05-26 at 18:00 +0800, Niclas Hedhman wrote:
> Hi,
>
> I think it would be good if one was allowed to use ${pom.version} for version
> attribute in Export-Package. There are two issues as far as I can see;
>
> 1. -SNAPSHOT is not allowed at all.
>
> 2. Does the package version evolve at some other rate than the bundle? And
> should one perhaps only use the first two digit groups for the package
> version.
>
>
> I also think that
>
> * <bundleSymbolicName> should default to ${pom.artifactId}
>
> * <bundleName> should default to ${pom.name}
>
> * <bundleDescription> should default to ${pom.description}
>
> * <bundleVendor> should default to ${pom.organization.name}
>
> * <bundleVersion> should default to ${pom.version} (see above).
>
> * bundleContactAddress should default to ${pom.organization.url}
>
> * <bundleUrl> and/or <bundleUpdateLocation> should default to ${pom.url}
>
> * <bundleCopyright should default to
> Copyright ${pom.inceptionYear}, ${pom.organization.name}
>
> * A whole bunch of other properties to read from file(s) in the project
> directory instead, including <exportPackage>, <excludeImport>
> Or perhaps utlize the <properties> tag in the pom main section...
>
> If that is done, then one can move the whole <plugin> section of the POM to a
> (grand)*parent pom, which I think simplifies 'standard cases', still allowing
> for the current form.
>
> Willing to do the work, but before wasting my time, I would like to get some
> feedback.
>
> WDYT?
>
>
> Cheers
> Niclas
>
Re: [Maven Plugin] Additional fixes...
Posted by Enrique Rodriguez <en...@gmail.com>.
Niclas Hedhman wrote:
...
> If that is done, then one can move the whole <plugin> section of the POM to a
> (grand)*parent pom, which I think simplifies 'standard cases', still allowing
> for the current form.
>
> Willing to do the work, but before wasting my time, I would like to get some
> feedback.
>
> WDYT?
This is a nicely done summary. I have been hoping that someone would
get around to this; it will be a great simplification of the config.
Richard made some good points, too.
+1.
Enrique
Re: [Maven Plugin] Additional fixes...
Posted by Manuel Santillan <sa...@dit.upm.es>.
IMHO, having default, sensible values for the manifest (as for any other
kind of descriptor) makes perfect sense. Seems like the {"don't repeat
yourself"; "convention over configuration"} mottos in the (overhyped?)
RoR.
Non-binding +1
/manuel
--
Manuel Santillán <sa...@dit.upm.es>
http://www.dit.upm.es/santillan
Departamento de Ingeniería de Sistemas Telemáticos
Escuela Técnica Superior de Ingenieros de Telecomunicación
Universidad Politécnica de Madrid
Avda. Complutense, s/n
28040 Madrid SPAIN
Tel. +34 913367366 ext.3034
El vie, 26-05-2006 a las 18:00 +0800, Niclas Hedhman escribió:
> Hi,
>
> I think it would be good if one was allowed to use ${pom.version} for version
> attribute in Export-Package. There are two issues as far as I can see;
>
> 1. -SNAPSHOT is not allowed at all.
>
> 2. Does the package version evolve at some other rate than the bundle? And
> should one perhaps only use the first two digit groups for the package
> version.
>
>
> I also think that
>
> * <bundleSymbolicName> should default to ${pom.artifactId}
>
> * <bundleName> should default to ${pom.name}
>
> * <bundleDescription> should default to ${pom.description}
>
> * <bundleVendor> should default to ${pom.organization.name}
>
> * <bundleVersion> should default to ${pom.version} (see above).
>
> * bundleContactAddress should default to ${pom.organization.url}
>
> * <bundleUrl> and/or <bundleUpdateLocation> should default to ${pom.url}
>
> * <bundleCopyright should default to
> Copyright ${pom.inceptionYear}, ${pom.organization.name}
>
> * A whole bunch of other properties to read from file(s) in the project
> directory instead, including <exportPackage>, <excludeImport>
> Or perhaps utlize the <properties> tag in the pom main section...
>
> If that is done, then one can move the whole <plugin> section of the POM to a
> (grand)*parent pom, which I think simplifies 'standard cases', still allowing
> for the current form.
>
> Willing to do the work, but before wasting my time, I would like to get some
> feedback.
>
> WDYT?
>
>
> Cheers
> Niclas
Re: [Maven Plugin] Additional fixes...
Posted by Enrique Rodriguez <en...@gmail.com>.
Richard S. Hall wrote:
> Alex Karasulu wrote:
>> Richard S. Hall wrote:
...
>>> I was wondering if it would be better to have:
>>>
>>> * pom.groupId = "org.apache.felix"
>>> * pom.artifactId = "scr"
>>>
>>> Thus, the symbolic name would be:
>>>
>>> * ${pom.groupId} + "." + ${pom.artifactId}
>>>
>>> This would coincide with us cleaning up our trunk directory to only
>>> show the unique part of the subproject name, as opposed to the
>>> groupId part.
>>>
>>> I am not sure if this would be a good move or a bad move from a maven
>>> perspective, though.
>> ...
>>
>> It would be a good move from the maven perspective and the CLI
>> perspective. Using the full package name is a bit too much.
>
> Well then, I will propose this for a vote next week...how does that sound?
I agree with only using the "unique part of the subproject name" and
maintaining the symbolic name, as you describe.
As a major repo change this probably warrants a vote, but it does feel
like we have consensus.
Enrique
Re: [Maven Plugin] Additional fixes...
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Alex Karasulu wrote:
> Richard S. Hall wrote:
>> Niclas Hedhman wrote:
>>
> ...
>>> I also think that * <bundleSymbolicName> should default to
>>> ${pom.artifactId}
>>>
>>
>> Yes, this is what I am doing already in my pom files. However, I was
>> wondering lately if we are doing the artifactId the best way. Right
>> now we have, for example:
>>
>> * pom.groupId = "org.apache.felix"
>> * pom.artifactId = "org.apache.felix.scr"
>>
>> I was wondering if it would be better to have:
>>
>> * pom.groupId = "org.apache.felix"
>> * pom.artifactId = "scr"
>>
>> Thus, the symbolic name would be:
>>
>> * ${pom.groupId} + "." + ${pom.artifactId}
>>
>> This would coincide with us cleaning up our trunk directory to only
>> show the unique part of the subproject name, as opposed to the
>> groupId part.
>>
>> I am not sure if this would be a good move or a bad move from a maven
>> perspective, though.
> ...
>
> It would be a good move from the maven perspective and the CLI
> perspective. Using the full package name is a bit too much.
Well then, I will propose this for a vote next week...how does that sound?
-> richard
Re: [Maven Plugin] Additional fixes...
Posted by Alex Karasulu <ao...@bellsouth.net>.
Richard S. Hall wrote:
> Niclas Hedhman wrote:
>
...
>> I also think that
>> * <bundleSymbolicName> should default to ${pom.artifactId}
>>
>
> Yes, this is what I am doing already in my pom files. However, I was
> wondering lately if we are doing the artifactId the best way. Right
> now we have, for example:
>
> * pom.groupId = "org.apache.felix"
> * pom.artifactId = "org.apache.felix.scr"
>
> I was wondering if it would be better to have:
>
> * pom.groupId = "org.apache.felix"
> * pom.artifactId = "scr"
>
> Thus, the symbolic name would be:
>
> * ${pom.groupId} + "." + ${pom.artifactId}
>
> This would coincide with us cleaning up our trunk directory to only
> show the unique part of the subproject name, as opposed to the groupId
> part.
>
> I am not sure if this would be a good move or a bad move from a maven
> perspective, though.
...
It would be a good move from the maven perspective and the CLI
perspective. Using the full package name is a bit too much.
Alex
Re: [Maven Plugin] Additional fixes...
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Niclas Hedhman wrote:
> Of course. I meant that one could use the ${pom.version} or similar thing
> within <configuration> section, but that the dash is properly replaced in
> each such instance.
>
> Also, whether it would make sense to have a reduced version as well, so that
> if ${pom.version} == "1.2.3", I could use "something" to end up with a
>
> Export-Package: org.hedhman.niclas.api; version=1.2
>
> to allow smoother handling of graceful compatibility upgrades.
I don't see this as being so important. Exported packages should be
explicit about which version they are, they should not masquerade as
another version. Import statements are used to indicate compatibility
ranges.
-> richard
Re: [Maven Plugin] Additional fixes...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 26 May 2006 20:55, Richard S. Hall wrote:
> > 2. Does the package version evolve at some other rate than the bundle?
> > And should one perhaps only use the first two digit groups for the
> > package version.
> >
>
> I think it is worthwhile to have it be possible to use ${pom.version}
> for export package version, but it should clearly not be the default.
> Since packages can be included into any arbitrary bundle, there is no
> default relationship between the deployment unit version (i.e.,
> ${pom.version}) and the package version.
Of course. I meant that one could use the ${pom.version} or similar thing
within <configuration> section, but that the dash is properly replaced in
each such instance.
Also, whether it would make sense to have a reduced version as well, so that
if ${pom.version} == "1.2.3", I could use "something" to end up with a
Export-Package: org.hedhman.niclas.api; version=1.2
to allow smoother handling of graceful compatibility upgrades.
Cheers
Niclas
Re: [Maven Plugin] Additional fixes...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 29 May 2006 13:40, Niclas Hedhman wrote:
> On Friday 26 May 2006 20:55, Richard S. Hall wrote:
> > I was wondering if it would be better to have:
> >
> > * pom.groupId = "org.apache.felix"
> > * pom.artifactId = "scr"
> >
> > Thus, the symbolic name would be:
> >
> > * ${pom.groupId} + "." + ${pom.artifactId}
>
> So, the symbolic name == the concatenated group.artifact... How about the
> Jar file name?? Is that getting the symbolic name + version ??
For reference; Maven will assign the jarName to our plugin as the artifactId +
version, unless the <finalName> element has been defined in the POM, in which
case that is set to the jarName property.
That means the normal override mechanism sits with the "finalName" element. Is
that enough, considering one can write;
<finalName>${pom.groupId}.${pom.artifactId}.${version}</finalName>
??
Cheers
Niclas
Re: [Maven Plugin] Additional fixes...
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Niclas Hedhman wrote:
> Well, looking closer at the Maven Release plugin, and I think we have an
> issue;
>
> It seems that it will only deploy the artifact (jar) to the artifact
> repository server under the canonical naming and do not follow <finalName> in
> the POM.
>
> This means that we WILL end up with a Jar file name == <artifactId>, no matter
> what, in the repository.
>
> Any suggestions on how we should deal with Maven vs Eclipse naming?? Do we
> need to care?
I would say we shouldn't care. I am in agreement with Maven. ;-)
-> richard
Re: [Maven Plugin] Additional fixes...
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Niclas Hedhman wrote:
> Well, looking closer at the Maven Release plugin, and I think we have an
> issue;
>
> It seems that it will only deploy the artifact (jar) to the artifact
> repository server under the canonical naming and do not follow <finalName> in
> the POM.
>
> This means that we WILL end up with a Jar file name == <artifactId>, no matter
> what, in the repository.
>
> Any suggestions on how we should deal with Maven vs Eclipse naming?? Do we
> need to care?
I would say we shouldn't care. For a change, I am in agreement with
Maven. ;-)
-> richard
Re: [Maven Plugin] Additional fixes...
Posted by Trygve Laugstøl <tr...@apache.org>.
Niclas Hedhman wrote:
> On Wednesday 31 May 2006 19:25, Trygve Laugstøl wrote:
>
>>Maven will not understand layouts per group id, only layouts per
>>repository which I think should be sufficient.
>
>
> So end of the day;
>
> Your suggestions leads to,
>
> 1. An Equinox compatible "layout".
Yep. The idea is to be able to develop and publish artifacts with Maven
and consume them directly from your favorite OSGi container. (or
OSGi-based IDE ;)
> 2. A public server with this layout where we can store OSGi
> bundles.
Yep.
> 3. Equinox/Eclipse and Felix/Maven live happily ever after ;o)
I was hoping that it would be possible to plug in support for
Maven-based artifacts in any OSGi container so that the container could
read directly from ibiblio or a special OSGi repository when resolving
bundle dependencies.
> My immediate question; What happens when such artifact is cached? Will that
> become a part of the normal cache or stored separately? And what about the
> "layout" and filenames in this case?
About the caching that will depend on who's doing the caching. If you
are using Maven all the way through it will do as it does today if you
use the default configuration, which means that it will download
releases once, but snapshots on every run.
> Hope you bare with me/us for trying to come to a good working solution.
I will, thanks for listening to what Maven has to offer :)
--
Trygve
Re: [Maven Plugin] Additional fixes...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 31 May 2006 19:25, Trygve Laugstøl wrote:
> Maven will not understand layouts per group id, only layouts per
> repository which I think should be sufficient.
So end of the day;
Your suggestions leads to,
1. An Equinox compatible "layout".
2. A public server with this layout where we can store OSGi
bundles.
3. Equinox/Eclipse and Felix/Maven live happily ever after ;o)
My immediate question; What happens when such artifact is cached? Will that
become a part of the normal cache or stored separately? And what about the
"layout" and filenames in this case?
Hope you bare with me/us for trying to come to a good working solution.
Cheers
Niclas
Re: [Maven Plugin] Additional fixes...
Posted by Trygve Laugstøl <tr...@apache.org>.
Niclas Hedhman wrote:
> On Wednesday 31 May 2006 15:46, Trygve Laugstøl wrote:
>
>>What you're describing here is the default Maven repository layout. With
>>your own "osgi" layout you should be able to name your artifacts just
>>like you want. Check out [1] for how to translate an artifact to a path.
>
>
> Well, the interface is all good and so on, but I don't se how that really fits
> into the discussion... Please enlighten me.
There seems to be a bit of confusion here between the naming of artifacts.
One name is the name that the file will get under target/ and the other
is the name in the repository. You do not want to change the name under
target/ because that means that you will have to configure all plugins
using it. It's just not worth the trouble for an intermediate file.
The repository one you have more control over like I'm trying to explain
below.
>
> 1. Maven do not like to have the groupId part of the filename. Equinox think
> it is a bit of a "must".
>
> 2. Maven insist of putting a dash between the artifactId and version in the
> filename, Equinox insist on an underscore.
This is still only true for the default layout[1], by making your own
layout you can translate from an Artifact which has the fields groupId,
artifactId, version etc which it IIRC translates into a path like:
$groupId.replace('.', '/')/$version/$artifactId-$version.$extension
What I was proposing was that you make a translator that returns this:
$groupId_$artifactId_$version.replace('-', '_')
(as you'll notice I'm not really aware of the OSGi naming rules)
I would suggest prefixing the path with the same group id directory
structure that the default layout uses because it can easily kill your
favorite ibiblio repository when you have a few hundred artifacts in there.
[1]:
https://svn.apache.org/repos/asf/maven/components/trunk/maven-artifact/src/main/java/org/apache/maven/artifact/repository/layout/DefaultRepositoryLayout.java
> These are by themselves nothing to worry or care about and very much personal
> preference et cetera.
>
>
> 3. Some people (Jeff) expresses a strong desire that the same filenames are
> used no matter where it is being used.
>
> 4. Jeff also insist on being able to put jars in a single directory, claiming
> management agents get an easier job.
>
> 5. Some people (Richard) likes to have short filenames.
>
> 6. Equinox is troubled by dashes in filenames, making it more difficult to
> use Maven produced bundles in Equinox.
3, 4 and 6 should be solved with a custom repository layout.
> 7. I think OBR client should work straight against Maven repository.
This should be possible today as long as the OBR client uses the correct
layout translator (be it "default" or "osgi")
> Did I forget something??
>
>
> So, in my PoV the "easiest" would be to;
>
> * have short artifactIds
> * filename created by [groupId].[artifactId]_[version].[qualifier]
> (dot, dash or underscroe in front of qualifier?)
> * OBR client can do searches (like Jeff suggested) but also work with
> groupId/artifactId and download straight from Maven repositories, incl
> the local cache management.
Just make sure you use the Maven components to do this.
> * Equinox needs no change.
> * Felix changes directory names and artifactIds.
>
> Is this at all possible??
>
> AFAICT, I can't make Maven understand that a particular group uses a different
> repository layout, and if it can manage a different layout "per repository
> host" then we might be in a position of something useful. So can it?
Maven will not understand layouts per group id, only layouts per
repository which I think should be sufficient.
--
Trygve
Re: [Maven Plugin] Additional fixes...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 01 June 2006 10:58, Jeff McAffer wrote:
> As a point of interest, why cant the group id be "felix"? It has been
> suggested that the path length and redundancy be eliminated by removing
> parts of the artifactID. Why not remove parts of the groupId?
That is because of the "Java Analogy" of getting things well organized in
large central repositories.
groupId = org.hedhman.niclas.some.application
artifactId = Habba
will end up inside directory;
<repoRoot>/org/hedhman/niclas/some/application/Habba/<version>/
Cheers
Niclas
Re: [Maven Plugin] Additional fixes...
Posted by Jeff McAffer <Je...@ca.ibm.com>.
"Richard S. Hall" <he...@ungoverned.org> wrote on 05/31/2006 05:42:18 AM:
> Niclas Hedhman wrote:
> > 4. Jeff also insist on being able to put jars in a single
> directory, claiming
> > management agents get an easier job.
Subtlety: It has been beaten into me time and again by consumers that
forcing them into particular layouts is problematic. Eclipse historically
has expected certain things from the layout and we have been working to
eliminate these expectations in response to the feedback we are getting.
It is not just management agents who are affected here. It is anyone who
has to ship, provide, store or organize bundles. Depending on your
usecases/scenarios this may be sysadmins, release engineers, developers,
end users, ... This is exactly the point, you are a producer creating a
bundle. The bundle as a whole should be as robust as possible and you do
well to avoid assumptions about how that bundle will be consumed.
> Since there is an implied parent-child relationship between groups and
> their artifacts. Currently, we have:
> * groupId = org.apache.felix
> * artifactId = org.apache.felix.subproject
As a point of interest, why cant the group id be "felix"? It has been
suggested that the path length and redundancy be eliminated by removing
parts of the artifactID. Why not remove parts of the groupId?
> Being able to have the first approach (without the redundancy and the
> short svn directory names), but with the freedom to name our resulting
> JAR files ${groupId}.${artifactId}-${version}.jar seems like it would be
> the holy grail.
Yes
Jeff
Re: [Maven Plugin] Additional fixes...
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Niclas Hedhman wrote:
> Well, the interface is all good and so on, but I don't se how that really fits
> into the discussion... Please enlighten me.
>
>
> 1. Maven do not like to have the groupId part of the filename. Equinox think
> it is a bit of a "must".
>
> 2. Maven insist of putting a dash between the artifactId and version in the
> filename, Equinox insist on an underscore.
>
> These are by themselves nothing to worry or care about and very much personal
> preference et cetera.
>
>
> 3. Some people (Jeff) expresses a strong desire that the same filenames are
> used no matter where it is being used.
>
> 4. Jeff also insist on being able to put jars in a single directory, claiming
> management agents get an easier job.
>
> 5. Some people (Richard) likes to have short filenames.
>
To clarify my position, I want to have short directory names in the svn
repo, but the directory names apparently have to be named after the
artifactId, which is currently org.apache.felix.blah..., which we
apparently need so that we can have long JAR names. I am not against
long JAR names, I just don't want my directories to be so long since I
use the command line.
Conceptually, it seems like it does make sense to have groupId and
artifactId be like:
* groupId = org.apache.felix
* artifactId = subproject
Since there is an implied parent-child relationship between groups and
their artifacts. Currently, we have:
* groupId = org.apache.felix
* artifactId = org.apache.felix.subproject
Which seems sort of redundant (and leads to long directory names). I was
told that we cannot disconnect artifactId from the svn directory name
without some consequences.
Being able to have the first approach (without the redundancy and the
short svn directory names), but with the freedom to name our resulting
JAR files ${groupId}.${artifactId}-${version}.jar seems like it would be
the holy grail.
> 7. I think OBR client should work straight against Maven repository.
>
OBR clients only work against the OBR service, however, I don't think it
would be difficult at all to make a maven repo look like an OBR repo,
assuming that it is a repo of bundles with the appropriate metadata.
> So, in my PoV the "easiest" would be to;
>
> * have short artifactIds
> * filename created by [groupId].[artifactId]_[version].[qualifier]
> (dot, dash or underscroe in front of qualifier?)
>
For the most part, I agree. I don't care about "_" or "-"...
> * OBR client can do searches (like Jeff suggested) but also work with
> groupId/artifactId and download straight from Maven repositories, incl
> the local cache management.
> * Equinox needs no change.
> * Felix changes directory names and artifactIds.
>
> Is this at all possible??
>
Good question.
-> richard
Re: [Maven Plugin] Additional fixes...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 31 May 2006 15:46, Trygve Laugstøl wrote:
> What you're describing here is the default Maven repository layout. With
> your own "osgi" layout you should be able to name your artifacts just
> like you want. Check out [1] for how to translate an artifact to a path.
Well, the interface is all good and so on, but I don't se how that really fits
into the discussion... Please enlighten me.
1. Maven do not like to have the groupId part of the filename. Equinox think
it is a bit of a "must".
2. Maven insist of putting a dash between the artifactId and version in the
filename, Equinox insist on an underscore.
These are by themselves nothing to worry or care about and very much personal
preference et cetera.
3. Some people (Jeff) expresses a strong desire that the same filenames are
used no matter where it is being used.
4. Jeff also insist on being able to put jars in a single directory, claiming
management agents get an easier job.
5. Some people (Richard) likes to have short filenames.
6. Equinox is troubled by dashes in filenames, making it more difficult to
use Maven produced bundles in Equinox.
7. I think OBR client should work straight against Maven repository.
Did I forget something??
So, in my PoV the "easiest" would be to;
* have short artifactIds
* filename created by [groupId].[artifactId]_[version].[qualifier]
(dot, dash or underscroe in front of qualifier?)
* OBR client can do searches (like Jeff suggested) but also work with
groupId/artifactId and download straight from Maven repositories, incl
the local cache management.
* Equinox needs no change.
* Felix changes directory names and artifactIds.
Is this at all possible??
AFAICT, I can't make Maven understand that a particular group uses a different
repository layout, and if it can manage a different layout "per repository
host" then we might be in a position of something useful. So can it?
Cheers
Niclas
Re: [Maven Plugin] Additional fixes...
Posted by Trygve Laugstøl <tr...@apache.org>.
Niclas Hedhman wrote:
> On Tuesday 30 May 2006 10:00, Jeff McAffer wrote:
>
>
>> Niclas Hedhman <he...@gmail.com> wrote on 05/29/2006 03:23:17 AM:
>>
>>> Any suggestions on how we should deal with Maven vs Eclipse naming?? Do
>>> we need to care?
>
>
>
> The other post was excellent, but...
>
>
>> IMHO we do need to care. This is a case of less is more. The Eclipse
>> community has developed a naming convention for its bundle JARs. As far
>> as I know, Maven does not have a convention since it covers a very wide
>> spectrum of usecases.
>
>
>
> There are a few restrictions imposed by Maven.
>
> * ArtifactID WILL become part of the filename together with Version
and Type.
> <finalname> is NOT respected for repository uploads. This would
require the
> FQDN style to use the FQDN in both group and artifact, generally
> discouraged by the Maven peeps, but totally doable.
>
> * Versions are appended to filename (as well as being part of the
directory
> structure) with a DASH. Underscore is not possible.
>
> * Versions during development contains -SNAPSHOT, which Equinox does
not like
> anywhere, and OSGi doesn't like in its own versioning (handled by
plugin).
What you're describing here is the default Maven repository layout. With
your own "osgi" layout you should be able to name your artifacts just
like you want. Check out [1] for how to translate an artifact to a path.
By having a "osgi" layout Maven should be able to both produce and
consume artifacts from osgi repositories directly.
> So, from my PoV it seems that Eclipse vs Maven is fairly incompatible
on this point, and I can only see three ways out;
>
> * Equinox makes concessions to support Maven's style.
>
> * Maven makes concessions to support Equinox's style.
>
> * We make a program that takes the published Maven artifacts, rename and
> republish to an Eclipse Update site, and possibly an OBR as well.
This can always be done as a extra deployment step when deploying a osgi
artifact. I assume you're going to make a osgi packaging which can
include such a step by default. This might be required anyway if you
need to update some extra index files or stuff like that.
[1]:
https://svn.apache.org/repos/asf/maven/components/trunk/maven-artifact/src/main/java/org/apache/maven/artifact/repository/layout/ArtifactRepositoryLayout.java
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
Re: [Maven Plugin] Additional fixes...
Posted by Jeff McAffer <Je...@ca.ibm.com>.
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: [Maven Plugin] Additional fixes...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 30 May 2006 23:16, Jeff McAffer wrote:
> Niclas Hedhman <he...@gmail.com> wrote on 05/30/2006 03:00:53 AM:
> This looks like an incompatibility between Maven and OSGi. As I
> understand your point, the maven-osgi plugin does some sort of
> transformation to make the version number acceptable at runtime. The OSGi
> spec does not allow '-' separators in the version number and Eclipse tools
> the OSGi spec. So this one may be harder to work around.
Yes, I added that the XX-Package set is scanned for version clauses and
exchanges the "-" with ".", as OSGi allows for a "qualifier" after the micro
part.
IIRC, the spec doesn't discuss file names with or without version in them, in
which case it is not about the OSGi spec, but about Eclipse tooling...
> > * Equinox makes concessions to support Maven's style.
>
> 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)
> > * Maven makes concessions to support Equinox's style.
>
> I would rephrase as enhancing Maven to better support OSGi. Certainly if
> Maven allowed _ as the name/version separator in the JAR name that would
> be ideal but the other issues seem more fundamental/important.
Maven is faced with a different angle of the same problem. Given
group+artifact+version+qualifier, it must download the artifact from a known
location, which is not "list files" capable.
There is a slight possibility to have the "Project Object Model" (pom) file
containing the separator, and let the pom file have the hard coded dash as a
separator, whilst the other artifact types of the same group+artifact will
follow the declared separator.
I think such change is very core in Maven, and would probably be hard to get
them to agree on, even if we do all the work.
> > * We make a program that takes the published Maven artifacts, rename
> > and republish to an Eclipse Update site, and possibly an OBR as well.
> This is interesting. Are you saying that when an artifact is taken out of
> the repo it should be renamed for use at runtime? This feels like a
> potential disconnect.
Well, the Maven problem is not so much about "local development", as one can
define a <finalname> for the Jar file in any format one wishes. The problem
is that during the "release process" where the artifacts gets uploaded to the
repository, it will use the well-formed artifact name, and not the
<finalname> declaration. Now, it seems that there are a couple of "provising
methods" to be handled;
* Local development
* Media, CD, zips and so forth
* OBR
* Eclipse Update
If we had a "public OBR" function, which is given a released
group+artifact+version, it could pick it up from the Maven central
repository, mangle it to suit OBR and then perform the upload and whatever
else required. Same principle for any other 'provisioning destination'.
> To me the essential point is that a bundle be standalone so that it can be
> used, unmodified, in many contexts. This means that it be self-describing
> and that the bundle JAR be uniquely named. As I understand the current
> situation, Maven avoids collisons by having a groupID/artifactID structure
> in the repo. For example, you could take the
> org.eclipse.core.runtime_3.2.0.jar bundle and make "org.eclipse" the group
> id and "core.runtime" the artifact id (with "3.2.0" the version and "jar"
> the type). Is that correct?
Essentially, yes. The dots in the groupId are exchanged for file separator, to
minimize single directory entries on public server (which has been huge
problem before this was introduced), whereas the artifactId is not.
> 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 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.
I still don't have a prioritized list, but feels bound by the limitations of
the tooling available, and am now faced with "one or the other", which I feel
to be a total loss for many...
> Side comment: publishing as an update site is interesting but we are
> certainly not pushing for that (at this time).
Ok.
> I would rather see update
> get more flexible to it can better understand other repo formats than try
> to get everyone to adopt our structure.
Agree.
Cheers
Niclas
Re: [Maven Plugin] Additional fixes...
Posted by Jeff McAffer <Je...@ca.ibm.com>.
Niclas Hedhman <he...@gmail.com> wrote on 05/30/2006 03:00:53 AM:
> There are a few restrictions imposed by Maven.
> * ArtifactID WILL become part of the filename together with Versionand
Type.
> <finalname> is NOT respected for repository uploads. This would
require the
> FQDN style to use the FQDN in both group and artifact, generally
> discouraged by the Maven peeps, but totally doable.
Maven question: Why is the group id influenced by the name chosen for the
artifact? That is, why would FQDN need to be used for both?
> * Versions are appended to filename (as well as being part of the
directory
> structure) with a DASH. Underscore is not possible.
Dash is technically feasible for us to allow in Eclipse. It would be
interesting to see if Maven could allow underscore.
> * Versions during development contains -SNAPSHOT, which Equinox does
not like
> anywhere, and OSGi doesn't like in its own versioning (handled by
plugin).
This looks like an incompatibility between Maven and OSGi. As I
understand your point, the maven-osgi plugin does some sort of
transformation to make the version number acceptable at runtime. The OSGi
spec does not allow '-' separators in the version number and Eclipse tools
the OSGi spec. So this one may be harder to work around.
> So, from my PoV it seems that Eclipse vs Maven is fairly incompatible on
this
> point, and I can only see three ways out;
>
> * Equinox makes concessions to support Maven's style.
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.
> * Maven makes concessions to support Equinox's style.
I would rephrase as enhancing Maven to better support OSGi. Certainly if
Maven allowed _ as the name/version separator in the JAR name that would
be ideal but the other issues seem more fundamental/important.
> * We make a program that takes the published Maven artifacts, rename
and
> republish to an Eclipse Update site, and possibly an OBR as well.
This is interesting. Are you saying that when an artifact is taken out of
the repo it should be renamed for use at runtime? This feels like a
potential disconnect. We've been working really hard to make seamless the
path between development time and runtime. That is, you run the bundles
you develop against without doing a deployment step or some such.
To me the essential point is that a bundle be standalone so that it can be
used, unmodified, in many contexts. This means that it be self-describing
and that the bundle JAR be uniquely named. As I understand the current
situation, Maven avoids collisons by having a groupID/artifactID structure
in the repo. For example, you could take the
org.eclipse.core.runtime_3.2.0.jar bundle and make "org.eclipse" the group
id and "core.runtime" the artifact id (with "3.2.0" the version and "jar"
the type). Is that correct?
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).
Side comment: publishing as an update site is interesting but we are
certainly not pushing for that (at this time). I would rather see update
get more flexible to it can better understand other repo formats than try
to get everyone to adopt our structure. Note also that to date, the vast
majority of our installations come as zips or product installs and do not
involve update sites (at least not in the initial provisioning).
Jeff
Re: [Maven Plugin] Additional fixes...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 30 May 2006 10:00, Jeff McAffer wrote:
> Niclas Hedhman <he...@gmail.com> wrote on 05/29/2006 03:23:17 AM:
> > Any suggestions on how we should deal with Maven vs Eclipse naming?? Do
> > we need to care?
The other post was excellent, but...
> IMHO we do need to care. This is a case of less is more. The Eclipse
> community has developed a naming convention for its bundle JARs. As far
> as I know, Maven does not have a convention since it covers a very wide
> spectrum of usecases.
There are a few restrictions imposed by Maven.
* ArtifactID WILL become part of the filename together with Version and Type.
<finalname> is NOT respected for repository uploads. This would require the
FQDN style to use the FQDN in both group and artifact, generally
discouraged by the Maven peeps, but totally doable.
* Versions are appended to filename (as well as being part of the directory
structure) with a DASH. Underscore is not possible.
* Versions during development contains -SNAPSHOT, which Equinox does not like
anywhere, and OSGi doesn't like in its own versioning (handled by plugin).
So, from my PoV it seems that Eclipse vs Maven is fairly incompatible on this
point, and I can only see three ways out;
* Equinox makes concessions to support Maven's style.
* Maven makes concessions to support Equinox's style.
* We make a program that takes the published Maven artifacts, rename and
republish to an Eclipse Update site, and possibly an OBR as well.
Any thoughts on that?
Cheers
Niclas
Re: [Maven Plugin] Additional fixes...
Posted by Jeff McAffer <Je...@ca.ibm.com>.
Niclas Hedhman <he...@gmail.com> wrote on 05/29/2006 03:23:17 AM:
> Any suggestions on how we should deal with Maven vs Eclipse naming?? Do
we
> need to care?
IMHO we do need to care. This is a case of less is more. The Eclipse
community has developed a naming convention for its bundle JARs. As far
as I know, Maven does not have a convention since it covers a very wide
spectrum of usecases. In the particular case of Felix bundle JARs you are
currently formulating your convention. For reasons outlined in another
post and considering value of presenting just one naming convention to the
consumers of OSGi technology I suggest that Felix use the same approach as
is used in Eclipse. Of course I am biased here but my heart is really
with the consumers on this. Less is more. FQDN_version.jar is widely
used, simple to describe, easy to understand and implement.
Jeff
Re: [Maven Plugin] Additional fixes...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 29 May 2006 15:11, Enrique Rodriguez wrote:
> Niclas Hedhman wrote:
> > On Monday 29 May 2006 14:31, Richard S. Hall wrote:
> >> Niclas Hedhman wrote:
> >>> On Friday 26 May 2006 20:55, Richard S. Hall wrote:
> >>>> I was wondering if it would be better to have:
> >>>>
> >>>> * pom.groupId = "org.apache.felix"
> >>>> * pom.artifactId = "scr"
> >>>>
> >>>> Thus, the symbolic name would be:
> >>>>
> >>>> * ${pom.groupId} + "." + ${pom.artifactId}
> >>>
> >>> So, the symbolic name == the concatenated group.artifact... How about
> >>> the Jar file name?? Is that getting the symbolic name + version ??
> >>
> >> Personally, I would rather have it be artifactId + version because the
> >> JAR filenames are way too long currently.
> >
> > And you don't see a problem with "scr-1.0.0.jar" ending up in potential
> > naming conflict??
> >
> > Personally, I have little preference. Eclipse uses FQDN_version.jar, and
> > there seems to be some reason behind that.
>
> My preference would be the longer "symbolic name + version" to avoid
> naming conflicts.
Well, looking closer at the Maven Release plugin, and I think we have an
issue;
It seems that it will only deploy the artifact (jar) to the artifact
repository server under the canonical naming and do not follow <finalName> in
the POM.
This means that we WILL end up with a Jar file name == <artifactId>, no matter
what, in the repository.
Any suggestions on how we should deal with Maven vs Eclipse naming?? Do we
need to care?
Cheers
Niclas
Re: [Maven Plugin] Additional fixes...
Posted by Enrique Rodriguez <en...@gmail.com>.
Richard S. Hall wrote:
> Niclas Hedhman wrote:
...
>> And you don't see a problem with "scr-1.0.0.jar" ending up in
>> potential naming conflict??
>>
>
> In conflict with what? The bundle JAR file will be used by the average
> user from a URL in OBR like:
>
> http://incubator.apache.org/felix/obr/scr-1.0.0.jar
>
> This URL is only intended to be used to install the bundle into the
> framework. There is no real reason for people to actually deal with the
> JAR file itself. Even then we could just append "felix." to the front or
> something, as opposed to "org.apache.felix.".
Richard makes a good point here. And, given the M2 constraint mentioned
by Niclas, I'm fine with "Jar file name == <artifactId>."
Enrique
Re: JAR file naming (was Re: [Maven Plugin] Additional fixes...)
Posted by Enrique Rodriguez <en...@gmail.com>.
Trustin Lee wrote:
> On 6/6/06, Rob Walker <ro...@ascert.com> wrote:
>>
>> Richard S. Hall wrote:
...
>> As simple as it is - I'm happy that such a naming convention would be
>> both clear and easy to use, and not have too many pitfalls for the
>> future.
>>
>> So I'd be happy to see this go to a vote.
>
>
> +1
I'm also fine with it and would like to see it go to a vote.
Enrique
Re: JAR file naming (was Re: [Maven Plugin] Additional fixes...)
Posted by Trustin Lee <tr...@gmail.com>.
On 6/6/06, Rob Walker <ro...@ascert.com> wrote:
>
> Richard S. Hall wrote:
> > Trustin Lee wrote:
> >> In Apache MINA, I decided to name the JAR files like this:
> >>
> >> mina-<subproject name>-<sub-sub-project name>-...jar.
> >>
> >> For example, there are JARs whose names are:
> >>
> >> * mina-core
> >> * mina-filter-compression
> >> * mina-filter-ssl
> >> * mina-integration-spring
> >> * mina-integration-jmx (this doesn't exist yet. It's just for
> example.)
> >>
> >> I understand Jeff's concern and it really becomes a problem as the
> >> number of
> >> subprojects increase. But I think we can manage this at least within
> >> Felix. For other projects outside of Felix which depends on Felix,
> they
> >> will have a different Maven groupId, so I think it's fine.
> >
> > So, does this mean that we are going to use this approach in Felix? Is
> > this something that is ready to vote on now?
> >
> As simple as it is - I'm happy that such a naming convention would be
> both clear and easy to use, and not have too many pitfalls for the future.
>
> So I'd be happy to see this go to a vote.
+1
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: JAR file naming (was Re: [Maven Plugin] Additional fixes...)
Posted by Rob Walker <ro...@ascert.com>.
Richard S. Hall wrote:
> Trustin Lee wrote:
>> In Apache MINA, I decided to name the JAR files like this:
>>
>> mina-<subproject name>-<sub-sub-project name>-...jar.
>>
>> For example, there are JARs whose names are:
>>
>> * mina-core
>> * mina-filter-compression
>> * mina-filter-ssl
>> * mina-integration-spring
>> * mina-integration-jmx (this doesn't exist yet. It's just for example.)
>>
>> I understand Jeff's concern and it really becomes a problem as the
>> number of
>> subprojects increase. But I think we can manage this at least within
>> Felix. For other projects outside of Felix which depends on Felix, they
>> will have a different Maven groupId, so I think it's fine.
>
> So, does this mean that we are going to use this approach in Felix? Is
> this something that is ready to vote on now?
>
As simple as it is - I'm happy that such a naming convention would be
both clear and easy to use, and not have too many pitfalls for the future.
So I'd be happy to see this go to a vote.
-- Rob
Re: JAR file naming (was Re: [Maven Plugin] Additional fixes...)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Trustin Lee wrote:
> In Apache MINA, I decided to name the JAR files like this:
>
> mina-<subproject name>-<sub-sub-project name>-...jar.
>
> For example, there are JARs whose names are:
>
> * mina-core
> * mina-filter-compression
> * mina-filter-ssl
> * mina-integration-spring
> * mina-integration-jmx (this doesn't exist yet. It's just for example.)
>
> I understand Jeff's concern and it really becomes a problem as the
> number of
> subprojects increase. But I think we can manage this at least within
> Felix. For other projects outside of Felix which depends on Felix, they
> will have a different Maven groupId, so I think it's fine.
So, does this mean that we are going to use this approach in Felix? Is
this something that is ready to vote on now?
-> richard
Re: JAR file naming (was Re: [Maven Plugin] Additional fixes...)
Posted by Trustin Lee <tr...@gmail.com>.
On 5/30/06, Jeff McAffer <Je...@ca.ibm.com> wrote:
>
> "Richard S. Hall" <he...@ungoverned.org> wrote on 05/30/2006 03:18:08 AM:
>
> > Interestingly enough, I just spent some time poking about the M2 repo on
>
> > ibiblio. If Felix were to adopt the FQDN approach for its libs, it
> > appears that we would be the only project in Apache doing so. On the
> > other hand, it does seem to be a semi-standard practice to prefix with
> > the project name, e.g., "felix-".
> >
> > So, apparently everyone else but Eclipse is doing it incorrectly. ;-)
>
> Finally, the truth well out! ;-) Seriously, prefixing with "felix"
> (whatever) would take care of most (but not all) of the collision
> concerns. The downside is that the approach is more complicated. It
> looks easy but how would you write down a guideline for newbies to follow.
> Something like "prefix your artifact id with your project name" might
> work. In cases where there are nested (sub) projects it is less clear.
> For example, we often have "core" and "ui" teams or "platform" sub
> projects in some "foo" project. Are those bundles then "foo.xxx",
> "foo.core.xxx" or "foo.platform.core.xxx"? Since the guideline is open to
> interpretation it is not a very strong convention. The FQDN convention is
> simple, clear and unambiguous. Note that in the examples here all that is
> really saved is the "org.apache" part of the name.
In Apache MINA, I decided to name the JAR files like this:
mina-<subproject name>-<sub-sub-project name>-...jar.
For example, there are JARs whose names are:
* mina-core
* mina-filter-compression
* mina-filter-ssl
* mina-integration-spring
* mina-integration-jmx (this doesn't exist yet. It's just for example.)
I understand Jeff's concern and it really becomes a problem as the number of
subprojects increase. But I think we can manage this at least within
Felix. For other projects outside of Felix which depends on Felix, they
will have a different Maven groupId, so I think it's fine.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: JAR file naming (was Re: [Maven Plugin] Additional fixes...)
Posted by Jeff McAffer <Je...@ca.ibm.com>.
"Richard S. Hall" <he...@ungoverned.org> wrote on 05/30/2006 03:18:08 AM:
> Interestingly enough, I just spent some time poking about the M2 repo on
> ibiblio. If Felix were to adopt the FQDN approach for its libs, it
> appears that we would be the only project in Apache doing so. On the
> other hand, it does seem to be a semi-standard practice to prefix with
> the project name, e.g., "felix-".
>
> So, apparently everyone else but Eclipse is doing it incorrectly. ;-)
Finally, the truth well out! ;-) Seriously, prefixing with "felix"
(whatever) would take care of most (but not all) of the collision
concerns. The downside is that the approach is more complicated. It
looks easy but how would you write down a guideline for newbies to follow.
Something like "prefix your artifact id with your project name" might
work. In cases where there are nested (sub) projects it is less clear.
For example, we often have "core" and "ui" teams or "platform" sub
projects in some "foo" project. Are those bundles then "foo.xxx",
"foo.core.xxx" or "foo.platform.core.xxx"? Since the guideline is open to
interpretation it is not a very strong convention. The FQDN convention is
simple, clear and unambiguous. Note that in the examples here all that is
really saved is the "org.apache" part of the name.
To be clear, I fully agree that at a technical level the name of the JAR
does not matter. However, quite a bit of software engineering is lowering
bars to understanding and entry. Simple and consistent practices are key
to promoting this.
> In truth, I can live with the long JAR file names. However, I would like
> to get rid of the long names in the repository. Yet however, I am told
> that the directory name should really match the artifactId for Maven.
> Yet another however, if we change the artifactId then the name of the
> JAR file gets shorten. Thus, we have to live with really long directory
> names in the repo, which is the only thing I would like to change. :-o
I'm not that familiar with how Maven works or where people are exposed to
repo directory names. I do feel however that tools should support and
encourage best practices. Perhaps Maven has never been faced with this
kind of usecase and needs to be updated to better support it.
Jeff
JAR file naming (was Re: [Maven Plugin] Additional fixes...)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Jeff McAffer wrote:
> This approach puts a heavy burden on bundle consumers. Perhaps at
> development time people are manually managing bundles and have an
> opportunity to define a "felix" or "eclipse" directory. Personally I do
> alot of this kind of bundle pushing and suspect it would be bothersome and
> error prone to have to manage the origin of bundles on an individual
> basis.
>
> Beyond that, the approach is very problematic for products. When you ship
> a product you want to put all the bundles (i.e., JARs) in one spot and
> have them installed. Whether that is on a provisioning server (may or may
> not be Maven or OBR), a CD, a zip or directly on the user's machine.
> Having to sort them according to origin would be somewhat less than
> optimal.
>
> I understand that in your workflows and usecases you do not handle JARs
> directly. In pretty much all of the usecases I have seen (Eclipse ones
> and plain OSGi ones) there reasons that people need or want to handle the
> JARs. Again, whether it is in the final deployment, on the install media,
> on the provisioning server, ... at some point in the lifecycle of a bundle
> the JAR will come in contact with other bundle JARs from other sources --
> naming collisions are therefore not just possible but likely. Prefixing
> the JAR name with "felix" or "eclipse" or, ... would certainly help.
> Personally I would vote for the fully qualified domain name for the same
> reasons Java developers use FQDNs for package names. It is simple and
> guaranteed best practice. This is deceptively important. The rest of the
> community (and not just the Apache community) is going to follow what you
> do here. Having an approach that is simple ("use the same model you use
> for picking package names") is powerful.
>
Interestingly enough, I just spent some time poking about the M2 repo on
ibiblio. If Felix were to adopt the FQDN approach for its libs, it
appears that we would be the only project in Apache doing so. On the
other hand, it does seem to be a semi-standard practice to prefix with
the project name, e.g., "felix-".
So, apparently everyone else but Eclipse is doing it incorrectly. ;-)
In truth, I can live with the long JAR file names. However, I would like
to get rid of the long names in the repository. Yet however, I am told
that the directory name should really match the artifactId for Maven.
Yet another however, if we change the artifactId then the name of the
JAR file gets shorten. Thus, we have to live with really long directory
names in the repo, which is the only thing I would like to change. :-o
-> richard
> Since most people in your shoes will be using OBR, perhaps the OBR client
> can be enhanced to allow for shortcuts etc. For example if you do a *src*
> search and get 4 numbered results, perhaps you can then say "install 3" to
> get the third result installed? That way you don't have to type any of
> the URL *or* the jar name. Everyone wins.
>
> Jeff
>
>
>
>
> "Richard S. Hall" <he...@ungoverned.org>
> 05/29/2006 04:39 AM
> Please respond to
> felix-dev@incubator.apache.org
>
>
> To
> felix-dev@incubator.apache.org
> cc
>
> Subject
> Re: [Maven Plugin] Additional fixes...
>
>
>
>
>
>
> I agree that this is the issue, however, if you are caching Felix
> bundles, you could just as easily create a "felix" directory in your
> cache of bundles so that you know where they come from. Which is
> essentially what maven does in its repo for all of its cached JAR files...
>
> I am afraid that this is one of those situations where there is not a
> single solution that solves every concern.
>
> -> richard
>
> Manuel Santillan wrote:
>
>> It's cumbersome to deal with long names (as well as long URLs). However,
>> having FQDN'd bundles may avoid some problems; e.g.,is this
>> agent-1.0.0.jar mine or someone else's? URLs do not completely solve the
>> problem, as some people (including myself) cache the bundles to avoid
>> network problems, so that URL!=UID. That's why we follow the equinox's
>> ${symbolic-name}-${version}.jar with FQDN sym-names approach.
>>
>> Just an opinion, though :-)
>>
>> Cheers,
>>
>> Manuel
>>
>>
>
>
>
Re: [Maven Plugin] Additional fixes...
Posted by Jeff McAffer <Je...@ca.ibm.com>.
This approach puts a heavy burden on bundle consumers. Perhaps at
development time people are manually managing bundles and have an
opportunity to define a "felix" or "eclipse" directory. Personally I do
alot of this kind of bundle pushing and suspect it would be bothersome and
error prone to have to manage the origin of bundles on an individual
basis.
Beyond that, the approach is very problematic for products. When you ship
a product you want to put all the bundles (i.e., JARs) in one spot and
have them installed. Whether that is on a provisioning server (may or may
not be Maven or OBR), a CD, a zip or directly on the user's machine.
Having to sort them according to origin would be somewhat less than
optimal.
I understand that in your workflows and usecases you do not handle JARs
directly. In pretty much all of the usecases I have seen (Eclipse ones
and plain OSGi ones) there reasons that people need or want to handle the
JARs. Again, whether it is in the final deployment, on the install media,
on the provisioning server, ... at some point in the lifecycle of a bundle
the JAR will come in contact with other bundle JARs from other sources --
naming collisions are therefore not just possible but likely. Prefixing
the JAR name with "felix" or "eclipse" or, ... would certainly help.
Personally I would vote for the fully qualified domain name for the same
reasons Java developers use FQDNs for package names. It is simple and
guaranteed best practice. This is deceptively important. The rest of the
community (and not just the Apache community) is going to follow what you
do here. Having an approach that is simple ("use the same model you use
for picking package names") is powerful.
Since most people in your shoes will be using OBR, perhaps the OBR client
can be enhanced to allow for shortcuts etc. For example if you do a *src*
search and get 4 numbered results, perhaps you can then say "install 3" to
get the third result installed? That way you don't have to type any of
the URL *or* the jar name. Everyone wins.
Jeff
"Richard S. Hall" <he...@ungoverned.org>
05/29/2006 04:39 AM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: [Maven Plugin] Additional fixes...
I agree that this is the issue, however, if you are caching Felix
bundles, you could just as easily create a "felix" directory in your
cache of bundles so that you know where they come from. Which is
essentially what maven does in its repo for all of its cached JAR files...
I am afraid that this is one of those situations where there is not a
single solution that solves every concern.
-> richard
Manuel Santillan wrote:
> It's cumbersome to deal with long names (as well as long URLs). However,
> having FQDN'd bundles may avoid some problems; e.g.,is this
> agent-1.0.0.jar mine or someone else's? URLs do not completely solve the
> problem, as some people (including myself) cache the bundles to avoid
> network problems, so that URL!=UID. That's why we follow the equinox's
> ${symbolic-name}-${version}.jar with FQDN sym-names approach.
>
> Just an opinion, though :-)
>
> Cheers,
>
> Manuel
>
Re: [Maven Plugin] Additional fixes...
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I agree that this is the issue, however, if you are caching Felix
bundles, you could just as easily create a "felix" directory in your
cache of bundles so that you know where they come from. Which is
essentially what maven does in its repo for all of its cached JAR files...
I am afraid that this is one of those situations where there is not a
single solution that solves every concern.
-> richard
Manuel Santillan wrote:
> It's cumbersome to deal with long names (as well as long URLs). However,
> having FQDN'd bundles may avoid some problems; e.g.,is this
> agent-1.0.0.jar mine or someone else's? URLs do not completely solve the
> problem, as some people (including myself) cache the bundles to avoid
> network problems, so that URL!=UID. That's why we follow the equinox's
> ${symbolic-name}-${version}.jar with FQDN sym-names approach.
>
> Just an opinion, though :-)
>
> Cheers,
>
> Manuel
>
Re: [Maven Plugin] Additional fixes...
Posted by Manuel Santillan <sa...@dit.upm.es>.
It's cumbersome to deal with long names (as well as long URLs). However,
having FQDN'd bundles may avoid some problems; e.g.,is this
agent-1.0.0.jar mine or someone else's? URLs do not completely solve the
problem, as some people (including myself) cache the bundles to avoid
network problems, so that URL!=UID. That's why we follow the equinox's
${symbolic-name}-${version}.jar with FQDN sym-names approach.
Just an opinion, though :-)
Cheers,
Manuel
--
Manuel Santillán <sa...@dit.upm.es>
http://www.dit.upm.es/santillan
Departamento de Ingeniería de Sistemas Telemáticos
Escuela Técnica Superior de Ingenieros de Telecomunicación
Universidad Politécnica de Madrid
Avda. Complutense, s/n
28040 Madrid SPAIN
Tel. +34 913367366 ext.3034
El lun, 29-05-2006 a las 03:21 -0400, Richard S. Hall escribió:
> Niclas Hedhman wrote:
> > On Monday 29 May 2006 14:31, Richard S. Hall wrote:
> >
> >> Niclas Hedhman wrote:
> >>
> >>> On Friday 26 May 2006 20:55, Richard S. Hall wrote:
> >>>
> >>>> I was wondering if it would be better to have:
> >>>>
> >>>> * pom.groupId = "org.apache.felix"
> >>>> * pom.artifactId = "scr"
> >>>>
> >>>> Thus, the symbolic name would be:
> >>>>
> >>>> * ${pom.groupId} + "." + ${pom.artifactId}
> >>>>
> >>> So, the symbolic name == the concatenated group.artifact... How about the
> >>> Jar file name?? Is that getting the symbolic name + version ??
> >>>
> >> Personally, I would rather have it be artifactId + version because the
> >> JAR filenames are way too long currently.
> >>
> >
> > And you don't see a problem with "scr-1.0.0.jar" ending up in potential naming
> > conflict??
> >
>
> In conflict with what? The bundle JAR file will be used by the average
> user from a URL in OBR like:
>
> http://incubator.apache.org/felix/obr/scr-1.0.0.jar
>
> This URL is only intended to be used to install the bundle into the
> framework. There is no real reason for people to actually deal with the
> JAR file itself. Even then we could just append "felix." to the front or
> something, as opposed to "org.apache.felix.".
>
> > Personally, I have little preference. Eclipse uses FQDN_version.jar, and there
> > seems to be some reason behind that.
>
> My preference is to avoid such long file names since I am at the command
> line a lot. However, I am flexible on the JAR naming approach. If people
> prefer the long name, then so be it.
>
> -> richard
Re: [Maven Plugin] Additional fixes...
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Niclas Hedhman wrote:
> On Monday 29 May 2006 14:31, Richard S. Hall wrote:
>
>> Niclas Hedhman wrote:
>>
>>> On Friday 26 May 2006 20:55, Richard S. Hall wrote:
>>>
>>>> I was wondering if it would be better to have:
>>>>
>>>> * pom.groupId = "org.apache.felix"
>>>> * pom.artifactId = "scr"
>>>>
>>>> Thus, the symbolic name would be:
>>>>
>>>> * ${pom.groupId} + "." + ${pom.artifactId}
>>>>
>>> So, the symbolic name == the concatenated group.artifact... How about the
>>> Jar file name?? Is that getting the symbolic name + version ??
>>>
>> Personally, I would rather have it be artifactId + version because the
>> JAR filenames are way too long currently.
>>
>
> And you don't see a problem with "scr-1.0.0.jar" ending up in potential naming
> conflict??
>
In conflict with what? The bundle JAR file will be used by the average
user from a URL in OBR like:
http://incubator.apache.org/felix/obr/scr-1.0.0.jar
This URL is only intended to be used to install the bundle into the
framework. There is no real reason for people to actually deal with the
JAR file itself. Even then we could just append "felix." to the front or
something, as opposed to "org.apache.felix.".
> Personally, I have little preference. Eclipse uses FQDN_version.jar, and there
> seems to be some reason behind that.
My preference is to avoid such long file names since I am at the command
line a lot. However, I am flexible on the JAR naming approach. If people
prefer the long name, then so be it.
-> richard
Re: [Maven Plugin] Additional fixes...
Posted by Enrique Rodriguez <en...@gmail.com>.
Niclas Hedhman wrote:
> On Monday 29 May 2006 14:31, Richard S. Hall wrote:
>> Niclas Hedhman wrote:
>>> On Friday 26 May 2006 20:55, Richard S. Hall wrote:
>>>> I was wondering if it would be better to have:
>>>>
>>>> * pom.groupId = "org.apache.felix"
>>>> * pom.artifactId = "scr"
>>>>
>>>> Thus, the symbolic name would be:
>>>>
>>>> * ${pom.groupId} + "." + ${pom.artifactId}
>>> So, the symbolic name == the concatenated group.artifact... How about the
>>> Jar file name?? Is that getting the symbolic name + version ??
>> Personally, I would rather have it be artifactId + version because the
>> JAR filenames are way too long currently.
>
> And you don't see a problem with "scr-1.0.0.jar" ending up in potential naming
> conflict??
>
> Personally, I have little preference. Eclipse uses FQDN_version.jar, and there
> seems to be some reason behind that.
My preference would be the longer "symbolic name + version" to avoid
naming conflicts.
Enrique
Re: [Maven Plugin] Additional fixes...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 29 May 2006 14:31, Richard S. Hall wrote:
> Niclas Hedhman wrote:
> > On Friday 26 May 2006 20:55, Richard S. Hall wrote:
> >> I was wondering if it would be better to have:
> >>
> >> * pom.groupId = "org.apache.felix"
> >> * pom.artifactId = "scr"
> >>
> >> Thus, the symbolic name would be:
> >>
> >> * ${pom.groupId} + "." + ${pom.artifactId}
> >
> > So, the symbolic name == the concatenated group.artifact... How about the
> > Jar file name?? Is that getting the symbolic name + version ??
>
> Personally, I would rather have it be artifactId + version because the
> JAR filenames are way too long currently.
And you don't see a problem with "scr-1.0.0.jar" ending up in potential naming
conflict??
Personally, I have little preference. Eclipse uses FQDN_version.jar, and there
seems to be some reason behind that.
Cheers
Niclas
Re: [Maven Plugin] Additional fixes...
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Niclas Hedhman wrote:
> On Friday 26 May 2006 20:55, Richard S. Hall wrote:
>
>> I was wondering if it would be better to have:
>>
>> * pom.groupId = "org.apache.felix"
>> * pom.artifactId = "scr"
>>
>> Thus, the symbolic name would be:
>>
>> * ${pom.groupId} + "." + ${pom.artifactId}
>>
>
> So, the symbolic name == the concatenated group.artifact... How about the Jar
> file name?? Is that getting the symbolic name + version ??
Personally, I would rather have it be artifactId + version because the
JAR filenames are way too long currently.
-> richard
Re: [Maven Plugin] Additional fixes...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 26 May 2006 20:55, Richard S. Hall wrote:
> I was wondering if it would be better to have:
>
> * pom.groupId = "org.apache.felix"
> * pom.artifactId = "scr"
>
> Thus, the symbolic name would be:
>
> * ${pom.groupId} + "." + ${pom.artifactId}
So, the symbolic name == the concatenated group.artifact... How about the Jar
file name?? Is that getting the symbolic name + version ??
Cheers
Niclas
Re: [Maven Plugin] Additional fixes...
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Niclas Hedhman wrote:
> On Friday 26 May 2006 20:55, Richard S. Hall wrote:
>
>> I am not sure what the value of ${pom.url} is, so I am not sure if this
>> would be a good default. Bundle-URL is supposed to be a URL that points
>> to where you can download the bundle.
>>
>
> pom.url == The URL to the project's homepage.
>
> Which I think maps well to the OSGi attribute Bundle-DocURL...
>
Yes, it makes more sense to map it to Bundle-DocURL.
-> richard
Re: [Maven Plugin] Additional fixes...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 26 May 2006 20:55, Richard S. Hall wrote:
> I am not sure what the value of ${pom.url} is, so I am not sure if this
> would be a good default. Bundle-URL is supposed to be a URL that points
> to where you can download the bundle.
pom.url == The URL to the project's homepage.
Which I think maps well to the OSGi attribute Bundle-DocURL...
Cheers
Niclas
Re: [Maven Plugin] Additional fixes...
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Niclas Hedhman wrote:
> I think it would be good if one was allowed to use ${pom.version} for version
> attribute in Export-Package. There are two issues as far as I can see;
>
> 1. -SNAPSHOT is not allowed at all.
>
Because of the '-' ? For Felix I automatically map this to a '.', so
that I end up with "0.8.0.SNAPSHOT"...seems workable.
> 2. Does the package version evolve at some other rate than the bundle? And
> should one perhaps only use the first two digit groups for the package
> version.
>
I think it is worthwhile to have it be possible to use ${pom.version}
for export package version, but it should clearly not be the default.
Since packages can be included into any arbitrary bundle, there is no
default relationship between the deployment unit version (i.e.,
${pom.version}) and the package version.
> I also think that
>
> * <bundleSymbolicName> should default to ${pom.artifactId}
>
Yes, this is what I am doing already in my pom files. However, I was
wondering lately if we are doing the artifactId the best way. Right now
we have, for example:
* pom.groupId = "org.apache.felix"
* pom.artifactId = "org.apache.felix.scr"
I was wondering if it would be better to have:
* pom.groupId = "org.apache.felix"
* pom.artifactId = "scr"
Thus, the symbolic name would be:
* ${pom.groupId} + "." + ${pom.artifactId}
This would coincide with us cleaning up our trunk directory to only show
the unique part of the subproject name, as opposed to the groupId part.
I am not sure if this would be a good move or a bad move from a maven
perspective, though.
> * <bundleName> should default to ${pom.name}
>
> * <bundleDescription> should default to ${pom.description}
>
> * <bundleVendor> should default to ${pom.organization.name}
>
> * <bundleVersion> should default to ${pom.version} (see above).
>
> * bundleContactAddress should default to ${pom.organization.url}
>
> * <bundleUrl> and/or <bundleUpdateLocation> should default to ${pom.url}
>
I am not sure what the value of ${pom.url} is, so I am not sure if this
would be a good default. Bundle-URL is supposed to be a URL that points
to where you can download the bundle.
There should NOT be any default for Bundle-UpdateLocation since this
will explicitly impact how bundles are updated. This tends to cause
confusion among developers when they make edits to a bundle, then type
"update", but not have it update because it was updating from the update
location instead of their local bundle. We should let OBR worry about
how to update bundles and not try to bake it in.
> * <bundleCopyright should default to
> Copyright ${pom.inceptionYear}, ${pom.organization.name}
>
> * A whole bunch of other properties to read from file(s) in the project
> directory instead, including <exportPackage>, <excludeImport>
> Or perhaps utlize the <properties> tag in the pom main section...
>
> If that is done, then one can move the whole <plugin> section of the POM to a
> (grand)*parent pom, which I think simplifies 'standard cases', still allowing
> for the current form.
>
I would like to think about how we can do these latter suggestions in
such a way that mangen and the maven plugin can cooperate, since these
types of issues need to be solved by mangen too.
-> richard
Re: [Maven Plugin] Additional fixes...
Posted by Alex Karasulu <ao...@bellsouth.net>.
Niclas Hedhman wrote:
> On Friday 26 May 2006 18:26, Peter Kriens wrote:
>
>> I think it is a very good idea to derive the bundle headers from
>> standard pom properties. This will make it easier for others to
>> include the OSGi headers.
>>
>> I am not a committer, but if I was I did a +1
>>
>
> Regardless, everyone's opinion count, especially yours... ;o)
>
Yeah that's an understatement.
Alex
Re: [Maven Plugin] Additional fixes...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 26 May 2006 18:26, Peter Kriens wrote:
> I think it is a very good idea to derive the bundle headers from
> standard pom properties. This will make it easier for others to
> include the OSGi headers.
>
> I am not a committer, but if I was I did a +1
Regardless, everyone's opinion count, especially yours... ;o)
Cheers
Niclas
Re: [Maven Plugin] Additional fixes...
Posted by Peter Kriens <Pe...@aQute.se>.
I think it is a very good idea to derive the bundle headers from
standard pom properties. This will make it easier for others to
include the OSGi headers.
I am not a committer, but if I was I did a +1
Kind regards,
Peter Kriens
NH> Hi,
NH> I think it would be good if one was allowed to use ${pom.version} for version
NH> attribute in Export-Package. There are two issues as far as I can see;
NH> 1. -SNAPSHOT is not allowed at all.
NH> 2. Does the package version evolve at some other rate than the bundle? And
NH> should one perhaps only use the first two digit groups for the package
NH> version.
NH> I also think that
NH>
NH> * <bundleSymbolicName> should default to ${pom.artifactId}
NH> * <bundleName> should default to ${pom.name}
NH> * <bundleDescription> should default to ${pom.description}
NH> * <bundleVendor> should default to ${pom.organization.name}
NH> * <bundleVersion> should default to ${pom.version} (see above).
NH> * bundleContactAddress should default to ${pom.organization.url}
NH> * <bundleUrl> and/or <bundleUpdateLocation> should default to ${pom.url}
NH> * <bundleCopyright should default to
NH> Copyright ${pom.inceptionYear}, ${pom.organization.name}
NH> * A whole bunch of other properties to read from file(s) in the project
NH> directory instead, including <exportPackage>, <excludeImport>
NH> Or perhaps utlize the <properties> tag in the pom main section...
NH> If that is done, then one can move the whole <plugin> section of the POM to a
NH> (grand)*parent pom, which I think simplifies 'standard cases', still allowing
NH> for the current form.
NH> Willing to do the work, but before wasting my time, I would like to get some
NH> feedback.
NH> WDYT?
NH> Cheers
NH> Niclas
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599