RE: [VOTE] Options for the Jakarta Taglibs Maven repository
Sorry, I've read your last mail just after sending mine. I know you're doing a great job. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 03, 2004 11:40 PM To: Maven Developers List Subject: RE: [VOTE] Options for the Jakarta Taglibs Maven repository Rather than going over it all, it might be helpful to read this: http://docs.codehaus.org/display/MAVEN/Repository+-+Layout Cheers, Brett Quoting Carlos Sanchez [EMAIL PROTECTED]: Hi, I just think that jstl shouldn't be mixed with concrete implementations. About the other issues with group names maybe we should consider the repository layout. Currently anyone can request an upload to any group and I think this won't scale well and can lead to conflict problems. Having strict naming conventions will avoid problems like those happening now with jakarta-taglibs. A solution could be adding the domain or package name in some way, e.g. apache.jakarta.taglibs apache-jakarta-taglibs apache/jakarta/taglibs Anything after the domain name would be responsability of the domain owner. Regards Carlos Sanchez A Coruña, Spain Oness Project http://oness.sourceforge.net -Original Message- From: Felipe Leme [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 03, 2004 1:19 PM To: Maven Developers List Subject: Re: [VOTE] Options for the Jakarta Taglibs Maven repository Oops, forgot my votes: 1.Multiple directories x one directory: [X ] +1 Create one directory for group (ex: taglibs-standard, taglibs-request). Advantages: easier to locate artifacts; consistent with the way Jakarta Commons is organized 3.Where to put jstl.jar [X] +1 On existing group jstl Advantage: no replication of existing directory; better separation between specification (JSTL) and implementation (Jakarta Standard Taglibs) For this one, I changed my mind after Carlos' messages... -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Options for the Jakarta Taglibs Maven repository
That whats tough about Sun releasing jars as a standard. Where should the api's be stored! Ultimately, I believe there are distribution clauses in the lisences for these things that allow us to distribute them in Apache software, this should also probibly apply to the repository as well. If we can, then definitely one copy. I even think putting them all in a Sun JARs groupID for now is worthwhile to make sure they stay the same. I think the Maven PMC can take another look at this and see where we are at. Like Brett said, we just don't have the transition to those naming conventions stablized yet (sigh) is a very painfull transition that is This will definitely happen on the Maven end some time this year. I'm not sure how we are going to transition old apps to the new repo format (haven't discussed that yet). We'll at least have a new copy of the repo set up. Just on the point of this URL from your other email: org/apache/jakarta/commons/collections/1.0.1/commons-collections-1.0.1.jar. vs org/apache/jakarta/commons/collections/1.0.1/collections-1.0.1.jar. The artifactID is the choice of the project, as they own the groupID. I'd suggest keeping commons-collections, as this is the filename used later. That would be the name when it is bundled into a WAR, for example, and it is how they are named now. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Options for the Jakarta Taglibs Maven repository
[*] +1 Create one directory for group
Notice some artifact allready have been uploaded on ibiblio in inconsistant
directories :
/xerces/jars/xmlParserApis-2.0.0/2.0.2/2.2.1
=
/xml-apis/jars/xmlParserApis-2.0.0/2.0.2
Assuming 2.2.1 is only in xerces group, it looks to be the 'correct' groupid for this
artifact. But for compatibility
those jars remain in xml-api with a Readme.html warning.
MAVEN ENHANCEMENT SUGGESTION:
Could'nt we have an automatic way to 'deprecate' some artifcat location, giving the
alternative group/artifactId to be
used ? It may been displayed by maven as a warning when downloading dependencies.
For example, a stamp file groupid/type/artifactid-version.deprecated may be a text
file containing the warning message
that maven can search when it downloads an artifact.
Nico.
- Original Message -
From: Felipe Leme [EMAIL PROTECTED]
To: Maven Developers List [EMAIL PROTECTED]
Sent: Tuesday, August 03, 2004 7:02 AM
Subject: [VOTE] Options for the Jakarta Taglibs Maven repository
Hi all,
As we haven't reached a common sense on how to name the groups, I think
we should vote for it. The issues are:
1.Multiple directories x one directory:
[ ] +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)
[ ] +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
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')
[ ] +1 Use existing directory 'taglibs'
Advantage: no replication of existing directory
Disadvantage: name is too generic
[ ] +0 Doesn't matter for me
3.Where to put jstl.jar
[ ] +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).
Regards,
Felipe
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Our name has changed. Please update your address book to the following format:
[EMAIL PROTECTED].
This message contains information that may be privileged or confidential and is the
property of the Capgemini Group. It is intended only for the person to whom it is
addressed. If you are not the intended recipient, you are not authorized to read,
print, retain, copy, disseminate, distribute, or use this message or any part
thereof. If you receive this message in error, please notify the sender immediately
and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Options for the Jakarta Taglibs Maven repository
On Tue, 2004-08-03 at 02:21, John Casey wrote: Just curious, but are you in control of the jakarta-taglibs builds? Yes, I am one of the committers. understand if you're pinging the maven-dev list for best practices (I Agree, but I'm not subscribed there (and started the thread here). Could you please forward it for me? jakarta-taglibs organization on ibiblio, you're talking to the wrong people...the taglibs people are able to control that. That thread started a couple of months ago, but just now I've taking the steps to make it available (the original post suggested one directory only, but I created many and nobody complained): http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=656477 In other words, it doesn't really matter for us (taglibs developers), this is more concerned to Maven users and ibiblio maintainers. -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Options for the Jakarta Taglibs Maven repository
On Tue, 2004-08-03 at 03:44, Nicolas De Loof wrote: MAVEN ENHANCEMENT SUGGESTION: Could'nt we have an automatic way to 'deprecate' some artifcat location, giving the alternative group/artifactId to be used ? It may been displayed by maven as a warning when downloading dependencies. For example, a stamp file groupid/type/artifactid-version.deprecated may be a text file containing the warning message that maven can search when it downloads an artifact. That would be nice, and I guess it wouldn't be hard to implement... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Options for the Jakarta Taglibs Maven repository
Oops, forgot my votes: 1.Multiple directories x one directory: [X ] +1 Create one directory for group (ex: taglibs-standard, taglibs-request). Advantages: easier to locate artifacts; consistent with the way Jakarta Commons is organized 3.Where to put jstl.jar [X] +1 On existing group jstl Advantage: no replication of existing directory; better separation between specification (JSTL) and implementation (Jakarta Standard Taglibs) For this one, I changed my mind after Carlos' messages... -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Options for the Jakarta Taglibs Maven repository
Felipe Leme wrote:
Hi all,
As we haven't reached a common sense on how to name the groups, I think
we should vote for it. The issues are:
1.Multiple directories x one directory:
[ ] +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)
[ ] +1 Create one directory for group (ex: taglibs-standard,
taglibs-request).
Advantages: easier to locate artifacts; consistent with the way
Jakarta Commons is organized
+1 The decision on which structure to use should be more dependent on
the type of group structure you have. If you expect the various
subgroups of your group to be releasing on separate schedules and/or
have new sub-groups created, then I would recommend you place the
artifacts into their own project directories. This way the various
groups can maintain separate directory structures with separate
contents, which will be easier to manage.
[ ] +0 Doesn't matter for me
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')
+1 just because an old directory exists, doesn't mean that you as the
individual managing taglibs maven release can't choose a new one, your
the canonical source for these files. 'taglibs' is very generic.
[ ] +1 Use existing directory 'taglibs'
Advantage: no replication of existing directory
Disadvantage: name is too generic
-1 I agree, we see this problem arise in other areas of the repository,
if it can be cleaned out, (or deprecated as the other thread suggests,
that would be good)
[ ] +0 Doesn't matter for me
3.Where to put jstl.jar
[ ] +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 this sounds good, JSTL is fairly unique in the community, I don't
beleive there will be any naming clashes.
[ ] +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).
Regards,
Felipe
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Options for the Jakarta Taglibs Maven repository
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]
Re: [VOTE] Options for the Jakarta Taglibs Maven repository
Just a suggestion, that may be a bad idea...
What about setting groupid to taglibs/standard ?
That may allow using a more hierarchical repository (www.ibiblio.org/maven has so much
directories...)
repository_root
- taglibs
- standard
- artifact_type = jars
- artifact-version.jar
- string
...
...
I've tried it with maven 1.0RC4 and it works !
Nico.
I thought I should discuss a little further since Mark disagrees on some points here.
+1 The decision on which structure to use should be more dependent on
the type of group structure you have. If you expect the various
subgroups of your group to be releasing on separate schedules and/or
have new sub-groups created, then I would recommend you place the
artifacts into their own project directories. This way the various
groups can maintain separate directory structures with separate
contents, which will be easier to manage.
I couldn't parse this statement at all (no coffee :), so sorry if I'm on the wrong
track with
what you said. I don't see what the release schedule has to do with the directory
structure.
Releasing is pushing to a directory and you don't need to do anything there after
that.
Perhaps it would be best if you could reply to anything you don't agree with on my
other
email just sent as a starting point for a discussion.
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')
+1 just because an old directory exists, doesn't mean that you as the
individual managing taglibs maven release can't choose a new one, your
the canonical source for these files. 'taglibs' is very generic.
I agree on this point, I just know that we have a plan to resolve this issue, so
would prefer
that it stay the same now. Having said that, if you desperately want
jakarta-taglibs, that's
a non-issue for me really.
[ ] +1 Use existing directory 'taglibs'
Advantage: no replication of existing directory
Disadvantage: name is too generic
-1 I agree, we see this problem arise in other areas of the repository,
if it can be cleaned out, (or deprecated as the other thread suggests,
that would be good)
As above, since no deprecation is available, I think it is better to keep this for
now.
Thanks!
- Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Our name has changed. Please update your address book to the following format:
[EMAIL PROTECTED].
This message contains information that may be privileged or confidential and is the
property of the Capgemini Group. It is intended only for the person to whom it is
addressed. If you are not the intended recipient, you are not authorized to read,
print, retain, copy, disseminate, distribute, or use this message or any part
thereof. If you receive this message in error, please notify the sender immediately
and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Options for the Jakarta Taglibs Maven repository
Hi, I just think that jstl shouldn't be mixed with concrete implementations. About the other issues with group names maybe we should consider the repository layout. Currently anyone can request an upload to any group and I think this won't scale well and can lead to conflict problems. Having strict naming conventions will avoid problems like those happening now with jakarta-taglibs. A solution could be adding the domain or package name in some way, e.g. apache.jakarta.taglibs apache-jakarta-taglibs apache/jakarta/taglibs Anything after the domain name would be responsability of the domain owner. Regards Carlos Sanchez A Coruña, Spain Oness Project http://oness.sourceforge.net -Original Message- From: Felipe Leme [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 03, 2004 1:19 PM To: Maven Developers List Subject: Re: [VOTE] Options for the Jakarta Taglibs Maven repository Oops, forgot my votes: 1.Multiple directories x one directory: [X ] +1 Create one directory for group (ex: taglibs-standard, taglibs-request). Advantages: easier to locate artifacts; consistent with the wayJakarta Commons is organized 3.Where to put jstl.jar [X] +1 On existing group jstl Advantage: no replication of existing directory; better separation between specification (JSTL) and implementation (Jakarta Standard Taglibs) For this one, I changed my mind after Carlos' messages... -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Options for the Jakarta Taglibs Maven repository@cpqd.com.br
On Tue, 3 Aug 2004 16:29:06 +0200, Nicolas De Loof [EMAIL PROTECTED] wrote: Just a suggestion, that may be a bad idea... I don't think it's a bad idea, but... What about setting groupid to taglibs/standard ? That may allow using a more hierarchical repository (www.ibiblio.org/maven has so much directories...) According to Brett's previous message, looks like that's the plan for the future. So we better not apply that structure now... Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Options for the Jakarta Taglibs Maven repository
Rather than going over it all, it might be helpful to read this: http://docs.codehaus.org/display/MAVEN/Repository+-+Layout Cheers, Brett Quoting Carlos Sanchez [EMAIL PROTECTED]: Hi, I just think that jstl shouldn't be mixed with concrete implementations. About the other issues with group names maybe we should consider the repository layout. Currently anyone can request an upload to any group and I think this won't scale well and can lead to conflict problems. Having strict naming conventions will avoid problems like those happening now with jakarta-taglibs. A solution could be adding the domain or package name in some way, e.g. apache.jakarta.taglibs apache-jakarta-taglibs apache/jakarta/taglibs Anything after the domain name would be responsability of the domain owner. Regards Carlos Sanchez A Coruña, Spain Oness Project http://oness.sourceforge.net -Original Message- From: Felipe Leme [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 03, 2004 1:19 PM To: Maven Developers List Subject: Re: [VOTE] Options for the Jakarta Taglibs Maven repository Oops, forgot my votes: 1.Multiple directories x one directory: [X ] +1 Create one directory for group (ex: taglibs-standard, taglibs-request). Advantages: easier to locate artifacts; consistent with the wayJakarta Commons is organized 3.Where to put jstl.jar [X] +1 On existing group jstl Advantage: no replication of existing directory; better separation between specification (JSTL) and implementation (Jakarta Standard Taglibs) For this one, I changed my mind after Carlos' messages... -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Options for the Jakarta Taglibs Maven repository
Brett Porter wrote: I thought I should discuss a little further since Mark disagrees on some points here. +1 The decision on which structure to use should be more dependent on the type of group structure you have. If you expect the various subgroups of your group to be releasing on separate schedules and/or have new sub-groups created, then I would recommend you place the artifacts into their own project directories. This way the various groups can maintain separate directory structures with separate contents, which will be easier to manage. I couldn't parse this statement at all (no coffee :), so sorry if I'm on the wrong track with what you said. I don't see what the release schedule has to do with the directory structure. Releasing is pushing to a directory and you don't need to do anything there after that. Perhaps it would be best if you could reply to anything you don't agree with on my other email just sent as a starting point for a discussion. I think I'm the one who didn't have enough coffee when I wrote this... ;-) I'll respond in kind to your other thread. -- Mark R. Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Options for the Jakarta Taglibs Maven repository
Carlos Sanchez wrote: Hi, I just think that jstl shouldn't be mixed with concrete implementations. That whats tough about Sun releasing jars as a standard. Where should the api's be stored! Ultimately, I believe there are distribution clauses in the lisences for these things that allow us to distribute them in Apache software, this should also probibly apply to the repository as well. The point in keeping this separate from the taglibs is that they can be maintained as to not have multiple copies in the repository. For instance, if tomcat releases jasper with jstl included and taglibs releases standard with the jstl ja included too, then there are two copies of the jar present in the repository. Where, if they both list them separately as a dependency, then we can maintain just a single copy of the jar in the repository as a separate project, both can reference it as a dependency, thus I think its important that it be separate, just like the servletapi. About the other issues with group names maybe we should consider the repository layout. Currently anyone can request an upload to any group and I think this won't scale well and can lead to conflict problems. Having strict naming conventions will avoid problems like those happening now with jakarta-taglibs. A solution could be adding the domain or package name in some way, e.g. apache.jakarta.taglibs apache-jakarta-taglibs apache/jakarta/taglibs Like Brett said, we just don't have the transition to those naming conventions stablized yet (sigh) is a very painfull transition that is being held off because it will impact so many projects when it happens. So his argument that we should just use taglibs for now is valid in that it may all change in the near future when we attempt this transition. I'll retract my statement that they should be separate project directories (taglibs-standard, taglibs-jndi, etc) because if we are consolidating commons into one directory structure as a goal then other projects should follow this theme. -Mark Anything after the domain name would be responsability of the domain owner. Regards Carlos Sanchez A Coruña, Spain Oness Project http://oness.sourceforge.net -Original Message- From: Felipe Leme [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 03, 2004 1:19 PM To: Maven Developers List Subject: Re: [VOTE] Options for the Jakarta Taglibs Maven repository Oops, forgot my votes: 1.Multiple directories x one directory: [X ] +1 Create one directory for group (ex: taglibs-standard, taglibs-request). Advantages: easier to locate artifacts; consistent with the wayJakarta Commons is organized 3.Where to put jstl.jar [X] +1 On existing group jstl Advantage: no replication of existing directory; better separation between specification (JSTL) and implementation (Jakarta Standard Taglibs) For this one, I changed my mind after Carlos' messages... -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark R. Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Options for the Jakarta Taglibs Maven repository
Brett Porter wrote: 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. wouldn't it be: org/apache/jakarta/commons/collections/1.0.1/collections-1.0.1.jar as collections is the artifact id and org/apache/jakarta/commons is the group heirarchy? In which case it would be the following for taglibs after we've made such a transition: org/apache/jakarta/taglibs/1.0.1/standard-1.0.1.jar and until then, I think your right that it would be taglibs/jars/taglibs-standard-1.0.1.jar So if we were to define a list of goals to make the transition to a new repository structure, what would they look like? 1.) migrate commons from individual project directories to a single project directory (IE) commons-collections/jars/commons-collections-1.0.1.jar commons-beanutils/jars/commons-beanutils-1.0.1.jar -to- commons/jars/commons-collections-1.0.1.jar commons/jars/commons-beanutils-1.0.1.jar 2.) make sure all projects maintain this strategy. (IE) taglibs/jars/taglibs-standard-1.0.1.jar taglibs/jars/taglibs-jndi-1.0.1.jar 3.) convert everything one day in the future to: org/apache/jakarta/commons/collections/1.0.1/collections-1.0.1.jar org/apache/jakarta/commons/beanutils/1.0.1/beanutils-1.0.1.jar org/apache/jakarta/taglibs/standard/1.0.1/standard-1.0.1.jar org/apache/jakarta/taglibs/jndi/1.0.1/jndi-1.0.1.jar Is this the plan? -- Mark R. Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Options for the Jakarta Taglibs Maven repository
Just curious, but are you in control of the jakarta-taglibs builds? I
understand if you're pinging the maven-dev list for best practices (I
suppose, but the maven-user list would probably be better), but if
you're wanting us to actually make a change in the layout of the
jakarta-taglibs organization on ibiblio, you're talking to the wrong
people...the taglibs people are able to control that.
just FYI.
-j
On Tue, 2004-08-03 at 01:02, Felipe Leme wrote:
Hi all,
As we haven't reached a common sense on how to name the groups, I think
we should vote for it. The issues are:
1.Multiple directories x one directory:
[ ] +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)
[ ] +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
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')
[ ] +1 Use existing directory 'taglibs'
Advantage: no replication of existing directory
Disadvantage: name is too generic
[ ] +0 Doesn't matter for me
3.Where to put jstl.jar
[ ] +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).
Regards,
Felipe
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
