You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2008/03/06 15:24:50 UTC
"Normal" release artifacts
I have started to write some Ant scripts to produce non-Maven release artifacts.
This will of course help everybody who doesn't want to use Maven or Ivy for
dependency management but will also bundle all the information that belongs
together (src, binaries, docs, javadocs, licensing information).
Most of the work has been finished but now I got stuck with the question if we
should ship third-party libs or not. E.g. for the Spring configurator this would
be everything listed at
http://cocoon.apache.org/subprojects/configuration/1.0/spring-configurator/1.0/dependencies.html.
The advantages are that the user gets everything that she needs but the
disadvantages are that we would have to add all license files of all 3rd-party
libs (AFAIK there is no automatic mechanism for that) and the download size
would increase. And I think that in 2008 you shouldn't manage your library
dependency graph manually anymore in your projects (Maven, Ivy, the Maven Ant
tasks are of great help and at least the last one is very easy to use.)
Finally, if we decide to ship 3rd party libs, one technical question:
Am I right that there is no automatic mechanism for Ant or Maven that pulls
together all license information of all 3rd-party libs?
And, if we decide to not ship 3rd party libs, am I right that we don't have to
add license files of them? (Otherwise all artifacts on the central Maven
repository would be legally broken ...)
Any comments?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: "Normal" release artifacts
Posted by Reinhard Poetz <re...@apache.org>.
David Crossley wrote:
> Vadim Gritsenko wrote:
>> Reinhard Poetz wrote:
>>> Reinhard Poetz wrote:
>>>> Finally, if we decide to ship 3rd party libs, one technical question:
>>>> Am I right that there is no automatic mechanism for Ant or Maven
>>>> that pulls together all license information of all 3rd-party libs?
>
> That would be good. At Forrest, we have similar issues
> not yet solved.
Is anybody aware of some code that helps in the ASF? Where could I ask such a
question? Is 'community@' the right forum?
>>>> And, if we decide to not ship 3rd party libs, am I right that we
>>>> don't have to add license files of them? (Otherwise all artifacts
>>>> on the central Maven repository would be legally broken ...)
>>>> Any comments?
>
> Perhaps legal-discuss@ list can help.
ok, will do so?
>>> Anyone?
>>>
>>> If I don't hear anything I will *not* include any third-party stuff
>>> (the only exception will be the getting-started stuff).
>>>
>>> Users will have to download all libraries themselves.
>> IMHO what's good a downloadable release if 'cocoon.sh run' does not
>> work? One of the points of such release is to make it one stop shop,
>> to get everything up and running in one quick download. May be it's
>> just me. Shrug.
>
> What does the "getting-started stuff" include?
> Perhaps we include the bare minimum and list
> exactly the other supporting products that they
> need to go further.
yes, I intend to write a 'getting-started guide' for non-Maven 2 users.
> Any supporting products that we do bundle,
> need their source too.
right
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: "Normal" release artifacts
Posted by David Crossley <cr...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
> >Reinhard Poetz wrote:
> >>
> >>I have started to write some Ant scripts to produce non-Maven
> >>release artifacts. This will of course help everybody who doesn't
> >>want to use Maven or Ivy for dependency management but will also
> >>bundle all the information that belongs together (src, binaries,
> >>docs, javadocs, licensing information).
> >>Most of the work has been finished but now I got stuck with the
> >>question if we should ship third-party libs or not. E.g. for the
> >>Spring configurator this would be everything listed at
> >>http://cocoon.apache.org/subprojects/configuration/1.0/spring-configurator/1.0/dependencies.html
> >>. The advantages are that the user gets everything that she needs but
> >>the disadvantages are that we would have to add all license files of all
> >>3rd-party libs (AFAIK there is no automatic mechanism for that) and the
> >>download size would increase. And I think that in 2008 you shouldn't
> >>manage your library dependency graph manually anymore in your projects
> >>(Maven, Ivy, the Maven Ant tasks are of great help and at least the last
> >>one is very easy to use.)
> >>Finally, if we decide to ship 3rd party libs, one technical question:
> >>Am I right that there is no automatic mechanism for Ant or Maven
> >>that pulls together all license information of all 3rd-party libs?
That would be good. At Forrest, we have similar issues
not yet solved.
> >>And, if we decide to not ship 3rd party libs, am I right that we
> >>don't have to add license files of them? (Otherwise all artifacts
> >>on the central Maven repository would be legally broken ...)
> >>Any comments?
Perhaps legal-discuss@ list can help.
> >Anyone?
> >
> >If I don't hear anything I will *not* include any third-party stuff
> >(the only exception will be the getting-started stuff).
> >
> >Users will have to download all libraries themselves.
>
> IMHO what's good a downloadable release if 'cocoon.sh run' does not
> work? One of the points of such release is to make it one stop shop,
> to get everything up and running in one quick download. May be it's
> just me. Shrug.
What does the "getting-started stuff" include?
Perhaps we include the bare minimum and list
exactly the other supporting products that they
need to go further.
Any supporting products that we do bundle,
need their source too.
-David
Samples distribution - Help needed
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
>> 4. cocoon-samples-1.0.0.zip
I won't have time to work on the samples distribution in a foreseeable future
because I have to concentrate on getting all the other stuff (1, 2 and 3) done.
By mimicking the 'getting-started-create' Ant target in
trunk/tools/release-builder/build.xml, it shouldn't be that hard to produce a
samples distribution that comes with a bundled Jetty and some shell scripts for
Win/Linux/Mac that can start the application.
Additionally the LICENSE.txt file has to be created correctly which is probably
the most difficult task, especially if you want to automatize it.
If somebody wants to work on the sample distribution, I'd be happy to help with
the integration into the release-builder (checksums, PGP, packaging, etc.).
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: "Normal" release artifacts
Posted by Vadim Gritsenko <va...@reverycodes.com>.
On Mar 16, 2008, at 10:42 AM, Reinhard Poetz wrote:
> Vadim Gritsenko wrote:
>> IMHO what's good a downloadable release if 'cocoon.sh run' does not
>> work?
>
> I'm not sure if I understand your concerns here correctly. Maybe I
> wasn't clear about what release artifacts I want to create. Here's
> the list:
>
> 1. cocoon-core-2.2.0.zip
> cocoon-servlet-service-1.0.0.zip
> cocoon-configuration-1.0.0.zip
>
> 2. cocoon-fop-1.0.0.zip
> cocoon-forms-1.0.0.zip
> ... [all the other blocks]
>
> 3. cocoon-2.2-getting-started-1.0.0.zip
> cocoon-2.2-legacy-getting-started-1.0.0.zip
>
> 4. cocoon-samples-1.0.0.zip
>
> 1. and 2. are the releases of our production ready sources (+ docs,
> +javadocs, +binaries). If somebody wants to use Cocoon in one of his
> projects and doesn't want to use Maven 2, Ivy or the Maven Ant
> tasks, he has to download them and add the libraries to his (web)
> application.
> To some extend it is even dangerous to add third-party libraries
> because this might lead to the inclusion of conflicting versions (or
> at least to unintended duplication) just because you add the
> libraries of several e.g. Cocoon blocks that were created at
> different times.
>
> The second purpose of 1. and 2. is providing a single release
> artifact of parts that belong together (docs, apidocs, sources,
> binaries). As it was pointed out several times by you and others,
> it feels strange to have only Maven 2 release artifacts.
>
> 3. and 4. are different. 'cocoon-2.2-getting-started' is a
> suggestion how you could organize a Cocoon project that uses blocks
> and that uses Ant as build system. We could also have a 'cocon-2.2-
> legacy-getting-started' package, that uses Cocoon the old way
> without using the SSF infrastructure.
>
> 'cocoon-samples' is the package for that the 'cocoon.sh run'
> proposal applies, IMO.
>
>> One of the points of such release is to make it one stop shop, to
>> get everything up and running in one quick download.
>
> Is 'cocoon-samples' good enough to be the one-stop-shop that you
> intend? However, I would like add a big warning message, that it is
> not supposed to be used as starting-point for a new Cocoon project.
If it includes core + all released blocks + all samples + all 3rd
party dependencies -- yes I think that's exactly what I had in mind.
> So let me ask again: Do we need third-party libraries in 1. and 2.
> or not? (For 3. and 4. it's clear to me because they wouldn't be
> useable otherwise.)
It would be good to have required dependencies there as well but given
existence of 4. it is IMHO less critical.
Vadim
Re: "Normal" release artifacts
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> IMHO what's good a downloadable release if 'cocoon.sh run' does not
> work?
I'm not sure if I understand your concerns here correctly. Maybe I wasn't clear
about what release artifacts I want to create. Here's the list:
1. cocoon-core-2.2.0.zip
cocoon-servlet-service-1.0.0.zip
cocoon-configuration-1.0.0.zip
2. cocoon-fop-1.0.0.zip
cocoon-forms-1.0.0.zip
... [all the other blocks]
3. cocoon-2.2-getting-started-1.0.0.zip
cocoon-2.2-legacy-getting-started-1.0.0.zip
4. cocoon-samples-1.0.0.zip
1. and 2. are the releases of our production ready sources (+ docs, +javadocs,
+binaries). If somebody wants to use Cocoon in one of his projects and doesn't
want to use Maven 2, Ivy or the Maven Ant tasks, he has to download them and add
the libraries to his (web) application.
To some extend it is even dangerous to add third-party libraries because this
might lead to the inclusion of conflicting versions (or at least to unintended
duplication) just because you add the libraries of several e.g. Cocoon blocks
that were created at different times.
The second purpose of 1. and 2. is providing a single release artifact of parts
that belong together (docs, apidocs, sources, binaries). As it was pointed out
several times by you and others, it feels strange to have only Maven 2 release
artifacts.
3. and 4. are different. 'cocoon-2.2-getting-started' is a suggestion how you
could organize a Cocoon project that uses blocks and that uses Ant as build
system. We could also have a 'cocon-2.2-legacy-getting-started' package, that
uses Cocoon the old way without using the SSF infrastructure.
'cocoon-samples' is the package for that the 'cocoon.sh run' proposal applies, IMO.
> One of the points of such release is to make it one stop shop, to
> get everything up and running in one quick download.
Is 'cocoon-samples' good enough to be the one-stop-shop that you intend?
However, I would like add a big warning message, that it is not supposed to be
used as starting-point for a new Cocoon project.
So let me ask again: Do we need third-party libraries in 1. and 2. or not? (For
3. and 4. it's clear to me because they wouldn't be useable otherwise.)
WDYT?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: "Normal" release artifacts
Posted by Vadim Gritsenko <va...@reverycodes.com>.
On Mar 14, 2008, at 2:33 PM, Reinhard Poetz wrote:
> Reinhard Poetz wrote:
>> I have started to write some Ant scripts to produce non-Maven
>> release artifacts. This will of course help everybody who doesn't
>> want to use Maven or Ivy for dependency management but will also
>> bundle all the information that belongs together (src, binaries,
>> docs, javadocs, licensing information).
>> Most of the work has been finished but now I got stuck with the
>> question if we should ship third-party libs or not. E.g. for the
>> Spring configurator this would be everything listed at http://cocoon.apache.org/subprojects/configuration/1.0/spring-configurator/1.0/dependencies.html
>> . The advantages are that the user gets everything that she needs
>> but the disadvantages are that we would have to add all license
>> files of all 3rd-party libs (AFAIK there is no automatic mechanism
>> for that) and the download size would increase. And I think that in
>> 2008 you shouldn't manage your library dependency graph manually
>> anymore in your projects (Maven, Ivy, the Maven Ant tasks are of
>> great help and at least the last one is very easy to use.)
>> Finally, if we decide to ship 3rd party libs, one technical question:
>> Am I right that there is no automatic mechanism for Ant or Maven
>> that pulls together all license information of all 3rd-party libs?
>> And, if we decide to not ship 3rd party libs, am I right that we
>> don't have to add license files of them? (Otherwise all artifacts
>> on the central Maven repository would be legally broken ...)
>> Any comments?
>
> Anyone?
>
> If I don't hear anything I will *not* include any third-party stuff
> (the only exception will be the getting-started stuff).
>
> Users will have to download all libraries themselves.
IMHO what's good a downloadable release if 'cocoon.sh run' does not
work? One of the points of such release is to make it one stop shop,
to get everything up and running in one quick download. May be it's
just me. Shrug.
Vadim
Re: "Normal" release artifacts
Posted by Reinhard Poetz <re...@apache.org>.
Reinhard Poetz wrote:
>
> I have started to write some Ant scripts to produce non-Maven release
> artifacts. This will of course help everybody who doesn't want to use
> Maven or Ivy for dependency management but will also bundle all the
> information that belongs together (src, binaries, docs, javadocs,
> licensing information).
>
> Most of the work has been finished but now I got stuck with the question
> if we should ship third-party libs or not. E.g. for the Spring
> configurator this would be everything listed at
> http://cocoon.apache.org/subprojects/configuration/1.0/spring-configurator/1.0/dependencies.html.
>
>
> The advantages are that the user gets everything that she needs but the
> disadvantages are that we would have to add all license files of all
> 3rd-party libs (AFAIK there is no automatic mechanism for that) and the
> download size would increase. And I think that in 2008 you shouldn't
> manage your library dependency graph manually anymore in your projects
> (Maven, Ivy, the Maven Ant tasks are of great help and at least the last
> one is very easy to use.)
>
> Finally, if we decide to ship 3rd party libs, one technical question:
> Am I right that there is no automatic mechanism for Ant or Maven that
> pulls together all license information of all 3rd-party libs?
> And, if we decide to not ship 3rd party libs, am I right that we don't
> have to add license files of them? (Otherwise all artifacts on the
> central Maven repository would be legally broken ...)
>
> Any comments?
Anyone?
If I don't hear anything I will *not* include any third-party stuff (the only
exception will be the getting-started stuff).
Users will have to download all libraries themselves.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________