Re: Discussion about Maven
Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: Grzegorz Kossakowski wrote: I wanted to know what are our rules. Do we: - want to have such a internal releases I'd avoid using word release for this as it has some legal implications and we would get chewed up for using it :) Ah, I'm young committer so forgive me that I omit legal implications and use inappropriate words. I'm really hard working to improve my English. :-) I agree it should not be called release. Many people use the term incorrectly. See http://apache.org/dev/#releases http://apache.org/dev/release.html#what Yes I think you can do such builds and place them on your private space at people.apache.org or on cocoon zones, and call it nightly or build or some such, but not a milestone *release*. And it is a good idea to do such builds as long as it helps to further development of Cocoon. +1 IMHO, for milestone *release*, I'd bundle all necessary unreleased dependencies and upload to www.apache.org/dist. I'm not sure if there are any legal gotchas with this approach, but it worked for us in the past, for 2.1 milestones. The only stuff that can go at w.a.o/dist/ is that which is intended to be released to the public beyond our dev group. Anything put there must be approved by this PMC. It will not work with Maven and it can't be called release I think. My personal opinion is that release (after changing wording) should be something that we can officially ship using our infrastructure. Part of our infrastructure is Maven now but in order to upload to its central server we can't have snapshot dependencies as pointed out earlier. The only solution I can think of is that we stay longer in nighly build mode and we can switch to milestone mode as soon as all of our dependencies are released ones. I think that it will work well only if we successfully push projects we depend on to follow release early, release often practice so we will not bed forced to stay in nighly build phase too long. I'm not so much experienced with Open Source to have a strong opinion on this. Do you think that we effectively push other project? The only effective way is to go and help those other projects: testing, feedback, etc. -David
Re: Discussion about Maven
Grzegorz Kossakowski wrote: I don't think it's harder with Maven. Maven was important factor when it comes to ability to have independent release cycles. We just need to clearly define terms (like release) we use I hope you are not suggesting to stop releasing milestones. and get used to the thought that we should tend to depend on released versions and talk more with other projects about releasing their goodies. Yes we should. Vadim
Re: Discussion about Maven
Ralph Goers pisze: I have always been unhappy that Cocoon releases contained non-released jars for a few reasons: 1. Often the jars were labeled something like xyz-20070525-dev.jar. It is impossible to download the source for this and know for sure that it matches what the jar was built from and whoever actually built the jar didn't put the source where someone could find it. BTW - this is much easier with subversion repositories as the builds can be tagged with the revision number. 2. Who is going to support this? Try asking a question about a problem. You should expect that when they ask for the version and you tell them you will either get nothing but silence or laughter. We make no guarantees about our repository and neither does anyone else. Unfortunately, some of the projects Cocoon has components built around only perform releases infrequently. Often we have encountered bugs that really need to be fixed. And finally, Cocoon uses so many other jars that a release would never be accomplished if we required formal versions of them all. However, with 2.2 I hope we can make sure that all the core Cocoon components only leverage jars from projects that are pretty stable and well maintained. I would suggest that if we are finding that some projects are not responsive then it might be time to look for alternatives to them or perhaps even drop the Cocoon block in question. Of course, I haven't actually looked to see which blocks would be impacted so even that may be impractical. +100 -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Discussion about Maven
Grzegorz Kossakowski wrote: On the other hand, milestones are just our internal releases and I think we can live with these gaps. No, they are not internal: http://cocoon.apache.org/2.1/changes.html http://archive.apache.org/dist/cocoon/SOURCES/ http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-core/2.2.0-M3/ Vadim
Re: Discussion about Maven
Vadim Gritsenko pisze: Grzegorz Kossakowski wrote: On the other hand, milestones are just our internal releases and I think we can live with these gaps. No, they are not internal: http://cocoon.apache.org/2.1/changes.html http://archive.apache.org/dist/cocoon/SOURCES/ http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-core/2.2.0-M3/ Examples you provided do not apply to the situation I want to discuss. In 2.1 times we were shipping all dependencies ourselves so there is no problem of dependency resolution. I was talking about the situation when we want to release some early alpha that has _snapshot_ dependencies that (obviously) are _not_ available at central server. If we want to make such a release it has to be internal because we cannot ship it or upload at central. I wanted to know what are our rules. Do we: - want to have such a internal releases OR - we really think that world is perfect and we'll always depend on released artifacts even in early stages of development OR - we do not make any early (alpha) releases at all (what about release early, release often, then?) I would really want to know your view on this issue. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Discussion about Maven
Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: Grzegorz Kossakowski wrote: On the other hand, milestones are just our internal releases and I think we can live with these gaps. No, they are not internal: http://cocoon.apache.org/2.1/changes.html http://archive.apache.org/dist/cocoon/SOURCES/ http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-core/2.2.0-M3/ Examples you provided do not apply to the situation I want to discuss. In 2.1 times we were shipping all dependencies ourselves so there is no problem of dependency resolution. I hope it is still an option. I was talking about the situation when we want to release some early alpha that has _snapshot_ dependencies that (obviously) are _not_ available at central server. If we want to make such a release it has to be internal because we cannot ship it or upload at central. Ok, I understand. I wanted to know what are our rules. Do we: - want to have such a internal releases I'd avoid using word release for this as it has some legal implications and we would get chewed up for using it :) Yes I think you can do such builds and place them on your private space at people.apache.org or on cocoon zones, and call it nightly or build or some such, but not a milestone *release*. And it is a good idea to do such builds as long as it helps to further development of Cocoon. OR - we really think that world is perfect and we'll always depend on released artifacts even in early stages of development IMHO, for milestone *release*, I'd bundle all necessary unreleased dependencies and upload to www.apache.org/dist. I'm not sure if there are any legal gotchas with this approach, but it worked for us in the past, for 2.1 milestones. OR - we do not make any early (alpha) releases at all (what about release early, release often, then?) -1. I'd prefer to have a (semi) regular milestone releases, even if it is harder to do with Maven... Vadim I would really want to know your view on this issue.
Re: Discussion about Maven
Vadim Gritsenko pisze: I wanted to know what are our rules. Do we: - want to have such a internal releases I'd avoid using word release for this as it has some legal implications and we would get chewed up for using it :) Ah, I'm young committer so forgive me that I omit legal implications and use inappropriate words. I'm really hard working to improve my English. :-) I agree it should not be called release. Yes I think you can do such builds and place them on your private space at people.apache.org or on cocoon zones, and call it nightly or build or some such, but not a milestone *release*. And it is a good idea to do such builds as long as it helps to further development of Cocoon. +1 IMHO, for milestone *release*, I'd bundle all necessary unreleased dependencies and upload to www.apache.org/dist. I'm not sure if there are any legal gotchas with this approach, but it worked for us in the past, for 2.1 milestones. It will not work with Maven and it can't be called release I think. My personal opinion is that release (after changing wording) should be something that we can officially ship using our infrastructure. Part of our infrastructure is Maven now but in order to upload to its central server we can't have snapshot dependencies as pointed out earlier. The only solution I can think of is that we stay longer in nighly build mode and we can switch to milestone mode as soon as all of our dependencies are released ones. I think that it will work well only if we successfully push projects we depend on to follow release early, release often practice so we will not bed forced to stay in nighly build phase too long. I'm not so much experienced with Open Source to have a strong opinion on this. Do you think that we effectively push other project? -1. I'd prefer to have a (semi) regular milestone releases, even if it is harder to do with Maven... I don't think it's harder with Maven. Maven was important factor when it comes to ability to have independent release cycles. We just need to clearly define terms (like release) we use and get used to the thought that we should tend to depend on released versions and talk more with other projects about releasing their goodies. WDYT? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Discussion about Maven
Grzegorz Kossakowski wrote: Examples you provided do not apply to the situation I want to discuss. In 2.1 times we were shipping all dependencies ourselves so there is no problem of dependency resolution. I was talking about the situation when we want to release some early alpha that has _snapshot_ dependencies that (obviously) are _not_ available at central server. If we want to make such a release it has to be internal because we cannot ship it or upload at central. I wanted to know what are our rules. Do we: - want to have such a internal releases OR - we really think that world is perfect and we'll always depend on released artifacts even in early stages of development OR - we do not make any early (alpha) releases at all (what about release early, release often, then?) I would really want to know your view on this issue. I have always been unhappy that Cocoon releases contained non-released jars for a few reasons: 1. Often the jars were labeled something like xyz-20070525-dev.jar. It is impossible to download the source for this and know for sure that it matches what the jar was built from and whoever actually built the jar didn't put the source where someone could find it. BTW - this is much easier with subversion repositories as the builds can be tagged with the revision number. 2. Who is going to support this? Try asking a question about a problem. You should expect that when they ask for the version and you tell them you will either get nothing but silence or laughter. We make no guarantees about our repository and neither does anyone else. Unfortunately, some of the projects Cocoon has components built around only perform releases infrequently. Often we have encountered bugs that really need to be fixed. And finally, Cocoon uses so many other jars that a release would never be accomplished if we required formal versions of them all. However, with 2.2 I hope we can make sure that all the core Cocoon components only leverage jars from projects that are pretty stable and well maintained. I would suggest that if we are finding that some projects are not responsive then it might be time to look for alternatives to them or perhaps even drop the Cocoon block in question. Of course, I haven't actually looked to see which blocks would be impacted so even that may be impractical. Ralph
Re: Discussion about Maven
Torsten Curdt pisze: 3. We cannot put milestones that depend on snapshot versions on central. It means that we can't upload following artifacts: org.apache.cocoon:cocoon-maven-plugin:1.0.0-M1 org.apache.cocoon:cocoon-rcl-spring-reloader:1.0.0-M1 org.apache.cocoon:cocoon-rcl-webapp-wrapper:1.0.0-M1 If there are people who can vote over on jakarta land ...please do so! The vote for commmons jci rc3 is still open ...but so far I only got only one +1 (that makes two +1s with mine) ...at least not -1s so far. I'd assume that would also help with the release of the above artifacts. A frustrated... Torsten, thanks for all the effort you have put into making this release. I wasn't aware that it's so painful to release something under commons umbrella. I'll keep my fingers crossed for you. :-) Even though I agree that it's the best to release all of our dependencies I would like to know your opinion on how to handle cases when not all our dependencies are on central server. I'm going to play with profiles.xml file and see how it performs for us. I would like to no if anyone is going to have a better/other idea. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Discussion about Maven
Grzegorz Kossakowski wrote:
Even though I agree that it's the best to release all of our
dependencies I would like to know your opinion on how to handle cases
when not all our dependencies are on central server. I'm going to play
with profiles.xml file and see how it performs for us. I would like to
no if anyone is going to have a better/other idea.
We have to distinguish between two scenarios:
1. building your own application using Cocoon artifacts
2. building Cocoon from SVN
ad 1): It was my mistake that I released a POM with dependencies that are not
available on the central Maven repository. As soon as commons-jci is available,
there is no need for it anymore.
ad 2): It's only some blocks (e.g. some portal stuff) that depend on
dependencies outside. As long as they don't get released, that's not a problem.
Note that the root POM doesn't have any dependency on any other repository than
the central Maven repository anymore.
Things might be different with Maven 2.1 but I suggest that we solve this
problem when Maven 2.1 is generally available.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Discussion about Maven
Reinhard Poetz pisze: Grzegorz Kossakowski wrote: Even though I agree that it's the best to release all of our dependencies I would like to know your opinion on how to handle cases when not all our dependencies are on central server. I'm going to play with profiles.xml file and see how it performs for us. I would like to no if anyone is going to have a better/other idea. We have to distinguish between two scenarios: 1. building your own application using Cocoon artifacts 2. building Cocoon from SVN ad 1): It was my mistake that I released a POM with dependencies that are not available on the central Maven repository. As soon as commons-jci is available, there is no need for it anymore. +1 ad 2): It's only some blocks (e.g. some portal stuff) that depend on dependencies outside. As long as they don't get released, that's not a problem. Not completely true. Do we take into consideration the case that we depend on snapshots/milestones uploaded somewhere (let it be our or other's staging repos) and make our own milestone early release? I want to say that due to COCOO-1745 (aka MNG-2743) we could suffer from unsatisfied dependencies because repository declaration is not handled correctly. Note that the root POM doesn't have any dependency on any other repository than the central Maven repository anymore. I'm glad to hear that. Putting profiles.xml file at root dir does not tie our root pom to it. It's only a configuration file for Maven needed only for devs and folks interested in building Cocoon. Things might be different with Maven 2.1 but I suggest that we solve this problem when Maven 2.1 is generally available. I won't insist on this change, we have more important goals but don't tell me in the future that I hadn't warned you. ;-) -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Discussion about Maven
Hello, I talked with Maven developers on IRC today. I asked for the problem[1] we are currently facing. They give me interesting advices and thoughts that may interest you. I paste cleaned up log file of the talk: [15:32:18] grek hi, I'm Grzegorz Kossakowski, a member of PMC of Apache Cocoon [15:33:07] grek I'm looking for help with Maven issues that seem to stop us from releasing artifacts :( [15:34:28] grek being more precise, we are affected by this issue very badly: http://jira.codehaus.org/browse/MNG-2743 [15:35:14] grek Is there anyone eager to help? [16:32:14] wsmoak grek: it's marked for 2.0.4. can you confirm it also happens with 2.0.6 ? [16:33:31] wsmoak and... after a quick read, can you duplicate repository elements where you need them, so you can proceed with the release ? [16:34:01] grek wsmoak: yes, it happens with 2.0.6 [16:35:22] grek wsmoak: yes, we can do this (and done it before) but we have to ask our *users* to put repository elements in *their* poms [16:35:46] grek I'll give you more links explaining the situation [16:36:03] wsmoak so it's not just a problem at release time? [16:36:45] wsmoak why can't the artifacts in that other repo be put in the central repo? [16:37:30] grek they are waiting in your JIRA ready for upload AFAIR ;) ^^ here I confused commons-jci with xreporter artifacts that waited for upload ^^ [16:38:56] grek but the problem still persists, Cocoon has _lots_ of dependencies, some of the stuff is just in between of conversion to the Maven [16:39:05] maxb Isn't central supposed to be selfcontained anyway? [16:39:30] grek what do you mean by self-contained? [16:39:40] wsmoak ok. assuming no problems with the upload bundle and carlos gets them into central, is there still a problem? [16:39:48] jvanzyl if you mean a complete transitive closure, yes but we don't have a way to check just yet [16:40:50] wsmoak poms in the central repo shouldn't define additional repositories [16:41:14] wsmoak it makes users in corporate environments nervous to see Maven trying to download from random places [16:41:28] grek hmmm, good point [16:41:47] grek let me explain our situation and policy at Apache Cocoon [16:42:46] jvanzyl wsmoak: that would be a good rule to check for upload bundles actually [16:42:58] jvanzyl no external repository definitions [16:43:03] * jvanzyl makes a note [16:43:24] grek if we want release something as RC (or final) we have to make sure that we do not depend on snapshot versions and all our dependencies are at central [16:44:22] grek however, we also release milestones which can depend on snapshots and can define it's own repositories (for those unreleased artifacts) [16:45:39] grek and that's the case now, we want to release a milestone of our own Maven plug-in so users can test it and report back if everything works [16:45:50] wsmoak grek: release meaning you want these milestones in the central repo? [16:46:08] grek wsmoak: yes [16:46:28] wsmoak then snapshots simply aren't allowed... you'll have to release milestones of your dependencies. [16:46:49] wsmoak but these aren't really users you're asking to help test, are they? they're more involved than that. [16:47:16] wsmoak what's wrong with staging it on people.apache.org/builds/cocoon and asking them to add a repository to their settings.xml to test ? [16:47:49] grek wsmoak: we have done exactly what you suggest [16:48:08] grek wait a minute, I'll provide links [16:48:48] wsmoak (btw, the Struts PMC has the same policy... snapshot dependencies are allowed in alpha releases.) [16:49:35] grek http://thread.gmane.org/gmane.text.xml.cocoon.devel/73469 and my answers in this thread [16:50:11] grek http://thread.gmane.org/gmane.text.xml.cocoon.devel/73495 - here is the user affected by the MNG-2743 [16:55:13] wsmoak ok. sounds like you're waiting on carlos to close a MAVENUPLOAD issue. [16:56:18] BrianFox grek: you can use the enforcer plugin to make sure people are using 2.0.6 to build cocoon 2.2 [16:56:30] wsmoak Kenney's 2006-01-07 comment on COCOON-1975 sounds right on (and that issue is closed). [16:57:03] grek BrianFox: we use it already, but will it work if someone just uses the artifacts but does not build them? [16:58:26] BrianFox no. I just saw you comment in that thread asking Joakim which version he used. With Enforcer you would know ;-) [16:59:11] BrianFox the prerequisites would affect users of plugins if that's what you mean [17:00:31] grek we require Maven 2.0.6 not only for plug-ins/building but also when people just depend on our artifacts, it's due to dependencyManagment fixed in 2.0.6 [17:00:56] BrianFox i see [17:01:27] wsmoak I don't think you can force them to build their own projects with 2.0.6. [17:01:44] wsmoak you can keep them from using your plugins *unless* they are
Re: Discussion about Maven
3. We cannot put milestones that depend on snapshot versions on central. It means that we can't upload following artifacts: org.apache.cocoon:cocoon-maven-plugin:1.0.0-M1 org.apache.cocoon:cocoon-rcl-spring-reloader:1.0.0-M1 org.apache.cocoon:cocoon-rcl-webapp-wrapper:1.0.0-M1 If there are people who can vote over on jakarta land ...please do so! The vote for commmons jci rc3 is still open ...but so far I only got only one +1 (that makes two +1s with mine) ...at least not -1s so far. I'd assume that would also help with the release of the above artifacts. A frustrated... -- Torsten
