You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jorg Heymans <jh...@domek.be> on 2006/08/01 00:59:40 UTC
Re: Status of releasing M1 artifacts
On 7/31/06 3:11 PM, in article 44CE017C.4010405@apache.org, "Reinhard Poetz"
<re...@apache.org> wrote:
>
> So far I've been able to release
>
> cocoon
> cocoon-core-modules
> cocoon-bootstrap
> cocoon-core
I did:
cocoon-tools-modules
cocoon-blocks-modules
cocoon-commons-modules
cocoon-deployer-modules
cocoon-deployer-core
cocoon-deployer-plugin
cocoon-licenses
I tried to rerelease cocoon-core because it was missing cocoon-licenses as
dependency but I'm getting errors about cocoon-bootstrap missing. Reinhard
you seemed to have managed to release cocoon-core, could you do it again
please as I have removed the tag and artifacts on people.a.o already ?
Also, note that there is no need to disable modules when releasing a module
pom, you can release it non-recursively by doing
mvn -N release:prepare release:perform -Darguments="-N"
Regards
jorg
Re: Status of releasing M1 artifacts
Posted by Jorg Heymans <jh...@domek.be>.
On 8/1/06 7:54 AM, in article 44CEECAF.7060700@apache.org, "Reinhard Poetz"
<re...@apache.org> wrote:
>> I tried to rerelease cocoon-core because it was missing cocoon-licenses as
>> dependency
>
> why do we need such a dependency? I don't understand what it really buys us.
>
There has been talk about this a while ago, about finding an easy way to
redistribute our licenses with the blocks. I remember suggesting this
solution as a way of "making sure" that our licenses are included in maven
based cocoon deployments. Perhaps I'm mistaken my suggestion for a decision
though, so feel free to remove it again if it doesn't buy us anything in
legal-land.
>> mvn -N release:prepare release:perform -Darguments="-N"
>
> what a strange notation ... I tried it with "-N" only.
>
The first -N applies to the maven you're invoking, the second -N applies to
the embedder that invokes maven from within maven during the release
process.
http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html
> Another question: Is it really a good idea if we add the release tags to one
> directory? Over the time we will get hundrets of them. Maybe we should build
> some hierarchy
>
> /cocoon/releases/core
> /cocoon/releases/blocks/cforms
> /cocoon/releases/blocks/ctemplate
> /cocoon/releases/blocks/...
> /cocoon/releases/tools/...
> /cocoon/releases/pom (for our pom artifacts)
>
+1 for a hierarchy of some sort. Is there another way of enforcing this
structure other than to add -DtagBase=http://svn.a.o.. to the commandline
when invoking the release plugin ?
Jorg
Re: Status of releasing M1 artifacts
Posted by Reinhard Poetz <re...@apache.org>.
Jorg Heymans wrote:
> On 7/31/06 3:11 PM, in article 44CE017C.4010405@apache.org, "Reinhard Poetz"
> <re...@apache.org> wrote:
>
>> So far I've been able to release
>>
>> cocoon
>> cocoon-core-modules
>> cocoon-bootstrap
>> cocoon-core
>
> I did:
>
> cocoon-tools-modules
> cocoon-blocks-modules
> cocoon-commons-modules
> cocoon-deployer-modules
> cocoon-deployer-core
> cocoon-deployer-plugin
> cocoon-licenses
>
> I tried to rerelease cocoon-core because it was missing cocoon-licenses as
> dependency
why do we need such a dependency? I don't understand what it really buys us.
> but I'm getting errors about cocoon-bootstrap missing.
yes, because you don't have the released version. You can get it from the rsynch
repository from people.apache.org and can install it manually to your local repo.
> Reinhard
> you seemed to have managed to release cocoon-core, could you do it again
> please as I have removed the tag and artifacts on people.a.o already ?
ah, ok. I hope I have some time.
> Also, note that there is no need to disable modules when releasing a module
> pom, you can release it non-recursively by doing
>
> mvn -N release:prepare release:perform -Darguments="-N"
what a strange notation ... I tried it with "-N" only.
Another question: Is it really a good idea if we add the release tags to one
directory? Over the time we will get hundrets of them. Maybe we should build
some hierarchy
/cocoon/releases/core
/cocoon/releases/blocks/cforms
/cocoon/releases/blocks/ctemplate
/cocoon/releases/blocks/...
/cocoon/releases/tools/...
/cocoon/releases/pom (for our pom artifacts)
WDYT?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Status of releasing M1 artifacts
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> The idea is that finally each block gets its own documentation. The
> problem now is that we will split up our documentation in smaller chunks
> (soon) but we aren't that far. This will cause a lot of broken URL in
> the future.
Not if you keep docs in Daisy. If docs are kept in Daisy, URLs will stay the
same (same IDs) even if logical organization is different (different nav doc).
Vadim
Re: Status of releasing M1 artifacts
Posted by Reinhard Poetz <re...@apache.org>.
hepabolu wrote:
> Reinhard Poetz said the following on 2/8/06 15:08:
>>> If all new URLs consist of only Daisy IDs, they should not break:
>>> there should not be much of document removals, right? Even if you
>>> intend to remove a document, you can replace it with a redirect to
>>> correct location. So I think new documentation can be managed without
>>> breaking any URLs.
>
> True. 2.2 gives the opportunity to change the URLs, so let's take that
> advantage.
>
>> The idea is that finally each block gets its own documentation. The
>> problem now is that we will split up our documentation in smaller
>> chunks (soon) but we aren't that far. This will cause a lot of broken
>> URL in the future.
>
> Do leave the documentation in Daisy, create separate collections and if
> necessary separate sites for each block, but don't move it out of Daisy
> to something that is as cumbersome as the old xdocs situation.
>
> Now that the docs are in Daisy more documentation has been written and
> updated than in a very long time before.
>
> And if you do that, and all docs are still in one repository, the Daisy
> IDs won't change.
>
>> Having said this, it might take some time until we really have block
>> specific docs and we shouldn't wait now that maybe never get done.
>
> True. But I'd rather spend time and energy on improving/simplifying the
> current process of extracting Daisy docs onto the website than moving
> the docs to yet another system.
>
> Besides, it's good for Cocoon that the docs are created with Cocoon.
>
> Bye, Helma
>
I *want* to leave the docs in Daisy. I've started to write a Daisy plugin that
gets a Daisy repository and a navigation document as configuration parameters.
If the plugin is added to the pre-site phase of the Maven build process, the
docs are added to the site. This way document generation and if we want
publishing will become very simple in the future.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Status of releasing M1 artifacts
Posted by hepabolu <he...@gmail.com>.
Reinhard Poetz said the following on 2/8/06 15:08:
>> If all new URLs consist of only Daisy IDs, they should not break:
>> there should not be much of document removals, right? Even if you
>> intend to remove a document, you can replace it with a redirect to
>> correct location. So I think new documentation can be managed without
>> breaking any URLs.
True. 2.2 gives the opportunity to change the URLs, so let's take that
advantage.
> The idea is that finally each block gets its own documentation. The
> problem now is that we will split up our documentation in smaller chunks
> (soon) but we aren't that far. This will cause a lot of broken URL in
> the future.
Do leave the documentation in Daisy, create separate collections and if
necessary separate sites for each block, but don't move it out of Daisy
to something that is as cumbersome as the old xdocs situation.
Now that the docs are in Daisy more documentation has been written and
updated than in a very long time before.
And if you do that, and all docs are still in one repository, the Daisy
IDs won't change.
> Having said this, it might take some time until we really have block
> specific docs and we shouldn't wait now that maybe never get done.
True. But I'd rather spend time and energy on improving/simplifying the
current process of extracting Daisy docs onto the website than moving
the docs to yet another system.
Besides, it's good for Cocoon that the docs are created with Cocoon.
Bye, Helma
Re: Status of releasing M1 artifacts
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>> Vadim Gritsenko wrote:
>>> Jorg Heymans wrote:
>>>> On 8/1/06 2:49 PM, in article 44CF4DEF.8010500@apache.org, "Reinhard
>>>> Poetz"
>>>>> I also think that we should wait with an official announcement as
>>>>> long as we
>>>>> have at least some minimal docs available at
>>>>> http://cocoon.apache.org/2.2-M1/.
>>>
>>> -1 on location specified above. I don't see no sense in keeping
>>> documentation of each and every milestone/alpha/beta/rc release. URL
>>> should read
>>>
>>> http://cocoon.apache.org/2.2/
>>>
>>> Front page may say that currently these are 2.2m1 documentation and
>>> it is a work in progress. Once first 2.2.0 release is out, this
>>> notice could be removed.
>>
>> If we don't have a problem if our urls break, we can publish our docs
>> to http://cocoon.apache.org/2.2/. WDYT?
>
> If all new URLs consist of only Daisy IDs, they should not break: there
> should not be much of document removals, right? Even if you intend to
> remove a document, you can replace it with a redirect to correct
> location. So I think new documentation can be managed without breaking
> any URLs.
The idea is that finally each block gets its own documentation. The problem now
is that we will split up our documentation in smaller chunks (soon) but we
aren't that far. This will cause a lot of broken URL in the future.
Having said this, it might take some time until we really have block specific
docs and we shouldn't wait now that maybe never get done.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Status of releasing M1 artifacts
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> Vadim Gritsenko wrote:
>> Jorg Heymans wrote:
>>> On 8/1/06 2:49 PM, in article 44CF4DEF.8010500@apache.org, "Reinhard
>>> Poetz"
>>>> I also think that we should wait with an official announcement as
>>>> long as we
>>>> have at least some minimal docs available at
>>>> http://cocoon.apache.org/2.2-M1/.
>>
>> -1 on location specified above. I don't see no sense in keeping
>> documentation of each and every milestone/alpha/beta/rc release. URL
>> should read
>>
>> http://cocoon.apache.org/2.2/
>>
>> Front page may say that currently these are 2.2m1 documentation and it
>> is a work in progress. Once first 2.2.0 release is out, this notice
>> could be removed.
>
> If we don't have a problem if our urls break, we can publish our docs to
> http://cocoon.apache.org/2.2/. WDYT?
If all new URLs consist of only Daisy IDs, they should not break: there should
not be much of document removals, right? Even if you intend to remove a
document, you can replace it with a redirect to correct location. So I think new
documentation can be managed without breaking any URLs.
Vadim
Re: Status of releasing M1 artifacts
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Jorg Heymans wrote:
>> On 8/1/06 2:49 PM, in article 44CF4DEF.8010500@apache.org, "Reinhard
>> Poetz"
>>> I also think that we should wait with an official announcement as
>>> long as we
>>> have at least some minimal docs available at
>>> http://cocoon.apache.org/2.2-M1/.
>
> -1 on location specified above. I don't see no sense in keeping
> documentation of each and every milestone/alpha/beta/rc release. URL
> should read
>
> http://cocoon.apache.org/2.2/
>
> Front page may say that currently these are 2.2m1 documentation and it
> is a work in progress. Once first 2.2.0 release is out, this notice
> could be removed.
If we don't have a problem if our urls break, we can publish our docs to
http://cocoon.apache.org/2.2/. WDYT?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Status of releasing M1 artifacts
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Jorg Heymans wrote:
> On 8/1/06 2:49 PM, in article 44CF4DEF.8010500@apache.org, "Reinhard Poetz"
>> I also think that we should wait with an official announcement as long as we
>> have at least some minimal docs available at http://cocoon.apache.org/2.2-M1/.
-1 on location specified above. I don't see no sense in keeping documentation of
each and every milestone/alpha/beta/rc release. URL should read
http://cocoon.apache.org/2.2/
Front page may say that currently these are 2.2m1 documentation and it is a work
in progress. Once first 2.2.0 release is out, this notice could be removed.
Vadim
Re: Status of releasing M1 artifacts
Posted by Jorg Heymans <jh...@domek.be>.
On 8/1/06 2:49 PM, in article 44CF4DEF.8010500@apache.org, "Reinhard Poetz"
<re...@apache.org> wrote:
> I released cocoon-core and it's available in the rsync repository. I think we
> should wait with the sync request with ibiblio as long as we have some blocks
> and the archetypes (need the template block) are available.
>
+1
> I also think that we should wait with an official announcement as long as we
> have at least some minimal docs available at http://cocoon.apache.org/2.2-M1/.
>
+1
Jorg
Re: Status of releasing M1 artifacts
Posted by Reinhard Poetz <re...@apache.org>.
Jorg Heymans wrote:
> I tried to rerelease cocoon-core because it was missing cocoon-licenses as
> dependency but I'm getting errors about cocoon-bootstrap missing.
I released cocoon-core and it's available in the rsync repository. I think we
should wait with the sync request with ibiblio as long as we have some blocks
and the archetypes (need the template block) are available.
I also think that we should wait with an official announcement as long as we
have at least some minimal docs available at http://cocoon.apache.org/2.2-M1/.
WDOT?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de