You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gr...@tuffmail.com> on 2007/06/03 21:45:13 UTC
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 on 2.0.6, with the prerequisite element.
[17:01:52] <BrianFox> right
[17:02:00] <grek> I see
[17:02:17] <grek> so we will have to put big, fat warnings everywhere to use 2.0.6
[17:02:33] <wsmoak> so at this point it's just education-- encourage them to upgrade to 2.0.6 and point them at the docs on how to prepare
for upgrade.
[17:03:07] <grek> yeah, but the original problem still persists I think
[17:03:37] <wsmoak> true, but it's not even marked with a fix-for version, so I don't think waiting is really an option
[17:04:06] <grek> and I just realized that the dependency we are talking about here (commons-jci-fam) does not wait for upload, I confused
it with other artifacts waiting for upload
[17:05:40] <grek> wsmoak: I'm aware of that you'll not fix it tomorrow but we really have to find a solution, we have a lot of depdencencies
for which we have to prepare poms and upload them
[17:06:36] <grek> waiting for each upload is not an option for us when we talk about milestone release, it happens to slowly I guess
[17:07:11] <wsmoak> are these your own artifacts we're talking about ?
[17:08:25] <grek> no, in this particular case it's a commons-jci-fam that is not a part of Cocoon, obviously
[17:09:44] * wsmoak will be back in ~30 min
[17:24:48] <grek> after thinking about it for a while I'm starting to realize that you are right and we should really push other folks to
upload their artifacts to central
[17:29:02] <grek> on the other hand, the issue I'm constantly referring to does not allow us to make internal (not published on central)
alpha/milestone releases
[17:29:44] <grek> that could depend on unreleased stuff, of course
[17:32:14] <esm> grek: totally unrelated to your issue - i like your solution using an alternate testing-cocoon-settings.xml file
[17:33:21] <grek> esm: thanks :)
[17:34:05] <esm> having uses rm -rf ~/.m2/repository doesn't make sense and now I know a better way :-)
[17:36:09] <grek> esm: yeah, and if you work with mutliple projects you can test one with empty, separate local repository and after testing
continue the development of the another one without having to re-download the dependencies
[17:36:32] * esm nods
[...]
[17:44:22] <grek> wsmoak: can you give us an advice on making this internal releases I talked above?
[17:46:12] <grek> in order to gather some early feedback from users we really need to make those releases that depend on snapshots or
released artifacts not available at central yet and I guess that we would be fine if Maven just been doing what we expect from him to do
[17:46:45] <wsmoak> grek: seems like you're mostly there. "release" your milestone, but deploy it to a staging area and have users add that
repo to their settings.xml
[17:47:29] <wsmoak> since you can't release with snapshot dependencies, push the other projects to release to central.
[17:48:09] <grek> starts to make sense
[17:49:18] <grek> if so, why Maven allows to define repositories at pom level if they do not work and are discouraged in a fact?
[17:58:55] <jvanzyl> a mistake that will be corrected in 2.1
[17:59:14] <jvanzyl> and you just won't be able to put them in a POM
[17:59:25] <jvanzyl> but that's a big change so we can't do it in 2.0.x
[17:59:30] <grek> ah I see
[17:59:37] <jvanzyl> but you can still abide by the practice of doing what is in 2.1
[17:59:48] <jvanzyl> define all your repos up front in a shared settings.xml
[18:00:08] <jvanzyl> so that your POMs don't change when you use different repos underneath for whatever reason
[18:00:21] <jvanzyl> your infrastructure requirements should not be passed on to your clients
[18:00:32] <grek> yes, I totally agree
[18:01:48] <grek> I'm only disappointed that you don't document this good practices and don't refer to them whenever someone has the problem
similar to our
[18:04:03] <grek> jvanzyl: one more thing if we have this shared settings file how we can tell Maven that it will should use that file while
building Cocoon?
[18:04:37] <grek> I guess that people will not be happy with -s option or replacing their default settings file
[18:06:27] <jvanzyl> we could do something like map repository settings to a groupId
[18:06:40] <jvanzyl> so you would have them in your settings for work on cocoon, haven't quite figured it out
[18:06:46] <wsmoak> grek: I use different sets of repos by putting them all in one settings.xml, inside profiles.
[18:07:00] <jvanzyl> so we'll try to make it convenient
[18:07:10] <jvanzyl> but defining repos in POMs was a definite mistake
[18:07:20] <kenney> maybe it's an idea to export a part of the settings, like the profile, as a 'project settings' artifact
[18:07:59] <kenney> it would contain properties needed by the projects to build (like j2ee app locations or database info), and the
repositories required to build/use that project
[18:08:14] <grek> wsmoak: but then you still have to define which profile to use with -P option, right?
[18:08:36] <kenney> grek: not necesarily, you can active a profile in any pom
[18:08:36] <wsmoak> yes... these are your project developers we're talking about, right ?
[18:08:39] <jvanzyl> yes, we'll make it easier
[18:08:57] <jvanzyl> no reason we can't generally map some settings for a groupId
[18:09:01] <wsmoak> there are many ways to activate a profile, as long as all of you agree on some conventions.
[18:09:11] <jvanzyl> so all your junk for org.apache.cocoon gets picked up
[18:10:09] <esm> grek: we use this at Pluto: http://wiki.apache.org/portals/Pluto/Maven2Tips
[18:10:21] <esm> alluding to what wsmoak said
[18:10:31] <esm> just a profile devs activate to test builds, etc
[18:10:43] <grek> activating profiles that contain infrastructure info in poms does not seem to be a neat idea, still you have your poms
bloated with infrastructure stuff
[18:11:20] <esm> we ask the devs to modify ~/.m2/settings.xml instead of putting stuff inpoms
[18:11:21] <grek> jvanzyl: what about simplest solution possible: searching for settings.xml file along pom.xml ?
[18:11:52] <kenney> grek: there's already profiles.xml that serves that purpose
[18:11:52] <jvanzyl> esm: right that's what generally happens
[18:12:30] <grek> kenney: any documentation?
[18:12:38] <jvanzyl> grek: i've really just started trying to collect everything i've found working at big places with 500+ devs
[18:12:48] <kenney> grek: euh, maven.apache.org ? :)
[18:12:59] <jvanzyl> and i'm about to start another one and they've agreed to let me publish the information
[18:13:25] <grek> kenney: I was asking if profiles.xml is somewhere documented, but I hope it really is :)
[18:13:31] <kenney> http://maven.apache.org/guides/introduction/introduction-to-profiles.html
[18:14:42] <grek> jvanzyl: does it mean that we'll see your conclusions on dev list soon?
[18:15:13] <grek> kenney: thanks, starting to read this
[18:15:32] <jvanzyl> no, i'm just starting a project that will probably last a year
[18:15:37] <jvanzyl> but as i go i will
[18:15:46] <jvanzyl> first deliverable is in 8 weeks so probably around then
[18:16:06] <jvanzyl> but 2.1 will move along quickly after next week
[18:16:41] <grek> I'm getting lost here, do you want to say that you are going to propose replacement for Maven?
[18:16:47] <jvanzyl> no
[18:17:13] <jvanzyl> this is a client project where i'm using maven
[18:17:18] <grek> ah, I see
[18:17:37] <grek> and why do you mean that 2.1 will move along quickly?
[18:18:43] <grek> from lurking at dev I had an impression that 2.1 is not going to be released soon (I mean, a year period)
[18:19:16] <wsmoak> it can look that way, then jvanzyl stays up for three days straight and suddenly all the bugs are closed ;)
[18:19:42] <grek> wsmoak: heheh ;)
[18:19:57] <jvanzyl> yah, it's not moved in a while as we try to bridge 2.0.x with 2.1.x so there's no shock
[18:20:03] <jvanzyl> all 2.0.x stuff will run in 2.1.x
[18:20:26] <jvanzyl> it's actually quite stable
[18:20:29] <wsmoak> ... except stuff that defines repositories in the pom ? if it's no longer allowed, how's that going to work?
[18:20:58] <jvanzyl> pom readers used keyed of the version of the POM
[18:21:09] <wsmoak> ah, the model version
[18:21:16] <jvanzyl> that will be harder
[18:21:19] <jvanzyl> the plugins are easier
[18:22:08] <grek> if I can have a huble request... could you write really good docs explaining what and why was changed and how to migrate?
[18:23:07] <grek> Cocoon has suffered for long time because of lack of migration guides and I think Maven should not repeat others' mistakes
[18:23:19] <jvanzyl> http://docs.codehaus.org/display/MAVEN/Maven+2.1+Backward+Compatibility+Information
[18:23:52] <jvanzyl> all here:
[18:23:58] <jvanzyl> http://docs.codehaus.org/display/MAVEN/Home
[18:24:06] <jvanzyl> those top three is where you'll see everything
[18:25:06] <esm> btw the docs for upgrading to 2.0.6 were nice - the dependencyManagment fixes
[18:25:16] <grek> great, I'm happy to hear these all good news
[18:25:20] <grek> yes, I agree with esm
[...]
[18:49:08] <grek> argh, I'm having some problems with internet connection
[18:49:29] <kenney> is there a plugin out there that can check wheter something is done with the exception in a catch clause?
[18:49:42] <kenney> esp. stuff like this: catch ( Exception e ) { throw new FooException("bar!"); }
[18:50:06] <grek> it's sign to go offline, so I would like to thank all of you for the information and tips you have given to me
[18:50:19] <grek> thanks! :)
[18:50:36] <esm> kenney: can you configure a PMD rule to find those?
[18:50:43] <esm> grek: ttyl
[18:50:46] <kenney> hm, maybe
[18:54:10] <grek> ok, it's time leave, thanks again for your help, have a nice evening, bye!
Ok, it's time for conclusions:
1. Defining repositories is considered harmful and we should get rid of all of them
2. I think that we should move repository information to profiles.xml, but it's a subject of discussion
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
But we still can have it in our staging repository and ask our early testers to customize their settings.xml for or create new one. I don't
see it as a big deal really, but I'm thinking about other implications. Especially, not all milestones will be available on the central,
there will be "gap" in version number. On the other hand, milestones are just our internal releases and I think we can live with these gaps.
What do you think?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Discussion about Maven
Posted by Grzegorz Kossakowski <gk...@apache.org>.
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/
Re: Discussion about Maven
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Grzegorz Kossakowski <gk...@apache.org>.
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
Posted by Torsten Curdt <tc...@apache.org>.
>
> 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
Re: Discussion about Maven
Posted by Grzegorz Kossakowski <gk...@apache.org>.
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
Posted by Ralph Goers <Ra...@dslextreme.com>.
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
Posted by David Crossley <cr...@apache.org>.
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
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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
Posted by Grzegorz Kossakowski <gk...@apache.org>.
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
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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
Posted by Grzegorz Kossakowski <gk...@apache.org>.
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
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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