Re: [VOTE] Release commons-sandbox-parent 1
On 6/24/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Rahul Akolkar wrote: > On 6/23/07, Phil Steitz <[EMAIL PROTECTED]> wrote: >> On 6/23/07, Rahul Akolkar <[EMAIL PROTECTED]> wrote: >> > >> > >> > I haven't yet understood why we need to release anything from the >> > sandbox at all. Sure, reproducibility is a good thing, but I doubt the >> > builds are radically irreproducible without this release; and more >> > importantly, I believe if people are interested in the sandbox >> > components and their reproducibility, they should help get a release >> > out instead. >> > >> >> I think you have a good point there, Rahul, but I would see this as a >> commons release, not a commons-sandbox release and I personally see >> the benefit (consistent builds, easier to get a sandbox component to >> build when jumping in) as outweighing the negatives (increasing >> likelihood people depend on sandbox components, making the sandbox >> more "comfortable"), especially given that we are *not* releasing any >> sandbox jars. >> > > > I appreciate you taking the time to elaborate. I am not impressed by > any of these benefits (I'm not trying to be curt, I don't know how > else to put it). Moreover, I agree about the negatives. So what are the negatives here? I have not seen anyone put forward any arguments yet as to why releasing the sandbox parent pom would be bad. We are *not* talking about releasing sandbox components! Please, enlighten me. > I see this as being distilled, and worse -- recurring, busy work. Well, Carlos asked for a release of the pom. I imagine that he has a good reason for this. So I stepped up to do the release. If I don't mind doing the job - why should you care? the problem is that if you try to check out and build one of the sandbox components it won't work, you'd need to checkout the whole sandbox just for one of them just to get the parent. I think is not a big deal and will make the life of people trying the sandbox components easier -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sandbox] releasing parent sandbox pom
any chances of getting this done? btw I have deployed a snapshot of commons-csv as there was none already there yet http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/commons-csv/ On 4/25/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: then we'd need a release of the parent and then one of the sandbox parent On 4/25/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: > On 4/25/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > > the source plugin 2.0.3 was just released, can we go ahead? > > I've just updated the commons-parent pom for the 2.0.3 source plugin - > so OK by me. > > http://svn.apache.org/viewvc?view=rev&revision=532523 > > Niall > > > On 3/17/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > > On 3/17/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > > > > can the parent commons-sandbox be released so all sandbox components > > > > can be built by themselves? > > > > it just needs to have the parent version updated to 2 > > > > > > > > or even better if commons parent is also released to take advantage of > > > > latest changes before releasing sandbox parent. > > > > > > I was hoping the maven source plugin was going to get a release - so > > > that we could remove the antrun workaround for the source plugin bug - > > > then release a new commons parent. Unfortunately that seems to be > > > stalled on the maven list. > > > > > > Niall > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > I could give you my word as a Spaniard. > > No good. I've known too many Spaniards. > > -- The Princess Bride > > > > - > > 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] > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sandbox] releasing parent sandbox pom
i guess at least to override the repo and prevent releases being deployed On 4/25/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: On 4/26/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > then we'd need a release of the parent and then one of the sandbox parent Do we need a Sandbox pom any more? Can't sandbox components use commons-parent? Niall > On 4/25/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > On 4/25/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > > > the source plugin 2.0.3 was just released, can we go ahead? > > > > I've just updated the commons-parent pom for the 2.0.3 source plugin - > > so OK by me. > > > > http://svn.apache.org/viewvc?view=rev&revision=532523 > > > > Niall > > > > > On 3/17/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > > > On 3/17/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > > > > > can the parent commons-sandbox be released so all sandbox components > > > > > can be built by themselves? > > > > > it just needs to have the parent version updated to 2 > > > > > > > > > > or even better if commons parent is also released to take advantage of > > > > > latest changes before releasing sandbox parent. > > > > > > > > I was hoping the maven source plugin was going to get a release - so > > > > that we could remove the antrun workaround for the source plugin bug - > > > > then release a new commons parent. Unfortunately that seems to be > > > > stalled on the maven list. > > > > > > > > Niall > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > I could give you my word as a Spaniard. > > > No good. I've known too many Spaniards. > > > -- The Princess Bride > > > > > > - > > > 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] > > > > > > > -- > I could give you my word as a Spaniard. > No good. I've known too many Spaniards. > -- The Princess Bride > > - > 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sandbox] releasing parent sandbox pom
then we'd need a release of the parent and then one of the sandbox parent On 4/25/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: On 4/25/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > the source plugin 2.0.3 was just released, can we go ahead? I've just updated the commons-parent pom for the 2.0.3 source plugin - so OK by me. http://svn.apache.org/viewvc?view=rev&revision=532523 Niall > On 3/17/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > On 3/17/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > > > can the parent commons-sandbox be released so all sandbox components > > > can be built by themselves? > > > it just needs to have the parent version updated to 2 > > > > > > or even better if commons parent is also released to take advantage of > > > latest changes before releasing sandbox parent. > > > > I was hoping the maven source plugin was going to get a release - so > > that we could remove the antrun workaround for the source plugin bug - > > then release a new commons parent. Unfortunately that seems to be > > stalled on the maven list. > > > > Niall > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > I could give you my word as a Spaniard. > No good. I've known too many Spaniards. > -- The Princess Bride > > - > 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sandbox] releasing parent sandbox pom
the source plugin 2.0.3 was just released, can we go ahead? On 3/17/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: On 3/17/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > can the parent commons-sandbox be released so all sandbox components > can be built by themselves? > it just needs to have the parent version updated to 2 > > or even better if commons parent is also released to take advantage of > latest changes before releasing sandbox parent. I was hoping the maven source plugin was going to get a release - so that we could remove the antrun workaround for the source plugin bug - then release a new commons parent. Unfortunately that seems to be stalled on the maven list. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sandbox] releasing parent sandbox pom
can the parent commons-sandbox be released so all sandbox components can be built by themselves? it just needs to have the parent version updated to 2 or even better if commons parent is also released to take advantage of latest changes before releasing sandbox parent. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 groupIds
yep, but to be clear, if we had relocated that version it'd potentially break people using it as their binary would change. I wouldn't like you to think that I screwed you for any reason. FWIW i'm not fan of relocations anyway, they have potentially bad effects. If an artifact moves to other place the user needs to change it by himself if he wants to upgrade. Not any different if an project changes omain and you have to go to the new one to download it. On 2/14/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: Carlos Sanchez wrote on Wednesday, February 14, 2007 8:40 AM: > iirc you have very different jars in the two groupids, that's not > relocation, that would actually change the binaries for users This was for one single release only (because we did not realize, that the M1 and M2 repos are "completed" automatically with the missing artifacts), but not for all the old releases where I also adjusted the POMs with the relocation section. Nevermind it is history now, but the complete discussion shows, that the process is still not clear and that there's no optimal solution either. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 groupIds
On 2/14/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: Maven should give here better support. If it ever downloads a relocation POM it should keep the relocation information in a separate DB/storage and take it always into account when resolving aritfacts no matter which version. Scenario 1 would be completely the the enough then. I'm not saying it's perfect ;) but that's how it is now -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 groupIds
On 2/13/07, nicolas de loof <[EMAIL PROTECTED]> wrote: According to this, when relocation projectX for new release N+1 option 1 : making dependency to oldGroupId:N+1 will work, but making dependency to newGroupId:N+1 will introduce duplicate jars issues if other dependencies introduce transitive-dependency to oldGroupId:N iirc "making dependency to oldGroupId:N+1" won't work because maven internally transforms it to newGroupId:N+1, so no difference option 2 : relocating all POM will fail du to proxies caching / mirror / sync issues and others, so will get duplicate jars issues option 3 : same as 1 All options introduce duplicate jars issues. yes, so 3 would involve the user and when something breaks it won't be "magically" The only solution I can find should be to have some meta-data in the POM to refer the old groupId, so that maven nows that newGroupId:x is the same artifact as oldGroupId:x Already in jira, no progress yet http://jira.codehaus.org/browse/MNG-2316 2007/2/14, Jörg Schaible <[EMAIL PROTECTED]>: > > Hi Carlos, > > Carlos Sanchez wrote on Tuesday, February 13, 2007 7:29 PM: > > > you can change the old poms to relocate to a new location as long as > > the new location has the same old jars and poms (just groupId > > change). IIRC your case was different. > > > > So, I' see two options for relocation: > > > > 1) when new version is out with new groupId add relocation pom in old > > location just for that new version. > > + Users updating version in old location will get a warning + easy > > to do - users may end having old versions and new versions in the > > classpath, that they would have to solve with exclusions > > > > 2) relocate all versions to new groupId > > + all users will only notice the warnings when using old group > > + no classpath problems in builds from scratch > > - harder to implement, will need to write some code > > - people with commons artifacts cached (almost everybody) will > > experience same problems as in 1, possibly getting two versions in > > the classpath > > I don't know whether I should laugh or cry because you "offered" option 2 > at all. I took option 2 and adjusted all the old releases of XStream on the > Codehaus repo, but they do not get synced to the public repo, since the > space for the relocation POMs is already occupied by the old files. It was > you who said, nothing can be done about this. Why should the synchronization > of the Apache repo be different to the one of Codehaus? > > - Jörg > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 groupIds
iirc you have very different jars in the two groupids, that's not relocation, that would actually change the binaries for users On 2/13/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: Hi Carlos, Carlos Sanchez wrote on Tuesday, February 13, 2007 7:29 PM: > you can change the old poms to relocate to a new location as long as > the new location has the same old jars and poms (just groupId > change). IIRC your case was different. > > So, I' see two options for relocation: > > 1) when new version is out with new groupId add relocation pom in old > location just for that new version. > + Users updating version in old location will get a warning + easy > to do - users may end having old versions and new versions in the > classpath, that they would have to solve with exclusions > > 2) relocate all versions to new groupId > + all users will only notice the warnings when using old group > + no classpath problems in builds from scratch > - harder to implement, will need to write some code > - people with commons artifacts cached (almost everybody) will > experience same problems as in 1, possibly getting two versions in > the classpath I don't know whether I should laugh or cry because you "offered" option 2 at all. I took option 2 and adjusted all the old releases of XStream on the Codehaus repo, but they do not get synced to the public repo, since the space for the relocation POMs is already occupied by the old files. It was you who said, nothing can be done about this. Why should the synchronization of the Apache repo be different to the one of Codehaus? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 groupIds
right a relocate pom for ALL versions is required to avoid duplication on classpath BUT as I said almost everybody will have cached previous versions of commons so they won't see the relocation until they delete local repo and the poms with relocation info get downloaded. On 2/13/07, nicolas de loof <[EMAIL PROTECTED]> wrote: What in such a scenario : My project depends commons-xxx-1.2, relocated at org.apache.commons.xxx-1.2 My pom get transitive commons-xxx-1.1 If I DON't update my POM maven2 will find the relocated artifact and exclude 1.1 - that's fine If 1.1 has no relocated POM, and if I update my POM, maven2 will get both 1.1 and 1.2 as they will not be detected as same artifact This mean a relocated POM for all oldest release is required to avoid duplicated jars in classpath. (am I wrong ?) 2007/2/13, Carlos Sanchez <[EMAIL PROTECTED]>: > > scenario 3 is with no relocation pom at all, so users get involved by > having to explicitly change the groupId > > On 2/13/07, nicolas de loof <[EMAIL PROTECTED]> wrote: > > I don't understand the distinction you make between scenario 1 and 3 : > > > > if new release use a relocation pom under commons-xxx and DOESN'T deploy > a > > jar under this group > > - maven2 users will get relocated artifact + a warning to update > > dependencies > > - maven1 users will not get the new version, may ask for it or only > found > > the POM and will update dependencies > > > > am I wrong ? > > > > Nico. > > > > > > > > 2007/2/13, Carlos Sanchez <[EMAIL PROTECTED]>: > > > > > > oh there's a 3rd option that I even like more > > > > > > 3) make new releases in new groupid, no relocations at all > > > + easiest ;) > > > + users trying to upgrade will need to know that the groupId has > > > changed and act by themselves, so they will be involved, and in case > > > of classpath problems they will know what has changed > > > - it'd be better to wait until a major/minor release so users can get > > > bugfixes easily > > > > > > > > > On 2/13/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > > > > you can change the old poms to relocate to a new location as long as > > > > the new location has the same old jars and poms (just groupId > change). > > > > IIRC your case was different. > > > > > > > > So, I' see two options for relocation: > > > > > > > > 1) when new version is out with new groupId add relocation pom in > old > > > > location just for that new version. > > > > + Users updating version in old location will get a warning > > > > + easy to do > > > > - users may end having old versions and new versions in the > > > > classpath, that they would have to solve with exclusions > > > > > > > > 2) relocate all versions to new groupId > > > > + all users will only notice the warnings when using old group > > > > + no classpath problems in builds from scratch > > > > - harder to implement, will need to write some code > > > > - people with commons artifacts cached (almost everybody) will > > > > experience same problems as in 1, possibly getting two versions in > the > > > > classpath > > > > > > > > I'd stick with 1) changing old releases scares me ;) and still > doesn't > > > > guarantee trouble free upgrades > > > > > > > > > > > > > > > > On 2/13/07, Jörg Schaible <[EMAIL PROTECTED]> > wrote: > > > > > you cannot change the old POMs anymore, in that case this > description > > > is obsolete. The only valid option is to use the new groupId with a > new > > > release and provide for this new release a relocation POM at the > former > > > location. This was Carlos' advice after a two week hassle to do such a > > > transition with XStream. > > > > > > > > > > - Jörg > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > -- > > > > I could give you my word as a Spaniard. > > > > No good. I've known too many Spaniards. > > > > -- Th
Re: m2 groupIds
scenario 3 is with no relocation pom at all, so users get involved by having to explicitly change the groupId On 2/13/07, nicolas de loof <[EMAIL PROTECTED]> wrote: I don't understand the distinction you make between scenario 1 and 3 : if new release use a relocation pom under commons-xxx and DOESN'T deploy a jar under this group - maven2 users will get relocated artifact + a warning to update dependencies - maven1 users will not get the new version, may ask for it or only found the POM and will update dependencies am I wrong ? Nico. 2007/2/13, Carlos Sanchez <[EMAIL PROTECTED]>: > > oh there's a 3rd option that I even like more > > 3) make new releases in new groupid, no relocations at all > + easiest ;) > + users trying to upgrade will need to know that the groupId has > changed and act by themselves, so they will be involved, and in case > of classpath problems they will know what has changed > - it'd be better to wait until a major/minor release so users can get > bugfixes easily > > > On 2/13/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > > you can change the old poms to relocate to a new location as long as > > the new location has the same old jars and poms (just groupId change). > > IIRC your case was different. > > > > So, I' see two options for relocation: > > > > 1) when new version is out with new groupId add relocation pom in old > > location just for that new version. > > + Users updating version in old location will get a warning > > + easy to do > > - users may end having old versions and new versions in the > > classpath, that they would have to solve with exclusions > > > > 2) relocate all versions to new groupId > > + all users will only notice the warnings when using old group > > + no classpath problems in builds from scratch > > - harder to implement, will need to write some code > > - people with commons artifacts cached (almost everybody) will > > experience same problems as in 1, possibly getting two versions in the > > classpath > > > > I'd stick with 1) changing old releases scares me ;) and still doesn't > > guarantee trouble free upgrades > > > > > > > > On 2/13/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: > > > you cannot change the old POMs anymore, in that case this description > is obsolete. The only valid option is to use the new groupId with a new > release and provide for this new release a relocation POM at the former > location. This was Carlos' advice after a two week hassle to do such a > transition with XStream. > > > > > > - Jörg > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > I could give you my word as a Spaniard. > > No good. I've known too many Spaniards. > > -- The Princess Bride > > > > > -- > I could give you my word as a Spaniard. > No good. I've known too many Spaniards. > -- The Princess Bride > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 groupIds
oh there's a 3rd option that I even like more 3) make new releases in new groupid, no relocations at all + easiest ;) + users trying to upgrade will need to know that the groupId has changed and act by themselves, so they will be involved, and in case of classpath problems they will know what has changed - it'd be better to wait until a major/minor release so users can get bugfixes easily On 2/13/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: you can change the old poms to relocate to a new location as long as the new location has the same old jars and poms (just groupId change). IIRC your case was different. So, I' see two options for relocation: 1) when new version is out with new groupId add relocation pom in old location just for that new version. + Users updating version in old location will get a warning + easy to do - users may end having old versions and new versions in the classpath, that they would have to solve with exclusions 2) relocate all versions to new groupId + all users will only notice the warnings when using old group + no classpath problems in builds from scratch - harder to implement, will need to write some code - people with commons artifacts cached (almost everybody) will experience same problems as in 1, possibly getting two versions in the classpath I'd stick with 1) changing old releases scares me ;) and still doesn't guarantee trouble free upgrades On 2/13/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: > you cannot change the old POMs anymore, in that case this description is obsolete. The only valid option is to use the new groupId with a new release and provide for this new release a relocation POM at the former location. This was Carlos' advice after a two week hassle to do such a transition with XStream. > > - Jörg > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 groupIds
you can change the old poms to relocate to a new location as long as the new location has the same old jars and poms (just groupId change). IIRC your case was different. So, I' see two options for relocation: 1) when new version is out with new groupId add relocation pom in old location just for that new version. + Users updating version in old location will get a warning + easy to do - users may end having old versions and new versions in the classpath, that they would have to solve with exclusions 2) relocate all versions to new groupId + all users will only notice the warnings when using old group + no classpath problems in builds from scratch - harder to implement, will need to write some code - people with commons artifacts cached (almost everybody) will experience same problems as in 1, possibly getting two versions in the classpath I'd stick with 1) changing old releases scares me ;) and still doesn't guarantee trouble free upgrades On 2/13/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: you cannot change the old POMs anymore, in that case this description is obsolete. The only valid option is to use the new groupId with a new release and provide for this new release a relocation POM at the former location. This was Carlos' advice after a two week hassle to do such a transition with XStream. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] pom for commons-logging-api and building/testing JCL with Maven 1
If it's this one http://svn.apache.org/viewvc/jakarta/commons/proper/logging/trunk/commons-logging-api.pom?view=markup I'd remove optional from both dependencies, it's not needed being scope test or plugins. So it has no dependencies at all, isn't it? On 8/10/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Hi all I've checked in a pom for commons-logging-api that is meant to be deployed to the Maven repository. Before I deploy it I would like for it to be reviewed. The reason for this file can be found in the archives [1]. Sorry it took so long, but I set the goal a little higher than just removing the dependencies. My aim was to get the thing to actually build and test commons-logging-api. After several different tries at this, I found that there was a bug in maven-test-plugin that prevents it. I have fixed the bug maven-test-plugin, but it has not been released yet. So for now we will have to make do with just a stripped down project.xml. I will revisit this when a new version of the maven-test-plugin has been released. [1] http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200607.mbox/[EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][discovery] m1-ibiblio-rsync-repository
That commons-discovery-0.2-dev.jar looks like a snapshot to me On 7/31/06, Henri Yandell <[EMAIL PROTECTED]> wrote: On 7/31/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > (moved from user list) > > On 7/31/06, Gilles Tabary <[EMAIL PROTECTED]> wrote: > > Hello. > > I am building an ear with Maven2. I need commons-discovery-0.2-dev.jar > > > There is a > > http://people.apache.org/repo/m1-ibiblio-rsync-repository/commons-discovery/jars/commons-discovery-0.2-dev.jar > > but I am not sure at all that is the reference thingy to be used. > > > > > Quick true or false question: > > Regardless of what has been done before, the > m1-ibiblio-rsync-repository should not contain snapshots. True. I've a script that looks for such things, but haven't gotten around to hooking it up to notifying people of problems. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] split of vfs
I prefer several jars On 7/27/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: Hi! > Then why not split that further and have > commons-vfs-bz2.jar etc... Yes, this is something Vincent Massol also told me to do. The reasons I wanted to go down to two jars are: *) each jar will have its own release cycle, means, we have to vote for each artifact, no? I think the number of mails in commons-dev is already high enough ;-) You can release all of them together calling only for a vote, release them separately is an optional (but useful) feature VFS 1.0 can be a composition of several vfs-*-1.0 jars, with just one tag *) I have the feeling that maintaining it is way too much work for me now, say, building all these releases, checking them and so on. Once VFS again has a significant number of developers (or its own release manager) such a structure might be manageable. I know that it will be the nicer structure, but should a commons project have such a complicated structure, I guess no. Maybe it might work better if VFS is a TLP (or at least out of commons) with its own mailing list and so on, though, not sure if/when this will happen. The lack of developers is definitely a NoNo for this. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] split of vfs
On 7/27/06, Jörg Schaible <[EMAIL PROTECTED]> wrote: Arnaud HERITIER wrote on Thursday, July 27, 2006 3:57 PM: > In M1 there's no transitive dependencies, thus your users will have to > define each dependency one by one. > But to improve the conversion between m1 and m2 poms for the > repository, if you deploy VFS with m1 you can add the following > setting : > http://maven.apache.org/maven-1.x/using/bestpractices.html#Get > ting_ready_for_Maven_2 Arnaud Wasn't there also a way to define "optional", so that the POM 2.0 converter will automatically set them? true - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [attributes] Planning a release
On 7/10/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Henri Yandell wrote: > On 7/9/06, Leo Sutic <[EMAIL PROTECTED]> wrote: >> >> Getting 2.2 out would be a nice endcap, and if you could just get the >> thing out in accordance with specs, that would be absolutely >> fantastic. I'll stick around to get 2.2 out if $SOMEONE_ELSE (you) do >> the release manager stuff. > > Which build system is the most used with attributes, Ant or Maven? > > Are we releasing the Plugin as well as the two jars? Currently the build is > > maven install-snapshot > maven install-plugin > > because the plugin depends on the snapshot 2.2 versions. Should the > plugin update to 2.2 dependencies? I've been going over the site documentation. This has been done so far: - Removed the dependency on commons-build - Synced the look and feel with the other components - Added project info and project reports Left to do: - Decide whether or not to change the groupId. Things needs to be committed either way. I'll do it once we have decided how. See also http://issues.apache.org/jira/browse/ATTRIBUTES-7 - Update all version references from 2.1 to 2.2. I'm working on that. - All download references to the plugin go to http://cvs.apache.org/~leosutic/... Can't we publish the plugin along with the other jars? Plugin must be in http://www.apache.org/dist/java-repository/groupId/plugins/ Currently http://www.apache.org/dist/java-repository/commons-attributes/plugins/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [attributes] Planning a release
I'm sorry I only used to build Spring in Maven2 some months ago. I didn't even see the annotations ;) On 7/10/06, Martin van den Bemt <[EMAIL PROTECTED]> wrote: Meant you may be interested in maintaining commons-attributes, because of the maven2 plugin :) (assuming you are actually using commons-attributes).. Mvgr, Martin Carlos Sanchez wrote: > mmm, were you talking about getting commons-attributes maven 1 plugin > released? the truth is that I never used it > > On 7/10/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > >> It's as easy as adding >> >> >> org.codehaus.mojo >> commons-attributes-maven-plugin >> 1.0 >> >> >> >> >> >> **/metadata/*.java >> >> >> >> compile >> >> >> >> >> >> >> On 7/10/06, Martin van den Bemt <[EMAIL PROTECTED]> wrote: >> > FYI maven 2 also has a commons-attributes plugin, written by >> (presumable) Carlos Sanchez (at least >> > from the website). >> > http://mojo.codehaus.org/commons-attributes-maven-plugin/ >> > >> > Maybe Carlos is interested to get involved ? >> > (cc-ed him) >> > >> > Mvgr, >> > Martin >> > >> > Henri Yandell wrote: >> > > On 7/9/06, Leo Sutic <[EMAIL PROTECTED]> wrote: >> > > >> > >> >> > >> Getting 2.2 out would be a nice endcap, and if you could just get >> the >> > >> thing out in accordance with specs, that would be absolutely >> > >> fantastic. I'll stick around to get 2.2 out if $SOMEONE_ELSE >> (you) do >> > >> the release manager stuff. >> > > >> > > >> > > Which build system is the most used with attributes, Ant or Maven? >> > > >> > > Are we releasing the Plugin as well as the two jars? Currently the >> build is >> > > >> > > maven install-snapshot >> > > maven install-plugin >> > > >> > > because the plugin depends on the snapshot 2.2 versions. Should the >> > > plugin update to 2.2 dependencies? >> > > >> > > The ant dist creates the 3 zips. Do you then zip that up as the >> > > release, and zip up a source tree as the source release? >> > > >> > > Hen >> > > >> > > - >> > > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > > For additional commands, e-mail: [EMAIL PROTECTED] >> > > >> > > >> > > >> > >> >> >> -- >> I could give you my word as a Spaniard. >> No good. I've known too many Spaniards. >> -- The Princess Bride >> > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [attributes] Planning a release
mmm, were you talking about getting commons-attributes maven 1 plugin released? the truth is that I never used it On 7/10/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote: It's as easy as adding org.codehaus.mojo commons-attributes-maven-plugin 1.0 **/metadata/*.java compile On 7/10/06, Martin van den Bemt <[EMAIL PROTECTED]> wrote: > FYI maven 2 also has a commons-attributes plugin, written by (presumable) Carlos Sanchez (at least > from the website). > http://mojo.codehaus.org/commons-attributes-maven-plugin/ > > Maybe Carlos is interested to get involved ? > (cc-ed him) > > Mvgr, > Martin > > Henri Yandell wrote: > > On 7/9/06, Leo Sutic <[EMAIL PROTECTED]> wrote: > > > >> > >> Getting 2.2 out would be a nice endcap, and if you could just get the > >> thing out in accordance with specs, that would be absolutely > >> fantastic. I'll stick around to get 2.2 out if $SOMEONE_ELSE (you) do > >> the release manager stuff. > > > > > > Which build system is the most used with attributes, Ant or Maven? > > > > Are we releasing the Plugin as well as the two jars? Currently the build is > > > > maven install-snapshot > > maven install-plugin > > > > because the plugin depends on the snapshot 2.2 versions. Should the > > plugin update to 2.2 dependencies? > > > > The ant dist creates the 3 zips. Do you then zip that up as the > > release, and zip up a source tree as the source release? > > > > Hen > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [attributes] Planning a release
It's as easy as adding org.codehaus.mojo commons-attributes-maven-plugin 1.0 **/metadata/*.java compile On 7/10/06, Martin van den Bemt <[EMAIL PROTECTED]> wrote: FYI maven 2 also has a commons-attributes plugin, written by (presumable) Carlos Sanchez (at least from the website). http://mojo.codehaus.org/commons-attributes-maven-plugin/ Maybe Carlos is interested to get involved ? (cc-ed him) Mvgr, Martin Henri Yandell wrote: > On 7/9/06, Leo Sutic <[EMAIL PROTECTED]> wrote: > >> >> Getting 2.2 out would be a nice endcap, and if you could just get the >> thing out in accordance with specs, that would be absolutely >> fantastic. I'll stick around to get 2.2 out if $SOMEONE_ELSE (you) do >> the release manager stuff. > > > Which build system is the most used with attributes, Ant or Maven? > > Are we releasing the Plugin as well as the two jars? Currently the build is > > maven install-snapshot > maven install-plugin > > because the plugin depends on the snapshot 2.2 versions. Should the > plugin update to 2.2 dependencies? > > The ant dist creates the 3 zips. Do you then zip that up as the > release, and zip up a source tree as the source release? > > Hen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
commons-chain project.xml improvement
Can anyone please add the properties section of the following dependencies to commons-chain project.xml? javax.servlet servlet-api 2.3 provided junit junit 3.8.1 test Thanks -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Are you thinking about doing it in the m1 or m2 repo?
see below
On 6/7/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
So, in the simple example below, covering commons-lang, the procedure
would be:
1. Copy all files from /commons-lang/ to
/org/apache/commons/commons-lang/ in the *Apache* repo
2. Change the groupId of all the pom files under
/org/apache/commons/commons-lang/ so that they use the
org.apache.commons groupId
3. Add relocation elements to all pom files in /commons-lang/ pointing
them to org.apache.commons like this:
org.apache.commons
If I understand the model documentation correctly, we shouldn't have to
use artifactId or version since they are the same. But should we add a
?
I never did.
4. Wait for a sync between the Apache repo and ibiblio, or is this
something that we need to ping someone about?
m1 repo - wait
m2 repo - ping
Is that correct so far?
When we later decide to release our first artifact using the new
groupId, should we also copy it to the repo using the groupId? My gut
feeling says no, but it's best to ask.
no
If I want to try this out locally first, can I test it in my local repo
${user.home}/.m2/repository/... or do I need to use a local httpd
serving as a central repo?
local is ok
--
Dennis Lundberg
Carlos Sanchez wrote:
> You are right. This would involve copying all the old group sutff to
> the new group and add the relocation poms.
>
> On 6/7/06, Nicolas De Loof <[EMAIL PROTECTED]> wrote:
>>
>> AFAIK there is a way in maven repo to "relocate" dependencies, so that a
>> POM for any commons can be published at commons-xxx groupId, that
>> "relocates" to org.apache.commons" groupId.
>>
>> Servletapi for example is now under "javax.servlet"
>> http://www.ibiblio.org/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom
>>
>>
>> Using this, when maven2 search for the "latest" release of any commons
>> it will look at the relocated one.
>>
>> Torsten Curdt a écrit :
>> > Brett,
>> >
>> > any comments on this?
>> >
>> > cheers
>> > --
>> > Torsten
>> >
>> > On 6/6/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
>> >> Brett, I did the test that you suggested.
>> >>
>> >> 1. Installed commons-lang 1.0.1 into my local repo with
>> >> groupId=org.apache.commons
>> >>
>> >> mvn install:install-file -DgroupId=org.apache.commons
>> >> -DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar
>> >> -Dfile=/path/to/commons-lang-1.0.1.jar
>> >>
>> >> 2. Created Maven 2 projects a, b and c with the dependencies mentioned
>> >> below.
>> >>
>> >> 3. Installed projects a and b into my local repo
>> >> mvn install
>> >>
>> >> 4. packaged project c as a war
>> >> mvn package
>> >>
>> >> The resulting war file includes both commons-lang-1.0.1.jar and
>> >> commons-lang-2.1.jar which was what you thought would happen.
>> >>
>> >> So this is bad, I guess. Anyone who uses commons components
>> transitively
>> >> in a Maven 2 environment are likely to be bitten by this. They must
>> keep
>> >> the same groupId for all commons-lang dependencies, as an example, in
>> >> the entire chain of transitive dependencies. I.e. they can't mix
>> >> groupId=commons-lang and groupId=org.apache.commons. This can be a
>> PITA
>> >> since some of the dependencies are most likely out of the projects own
>> >> control.
>> >>
>> >> What do you suggest we do? Should we wait with this relocation until a
>> >> version of Maven 2 is released that can handle these kind of
>> >> dependencies?
>> >>
>> >> --
>> >> Dennis Lundberg
>> >>
>> >> Brett Porter wrote:
>> >> > an extensive test should be something along the lines of:
>> >> >
>> >> > project A depends on commons-lang:commons-lang 2.1
>> >> > project B depends on o.a.c:commons-lang 1.0
>> >> > project C is a webapp that depends on A and B
>> >> >
>> >> > webapp should have only one commons-lang.
>> >> >
>> >> > You could do this with your own repository (and something completely
>> >> > artificial instead of commons-lang if it makes it easier).
>> >> >
>> >> > - Brett
>> >> >
>> >> > Dennis Lundberg wrote:
>> &g
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
You are right. This would involve copying all the old group sutff to the new group and add the relocation poms. On 6/7/06, Nicolas De Loof <[EMAIL PROTECTED]> wrote: AFAIK there is a way in maven repo to "relocate" dependencies, so that a POM for any commons can be published at commons-xxx groupId, that "relocates" to org.apache.commons" groupId. Servletapi for example is now under "javax.servlet" http://www.ibiblio.org/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom Using this, when maven2 search for the "latest" release of any commons it will look at the relocated one. Torsten Curdt a écrit : > Brett, > > any comments on this? > > cheers > -- > Torsten > > On 6/6/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote: >> Brett, I did the test that you suggested. >> >> 1. Installed commons-lang 1.0.1 into my local repo with >> groupId=org.apache.commons >> >> mvn install:install-file -DgroupId=org.apache.commons >> -DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar >> -Dfile=/path/to/commons-lang-1.0.1.jar >> >> 2. Created Maven 2 projects a, b and c with the dependencies mentioned >> below. >> >> 3. Installed projects a and b into my local repo >> mvn install >> >> 4. packaged project c as a war >> mvn package >> >> The resulting war file includes both commons-lang-1.0.1.jar and >> commons-lang-2.1.jar which was what you thought would happen. >> >> So this is bad, I guess. Anyone who uses commons components transitively >> in a Maven 2 environment are likely to be bitten by this. They must keep >> the same groupId for all commons-lang dependencies, as an example, in >> the entire chain of transitive dependencies. I.e. they can't mix >> groupId=commons-lang and groupId=org.apache.commons. This can be a PITA >> since some of the dependencies are most likely out of the projects own >> control. >> >> What do you suggest we do? Should we wait with this relocation until a >> version of Maven 2 is released that can handle these kind of >> dependencies? >> >> -- >> Dennis Lundberg >> >> Brett Porter wrote: >> > an extensive test should be something along the lines of: >> > >> > project A depends on commons-lang:commons-lang 2.1 >> > project B depends on o.a.c:commons-lang 1.0 >> > project C is a webapp that depends on A and B >> > >> > webapp should have only one commons-lang. >> > >> > You could do this with your own repository (and something completely >> > artificial instead of commons-lang if it makes it easier). >> > >> > - Brett >> > >> > Dennis Lundberg wrote: >> >> Hi Brett >> >> >> >> Sorry, I misunderstood you regarding when to do the testing. So, no I >> >> haven't done the test, yet. Can you elaborate a bit more on what >> needs >> >> to be tested? Perhaps you know of an artifact that has been relocated >> >> that we can have a look at, to see how they have done. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Sources and javadocs are great for maven users because when maven generates the IDE projects it will check the repo for them, download and link inside the IDE, enabling debugging through third party sources or reading the javadocs while coding. On 5/18/06, Phil Steitz <[EMAIL PROTECTED]> wrote: On 5/18/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > On 5/18/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > > Henri Yandell wrote: > > > On 5/13/06, robert burrell donkin <[EMAIL PROTECTED]> > > > wrote: > > >> On Thu, 2006-04-06 at 08:51 +0200, Nicolas De Loof wrote: > > >> > I agree about NOT making non-final jars available on ibiblio > > >> (httpclient > > >> > beeing an exception) > > >> > So could the next RC be uploaded to > > >> > http://cvs.apache.org/maven-snapshot-repository/ ? > > >> > > > >> > Please also consider using the new groupId recommandation for apache > > >> > commons-X : org.apache.commons.X > > >> > > >> should we make this change for the whole of the commons? > > > > > > Opening this up again. > > > > > > groupId: org.apache.commons > > > or > > > groupId: org.apache.commons.X > > > > > > ?? > > > > As one of the goals in the commons charter (12) is to have one jar (=one > > artifact) per subproject, I believe that org.apache.commons will work > > nicely. > > > > > The M2 repository has a better hierarchical structure, so I'm not sure > > > we have to worry about jamming X in place. > > > > > > Here's the m2 repo for my commons-alike testing project: > > > > > > http://www.ibiblio.org/maven2/genjava/ > > > > > > I'm thinking a group id of org.apache.commons for each component would > > > work well. > > > > > > We've got both logging and collections in need of deployment. Also > > > need to start putting the javadoc and sources in there too if > > > possible. > > > > What would be the best way to do this? Should we try to cram this into > > the Apache Maven 1 repo or should we start to provide Maven 2 POMs for > > all commons components instead? The Maven 2 repo has better support for > > these kinds of extras. > > Maven 1 repo; until we start doing it automatically from an m2 build > system. Less chance of us messing up the m2 repo that way. > > I'm working on deploying a lot of the javadoc.jars for commons > versions; then will do sources. Out of curiousity, why exactly do we want to duplicate the distribution of these things? What exactly does it buy us or our users? What is so hard / onerous about just downloading the official distros? I understand (and depend on) the practical value of the maven repo for binary jars, but don't see the compelling reason to duplicate src and javadoc distros. Until we have good automated signing and distribution from tags in place, I think we should avoid unnecessary duplication and as much as possible hold onto the connection tag <-> vote <-> distro <-> sig Breaking things apart and redistributing manually is asking for trouble, IMHO. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Maven 2 POM(s) for commons-logging [Was: RE : [ANNOUNCEMENT] Apache Jakarta Commons Logging 1.1 Released]
I'm gonna tweak the poms in the repository outside of apache, please add the optional property in the optional dependencies for future versions. I'll take a look to the other jars to make poms. On 5/15/06, robert burrell donkin <[EMAIL PROTECTED]> wrote: On Mon, 2006-05-15 at 20:51 +0200, Dennis Lundberg wrote: > Olivier Lamy wrote: > > Hi,n > > Thanks it's great job which fixes some troubles. > > But I have a trouble concerning the pom published [1]. > > I have recorded an MEV issue [2] > > A commons-logging developper's can put a comment or approve it ? > > > > Thanks, > > - Olivier > > > > [1] > > http://www.ibiblio.org/maven2/commons-logging/commons-logging/1.1/commons-logging-1.1.pom > > [2] http://jira.codehaus.org/browse/MEV-392 > > > > I have written a comment in the JIRA issue about why the situation is > the way it is. looks good :-) > The question is how we should proceed? Should we try to > tweak the POM that is currently deployed [1] i didn't deploy that POM and don't have karma: we'd need to talk the to maven team. it's too late for me to change the release POM deployed to the Apache repository: it's cut. the easiest approach would be for one of the maven team (who has karma) to apply appropriate modifications to the POM version in the maven 2 repository. > or should we try to create a POM for commons-logging-api or perhaps both? not sure the API works best as a virtual dependency. it can be satisfied by JCL 1.0.x, 1.1.x, by ceki's adapter or by Torsten's null implementation. not sure whether maven 2 handles this ATM. but the API jar contains more than is necessary for this purpose. probably carlos is right that all the dependencies need to be marked as optional but the full JCL jar shipped. not sure... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [openpgp] Building openpgp
only if they don't use a -SNAPSHOT version. if they do they will always deploy to cvs.apache.org On 5/3/06, Henri Yandell <[EMAIL PROTECTED]> wrote: There's a commented out block in there to stop sandbox projects being able to publish their code to the main apache repo. Would doing the below screw that up? Hen On 5/3/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > You can remove repositories element from > jakarta/commons/trunks-sandbox/pom.xml and make it inherit from the > apache pom with > > > org.apache > apache > 1 > > > > > On 5/3/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > I get the following error (using a fresh install of Maven 2.0.4) when > > trying to build OpenPGP, or indeed trying to domvn -N install in > > the sandbox directory to put the parent pom into the local repository. > > > > Downloading: http://snapshots.maven.codehaus.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-SNAPSHOT/maven-site-plugin-2.0-SNAPSHOT.jar > > [WARNING] Unable to get resource from repository snapshots > > (http://snapshots.maven.codehaus.org/maven2) > > [INFO] Skipping missing optional mojo: > > org.apache.maven.plugins:maven-site-plugin:attach-descriptor > > Downloading: http://snapshots.maven.codehaus.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-SNAPSHOT/maven-site-plugin-2.0-SNAPSHOT.jar > > [WARNING] Unable to get resource from repository snapshots > > (http://snapshots.maven.codehaus.org/maven2) > > [INFO] > > [ERROR] BUILD FAILURE > > [INFO] > > [INFO] A required plugin was not found: Plugin could not be found - > > check that the goal name is correct: Unable to download the artifact > > from any repository > > > > Try downloading the file manually from the project website. > > > > Then, install it using the command: > > mvn install:install-file -DgroupId=org.apache.maven.plugins > > -DartifactId=maven-site-plugin \ > > -Dversion=2.0-SNAPSHOT -Dpackaging=maven-plugin > > -Dfile=/path/to/file > > > > > > > > Any thoughts? > > > > Hen > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > I could give you my word as a Spaniard. > No good. I've known too many Spaniards. > -- The Princess Bride > > - > 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [openpgp] Building openpgp
You can remove repositories element from jakarta/commons/trunks-sandbox/pom.xml and make it inherit from the apache pom with org.apache apache 1 On 5/3/06, Henri Yandell <[EMAIL PROTECTED]> wrote: I get the following error (using a fresh install of Maven 2.0.4) when trying to build OpenPGP, or indeed trying to domvn -N install in the sandbox directory to put the parent pom into the local repository. Downloading: http://snapshots.maven.codehaus.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-SNAPSHOT/maven-site-plugin-2.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository snapshots (http://snapshots.maven.codehaus.org/maven2) [INFO] Skipping missing optional mojo: org.apache.maven.plugins:maven-site-plugin:attach-descriptor Downloading: http://snapshots.maven.codehaus.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-SNAPSHOT/maven-site-plugin-2.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository snapshots (http://snapshots.maven.codehaus.org/maven2) [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] A required plugin was not found: Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.plugins -DartifactId=maven-site-plugin \ -Dversion=2.0-SNAPSHOT -Dpackaging=maven-plugin -Dfile=/path/to/file Any thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] activation and javamail
I had put them in ibiblio, will be available soon On 5/2/06, Henri Yandell <[EMAIL PROTECTED]> wrote: Downloads okay, though a bit of noise from cookies. Meant increasing the version that commons-email depends upon (or at least is compiled against). Currently the unit tests are hanging though, on the EmailTest. Hen On 5/2/06, Torsten Curdt <[EMAIL PROTECTED]> wrote: > Hurray! > > http://weblogs.java.net/blog/kohsuke/archive/2006/05/javamail_and_ac.html > > Could someone add that to email, please? > > cheers > -- > Torsten > > - > 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] RC on ibiblio ?
On 4/5/06, robert burrell donkin <[EMAIL PROTECTED]> wrote: > sadly policy dictates that we can't upload release candidates to ibiblio AFAIK is PMC decision what gets uploaded - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] please use in POM
no, scope is different than optional true On 3/23/06, Jörg Schaible <[EMAIL PROTECTED]> wrote: > Henri Yandell wrote on Thursday, March 23, 2006 9:14 AM: > > > How do you do that in m1? > > > > > > optional > > > > Exactly! The project.xml of configuration already have some deps with scope > definitions for test. Similar can be done for "optional". > > - Jörg > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Maven2/RMIC?
This works for me. A known issue it's that it won't work under Mac as
the jdk tools doesn't exist, but I believe it's only needed when
iiop=true
org.apache.maven.plugins
maven-antrun-plugin
process-classes
Running rmic
run
com.sun
tools
system
1.4
${java.home}/../lib/tools.jar
On 3/13/06, James Carman <[EMAIL PROTECTED]> wrote:
> All,
>
> Has anyone got RMIC to work using Maven2? Jakarta Commons Proxy's test
> cases need to generate RMIC stubs, but I can't get it working. It keeps
> complaining about either JAVA_HOME or CLASSPATH issues. There are
> complaints out there on the forums about it, but I didn't really see a good
> work-around. Here's the relevant part of the pom.xml file:
>
>
>
> maven-antrun-plugin
>
>
> generate-rmic-stubs
> test-compile
>
>
>
>
>
>
>
>
>
>
> classpathref="rmic.classpath"/>
>
>
>
> run
>
>
>
>
>
>
> James
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [daemon] Deploying maven 2 pom for release 1.0.1
I think commons is required or the group would get too big. Also a groupId per PMC sounds the best approach. On 3/3/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > Another one: > > org.apache.jakarta > > no commons. > > With my different hats/mental viewpoints: > > * Foundation: We need to have an organizing, pmc based structure. > * Jakarta: We need a single top grouping for Jakarta > * Commons: We need a grouping for Commons > * Jakarta: I want to merge Commons and Jakarta, so can drop one > * Foundation: commons.apache.org means painful arguments, prefer jakarta. > > These multiple inputs are why I'm trying to get this resolved right > now, regardless of short-term pain. > > Hen > > On 3/3/06, Brett Porter <[EMAIL PROTECTED]> wrote: > > I'd say o.a.j.c, but really it doesn't matter. Pick one and use it > > consistently. > > > > If you use o.a.c, you will have to share with anything else "commons" at > > Apache. Same deal that has been traded off for the Java package before. > > It's really not a big deal. > > > > - Brett > > > > Dennis Lundberg wrote: > > > Henri Yandell wrote: > > >> On 2/27/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > > >>> Alex Karasulu wrote: > > Hiya, > > > > The directory project depends on commons-daemon 1.0.1 and we had to > > update the maven2 repo with a temporary pom.xml to allow our recent > > release to go through. I wanted to contact this list and make sure the > > deployed pom is correct. It is located here: > > > > http://test.maven.codehaus.org/maven2/commons-daemon/commons-daemon/1.0.1/ > > > > > > Also I'd like to make sure we can get m2 deployments working for > > commons > > daemon from now on. I'm a committer but I wanted to ask if it's ok to > > add a m2 pom alongside the m1 project.xml so we can update the m2 > > repository. > > >>> If we start to add m2 poms to SVN I do think we should use the Maven 2 > > >>> way to declare groupId, like this: > > >>> > > >>>org.apache.commons > > >>>commons-daemon > > >> > > >> I think it should be: org.apache.jakarta.commons > > >> > > >> It's not the package, just a grouping, so let's get it right at the > > >> ASF this time. > > > > > > This page [1] says to use the package, but I have taken this question > > > over to dev@maven.apache.org [2] to get this clarified. Will post the > > > result back here later. > > > > > > > > > > > > > > > [1]http://maven.apache.org/guides/mini/guide-naming-conventions.html > > > [2]http://www.nabble.com/What-M2-groupId-should-we-use-in-Jakarta-commons--t1220408.html > > > > > > > > > > - > > 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] > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] m2 groupId Was: [daemon] Deploying maven 2 pom for release 1.0.1
We don't force the package name as groupId, but the "expected" package name. eg. junit is in package junit but we'd put it in org.junit. After that is up to the organization (apache) to decide how org.apache is splitted. Now from the apache side ;) sounds like a groupId per PMC is a good idea, and if at its moment it was decided to go for org.apache.commons that's a good groupId. On 3/3/06, Phil Steitz <[EMAIL PROTECTED]> wrote: > On 3/3/06, Jörg Schaible <[EMAIL PROTECTED]> wrote: > > Now answering on the new thread with less spelling errors :) > > > > Henri Yandell wrote on Friday, March 03, 2006 6:40 AM: > > > > > Re-subjecting this - bit hidden under the old subject. > > > > > > On 3/2/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > >> On 2/27/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > > >>> > > >>> If we start to add m2 poms to SVN I do think we should use the > > >>> Maven 2 way to declare groupId, like this: > > >>> > > >>>org.apache.commons > > >>>commons-daemon > > >> > > >> I think it should be: org.apache.jakarta.commons > > >> > > >> It's not the package (afaik), just a grouping, so let's get it right > > >> at the ASF this time. > > > > > > Suggesting on repository@ that we lock things down so that PMCs have > > > group space into which only they can write etc etc - either through > > > SVN or unix groups. > > > > It is the recommended way to chose the package name as group id. If > > Jakartea wouldn't have an own mirror into the repo at ibiblio, your upload > > would been refused by the Maven team. And IMHO it is a good practice, > > because the user must not guess about an arbitrary chosen groupId by the > > developers of a package. > > > > +1 - I think Nicola Ken used to have a sig that said something like > "verba volant, scripta manent" (words fly, but what is written > remains). I see projects the same way - the package name is durable > and a property of the codebase, so should be (at least the root of) > its name in the repo. Jakarta is an org entity that may - sob, groan, > choke - go away some day. That's why it was wise IMHO not to insert > "jakarta" into the package names for o.a.c packages. The main point, > though, is that the package name identifies the code in the > conventional java namespace and I see no reason not to stick with > that. > > Phil > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [daemon] Deploying maven 2 pom for release 1.0.1
You can change that also in the m1 poms. If there're already releases we can relocate the to the new groupid, so people using the old one will get a warning althoug still working. On 2/27/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > Alex Karasulu wrote: > > Hiya, > > > > The directory project depends on commons-daemon 1.0.1 and we had to > > update the maven2 repo with a temporary pom.xml to allow our recent > > release to go through. I wanted to contact this list and make sure the > > deployed pom is correct. It is located here: > > > > http://test.maven.codehaus.org/maven2/commons-daemon/commons-daemon/1.0.1/ > > > > Also I'd like to make sure we can get m2 deployments working for commons > > daemon from now on. I'm a committer but I wanted to ask if it's ok to > > add a m2 pom alongside the m1 project.xml so we can update the m2 > > repository. > > If we start to add m2 poms to SVN I do think we should use the Maven 2 > way to declare groupId, like this: > >org.apache.commons >commons-daemon > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] jsch session is down problem in maven
Thanks Mario, I'm trying to promote commons-vfs inside maven in the future to prevent duplicate work and avoid issues like this.. http://jira.codehaus.org/browse/MNG-1047 On 11/27/05, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > HiCarlos, > > At maven project we have a problem with jsch, scp intermittently > > failing with session is down message > > http://jira.codehaus.org/browse/MNG-678 > > > No, I've never seen this problem and there were no reports like this. > > Could it be, that the time after creating the session and requesting a > channel is too long idle and thus the server ended it? > Just a wild guess ... > > --- > Mario > > > - > 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]
[vfs] jsch session is down problem in maven
Hi, At maven project we have a problem with jsch, scp intermittently failing with session is down message http://jira.codehaus.org/browse/MNG-678 Has anyone in vfs experimented this? is the scp vfs support working correctly? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[commons-logging] Remove commons-logging-1.1-dev.jar from apache repository
Hi, Please remove commons-logging-1.1-dev.jar from http://www.apache.org/dist/java-repository/commons-logging/jars/ That place is only for official apache releases. You can use http://cvs.apache.org/dist/ for nightly builds. This patch will help in the future http://issues.apache.org/bugzilla/show_bug.cgi?id=37314 Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [chain] dependencies
What maven2 tries to address with "optional" means that there's a very high chance for that jar not to be needed. Let's say you can use chain in a standalone (not servlet) environment, then servlet dependency is optional. This is a way to solve problems that usually would be easier solved having a chain-core, chain-jsf, chain-portlet, chain-servlet. (I'm just guesing up) I don't believe BeanUtils, Digester and Logging are optional at all. Of course if you use a class from the jar you won't need a lot of dependencies, but that's not the point of the optional tag in maven2. Regards On 11/15/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 11/15/05, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > > > I'm trying to sort out the dependencies for Chain-- right now the pom > > in the repository (for Maven 2) is bringing the Servlet and Portlet > > APIs plus a beta version of MyFaces into any project that depends on > > it. > > > > From the project home page, it looks like all three of these are optional. > > > At runtime, that's true unless you use the corresponding Context > implementation class. It's also true at compile time if you use the Ant > script (which has conditional compilation targets -- don't know whether you > can do that in Maven or not). > > Can someone please confirm (for a non-portlet developer) that Portlet > > works the same way as Servlet, that is, the container provides the API > > at runtime? > > > It *can* work that way. However, the portlet API is not a required part of > the J2EE (now Java EE) platform, so you cannot be guaranteed that it will be > in your average servlet container. For example, the portlet API jar is not > shipped with Tomcat by default. > > In addition, the docs say, "To maximize the usefulness of the Chain of > > Responsibility pattern APIs, the fundamental interface contracts are > > defined in a manner with zero dependencies other than an appropriate > > JDK." > > > > Does that mean that the BeanUtils, Digester and Logging dependencies > > are also optional? > > > If you take the intended meaning of "fundamental APIs" to mean the interface > definitions in org.apache.commons.chain (which was the intent of that > statement, since I wrote it :-) then yes, they are optional. However, > logging is required by most of the impl subpackage implementations. > Digester/BeanUtils are only required if you use the provided utility classes > to parse XML based configuration files. Nothing in Commons Chain actually > requires this ... you are perfectly free to create Catalog, Chain, and > Command instances manually and integrate them appropriately. > > Thanks, > > Wendy > > > Craig > > - > > 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: Maven build fixes affecting almost all projects
SNAPSHOT is a reserved word used by maven. When you deploy an artifact
whose version has the word SNAPSHOT it gets automatically deployed
also as a dated version, eg. 1.0-SNAPSHOT gets deployed as
1.0-20051115.203021.
About the javadoc dependency, the patch is wrong, shouldn't be
commented. In the other hand IMHO it shouldn't generate a new jar but
depend on the tools.jar, which btw is closer to the approach used in
m2. Anyway we'll have to fix this pom manually when used in the m2
repo.
On 11/8/05, Phil Steitz <[EMAIL PROTECTED]> wrote:
> On 11/8/05, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> > About adding SNAPSHOT the reason is the same as other people has
> > already given. I looked in the properties files and tried to guess the
> > right version which is currently in development, other people will
> > know better than me. The rule is if last version released was 1.0 it
> > should be 1.0.1-SNAPSHOT, unless explicitly working towards 1.1, which
> > would be 1.1-SNAPSHOT.
>
> Can someone explain why "-SNAPSHOT" is better than "-dev"?
> >
> > On 11/8/05, Dion Gillard <[EMAIL PROTECTED]> wrote:
> > > Questions:
> > >
> > > 1) The javadoc dependency in attributes/compiler/project.xml has been
> > > commented out. Why?
> >
> > The better way I can think about to fix this is adding tools.jar as a
> > dependency, and overriding it in the project.properties.
> > Something like
> > maven.jar.override=on
> > maven.jar.tools=${java.home}/../lib/tools.jar
>
> Did you look at the maven.xml? It seems to try to create and install
> this. It took me several attempts to get this to build (prior to
> change), but it did eventually.
> >
> > > 4) betwixt/project.xml has a change which places a directory element
> > > inside an includes element. According to the docs on
> > > http://maven.apache.org/maven-1.x/reference/project-descriptor.html#class_UnitTest
> > > this is not correct.
> >
> > I just moved up the includes, but yes the directory is not needed
> > there. It doesn't break under the xml schema though.
> >
> >
> > > 7) chain/apps/mailreader/project.xml changes do not fix the bad
> > > resource elements, they simply remove them.
> >
> > They are already under the right tag at the end of the pom
> >
>
> -
> 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: Maven build fixes affecting almost all projects
About adding SNAPSHOT the reason is the same as other people has
already given. I looked in the properties files and tried to guess the
right version which is currently in development, other people will
know better than me. The rule is if last version released was 1.0 it
should be 1.0.1-SNAPSHOT, unless explicitly working towards 1.1, which
would be 1.1-SNAPSHOT.
On 11/8/05, Dion Gillard <[EMAIL PROTECTED]> wrote:
> Questions:
>
> 1) The javadoc dependency in attributes/compiler/project.xml has been
> commented out. Why?
The better way I can think about to fix this is adding tools.jar as a
dependency, and overriding it in the project.properties.
Something like
maven.jar.override=on
maven.jar.tools=${java.home}/../lib/tools.jar
> 4) betwixt/project.xml has a change which places a directory element
> inside an includes element. According to the docs on
> http://maven.apache.org/maven-1.x/reference/project-descriptor.html#class_UnitTest
> this is not correct.
I just moved up the includes, but yes the directory is not needed
there. It doesn't break under the xml schema though.
> 7) chain/apps/mailreader/project.xml changes do not fix the bad
> resource elements, they simply remove them.
They are already under the right tag at the end of the pom
>
> On 11/6/05, Phil Steitz <[EMAIL PROTECTED]> wrote:
> > On 11/2/05, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> > > On Tue, 2005-11-01 at 11:16 +1100, Dion Gillard wrote:
> > > > Carlos, I think we the developers should work with you on this one.
> > >
> > > +1
> > >
> > > probably more effective that way
> > >
> > > but i'm comfortable about proposing commons karma for any existing
> > > apache committer who wants it.
> >
> >
> > I have taken a look at Carlos' patch and what it does is:
> >
> > 1) Change all current development version specs from -dev to -SNAPSHOT
> > 2) Introduces artifactId, groupId (in some cases, not everywhere?)
> > 3) Introduces scope tags for dependencies (in some cases)
> > 4) Eliminates some (unused?) resources elements from chain's build section
> > 5) Eliminates empty id, organization, email from contributors
> >
> > None of these look (to me) like they will affect builds or cause
> > problems. We should probably all agree that we want to follow the
> > "maven way" in 1); though and test all of the builds before
> > committing. I am willing to test all of the builds and then commit if
> > others are OK with this. If I hear no objections, I will do this in a
> > couple of days. In the mean time, it would be good for a [chain]
> > committer to look at the mods to there.
> >
> > Thanks, Carlos.
> >
> > Phil
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> http://www.multitask.com.au/people/dion/
> "You are going to let the fear of poverty govern your life and your
> reward will be that you will eat, but you will not live." - George
> Bernard Shaw
>
> -
> 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: Maven build fixes affecting almost all projects
http://issues.apache.org/bugzilla/show_bug.cgi?id=37314 On 10/31/05, Dion Gillard <[EMAIL PROTECTED]> wrote: > Post away... > > On 11/1/05, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > > It's 30KB. I haven't changed dependencies or anything related directly > > to the projects and their functionality, mainly syntax fixes, that's > > why I took the responsability of doing it at a time instead of one at > > a time. > > > > I can send the patch if you think is not too big for the mailing list. > > > > On 10/31/05, Dion Gillard <[EMAIL PROTECTED]> wrote: > > > Carlos, I think we the developers should work with you on this one. > > > > > > Post the patch as an attachment here so we can all look at it. How big is > > > it? > > > > > > On 11/1/05, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > > > > > I've been working on fixing the maven project.xml files so they work > > > > with maven 1.1 too and to improve the future releases and possible > > > > upgrade to maven 2. > > > > > > > > I don't have rights in the commons svn, so I'd like to know if you > > > > prefer a patch for everything as a bugzilla issue, separated patches > > > > (this would be a PITA), or just a mail attachment. > > > > > > > > These patches include: > > > > - fixing xml according to schema > > > > - use of "version-SNAPSHOT" instead of "version-dev" > > > > - adding some helper tags to improve the m1 pom conversion to m2. > > > > > > > > Regards > > > > > > > > Carlos Sanchez > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > http://www.multitask.com.au/people/dion/ > > > "You are going to let the fear of poverty govern your life and your > > > reward will be that you will eat, but you will not live." - George > > > Bernard Shaw > > > > > > - > > > 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] > > > > > > > -- > http://www.multitask.com.au/people/dion/ > "You are going to let the fear of poverty govern your life and your > reward will be that you will eat, but you will not live." - George > Bernard Shaw > > - > 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: Maven build fixes affecting almost all projects
It's 30KB. I haven't changed dependencies or anything related directly to the projects and their functionality, mainly syntax fixes, that's why I took the responsability of doing it at a time instead of one at a time. I can send the patch if you think is not too big for the mailing list. On 10/31/05, Dion Gillard <[EMAIL PROTECTED]> wrote: > Carlos, I think we the developers should work with you on this one. > > Post the patch as an attachment here so we can all look at it. How big is it? > > On 11/1/05, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I've been working on fixing the maven project.xml files so they work > > with maven 1.1 too and to improve the future releases and possible > > upgrade to maven 2. > > > > I don't have rights in the commons svn, so I'd like to know if you > > prefer a patch for everything as a bugzilla issue, separated patches > > (this would be a PITA), or just a mail attachment. > > > > These patches include: > > - fixing xml according to schema > > - use of "version-SNAPSHOT" instead of "version-dev" > > - adding some helper tags to improve the m1 pom conversion to m2. > > > > Regards > > > > Carlos Sanchez > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > http://www.multitask.com.au/people/dion/ > "You are going to let the fear of poverty govern your life and your > reward will be that you will eat, but you will not live." - George > Bernard Shaw > > - > 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]
Maven build fixes affecting almost all projects
Hi, I've been working on fixing the maven project.xml files so they work with maven 1.1 too and to improve the future releases and possible upgrade to maven 2. I don't have rights in the commons svn, so I'd like to know if you prefer a patch for everything as a bugzilla issue, separated patches (this would be a PITA), or just a mail attachment. These patches include: - fixing xml according to schema - use of "version-SNAPSHOT" instead of "version-dev" - adding some helper tags to improve the m1 pom conversion to m2. Regards Carlos Sanchez - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [chain] Please change version number in project.xml
The version should be 1.1-SNAPSHOT or 1.0.1-SNAPSHOT, not -dev. On 10/23/05, Wendy Smoak <[EMAIL PROTECTED]> wrote: > The Commons Chain project.xml file still specifies version 1.0. This means > that if you build it locally, Maven will overwrite the "official" > commons-chain-1.0.jar file in your local repository with one containing any > changes that have been made since the release. > > Please change the version number in project.xml, maybe 1.1-dev or 1.0.1-dev > would be appropriate. > > Thanks, > Wendy Smoak > > > > - > 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]
Releasing a new Commons BeanUtils 1.7.1
Hi, The commons beanutils 1.7.0 jar had a incorrect version in the manifest (1.6). As it seems that there won't be more releases soon, is it possible to make a 1.7.1 with just the manifest fixed? the number of people with an incorrect jar would be fewer as they would download the latest one. Issue: http://issues.apache.org/bugzilla/show_bug.cgi?id=31477 Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Jelly Builds
You're right, http://www.apache.org/dist/java-repository: official releases, mirrored http://cvs.apache.org/repository/: snapshots and other development artifacts not released, not mirrored Regards On 8/3/05, Dion Gillard <[EMAIL PROTECTED]> wrote: > Snapshots aren't supposed to go into the 'official' apache repostitory > http://www.apache.org/dist/java-repository but instead into > http://cvs.apache.org/repository/ , which I don't believe is mirrored > to ibiblio. > > Is this right? > > On 8/4/05, Paul Libbrecht <[EMAIL PROTECTED]> wrote: > > Releases are good but are scarce (as have seen in jelly!). Snapshots > > are supposed to reflect that approximation of a developer status... > > and, I think, therefore, Diogo wishes to get a snapshot for jelly in > > its current state. > > > > Is there a general policy how and when to do this? > > > > Is there a form of automatic mirrorring from Apache to maven's ibiblio > > repository ? > > > > paul > > > > > > Le 4 août 05, à 00:13, Dion Gillard a écrit : > > > > > Are the releases not good enough? > > > > > > On 8/4/05, Diogo Quintela (EF) <[EMAIL PROTECTED]> wrote: > > >> Hello list, > > >> I am reposting a question made a couple weeks ago without any > > >> answers given. > > >> I needed that at least a snapshot/date build of commons-jelly > > >> (core) > > >> and xml (tags) would get uploaded in ibiblio. I am working on > > >> xdoclet-plugins but I can't commit my changes before I have those jars > > >> available for download. I've read > > >> http://maven.apache.org/repository-upload.html and I feel they won't > > >> accept > > >> my request (for uploading my own made bundle...). > > >> Is there any jelly developer that could do that, or am I > > >> going the > > >> wrong way? > > >> > > >> Thanks > > >> Diogo Quintela > > >> > > >> --- > > >> Diogo Bacelar Quintela > > >> EF - Tecnologias de Informação, Lda. > > >> Av. António Serpa, 26 - 4º Dto. > > >> 1050-027 Lisboa, Portugal > > >> Tel: (+351) 217 827 800 > > >> Fax: (+351) 217 827 830 > > >> Email: [EMAIL PROTECTED] > > >> PGP: 0xF51A5AB9 > > >> > > >> > > >> - > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > > > > > > > > -- > > > http://www.multitask.com.au/people/dion/ > > > "You are going to let the fear of poverty govern your life and your > > > reward will be that you will eat, but you will not live." - George > > > Bernard Shaw > > > > > > - > > > 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] > > > > > > > -- > http://www.multitask.com.au/people/dion/ > "You are going to let the fear of poverty govern your life and your > reward will be that you will eat, but you will not live." - George > Bernard Shaw > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[validator] Side effect of allowing multiple forms on the same page
The last commit of the javascript code allows multiple forms on the same
page by generating a unique variable name based on form name, adding this
line
oMinLength = eval('new ' + form.name + '_minlength()');
But if any field of the form is called "name" javascript validation doesn't
work as form.name is an object, not a String
For example makes client side validation stop
working
I post this message so nobody spends its time asking themselves why
validation doesn't work anymore in some pages (as I have already done)
Affected files:
Jakarta-commons/validator/src/javascript/org/apache/commons/validator/javasc
ript/*.js
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
