The Maven developers have been discussing the future repository format so I can speak
with reasonable authority on this.
> [X] +1 Put everything in one directory (such as jakarta-taglibs)
> Advantage: less groups on ibiblio
> Disadvantage: the group is going to be huge (around 30-80 files on
> each artifact sub-dir)
What do you mean "each artifact sub-dir"?
I imagine this is less work for you, and is best compatible with the future direction.
This is my vote. So you'd start out with:
taglibs/jars/taglibs-standard-1.0.1.jar
(I'd stick with the existing taglibs group for now).
When you convert to Maven, this means your groupID is "taglibs" and your artifactId
is "taglibs-XXX" for each project.
I think we'll have jakarta-commons move that way in the long run, eventually with a
structure like
org/apache/jakarta/commons/collections/1.0.1/commons-collections-1.0.1.jar.
> [ ] +1 Create one directory for group (ex: taglibs-standard,
> taglibs-request).
> Advantages: easier to locate artifacts; consistent with the way
> Jakarta Commons is organized
> [ ] +0 Doesn't matter for me
This will further nuke ibiblio's root directory. -1.
> 2.(In case one directory wins previous poll)
> [ ] +1 Use new directory 'jakarta-taglibs
> Advantage: better identify which taglibs that group refers too
> Disadvantage: replication of existing directory ('taglibs')
> [X] +1 Use existing directory 'taglibs'
> Advantage: no replication of existing directory
> Disadvantage: name is too generic
> [ ] +0 Doesn't matter for me
just echoing above. Will fix it later, but for now I'd say we can keep it as is
without
affecting users. It will be reserved for jakarta-taglibs, not for any taglibs project.
> 3.Where to put jstl.jar
Is this something you've built, or is it from Sun? We can't redistribute it if it is
from Sun due
to the license. Assuming it is something built by taglibs, I think taglibs-jstl.jar is
appropriate
and can be put in the taglibs directory too.
> [ ] +1 Wherever standard.jar is
> Advantage: jstl.jar is created by Jakarta Standard Taglibs
> Disadvantage: it's a JCP API of its own; replication of existing
> directory ('jstl')
> [ ] +1 On existing group jstl
> Advantage: no replication of existing directory; better separation
> between specification (JSTL) and implementation (Jakarta Standard
> Taglibs)
> Disadvantage: jar is created by another project (there is no JSTL
> project on Jakarta/ASF); inconsistent with another groups (like
> servletapi)
> [ ] +1 On new group jstlapi
> Advantage: consistent with another groups (like servletapi); better
> separation between specification (JSTL) and implementation (Jakarta
> Standard Taglibs)
> Disadvantage: jar is created by another project (there is no JSTL
> project on Jakarta/ASF), replication of existing directory ('jstl');
> ugly name
> [ ] +0 Doesn't matter for me
> Notice that this is note a typical committer-issue-vote (it's not even
> totally related to the Maven project itself), but I rather listen your
> opinions now then decide the structure myself and have to handle the
> consequences later (specially because we cannot change it once it's
> uploaded to ibiblio).
You can copy later, but you can't remove anything. The deprecation idea is probably
something that will be more feasible in the maven 2 timeframe as there could be an
application handling the repository instead of a flat file system.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
