You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2006/05/30 09:18:08 UTC
JAR file naming (was Re: [Maven Plugin] Additional fixes...)
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: 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