You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2005/09/19 11:19:38 UTC
Bricks example app in our whiteboard, WDYT?
Hi community,
I'm working on my "Bricks" example application for the GT [2] and I was
thinking of putting the source code in our whiteboard, if people don't
mind.
I don't want to make it a block as it contains the full source code of
a (very simple) standalone application built on Cocoon, including a
build system based on [1], and it's important to show how independent
from a particular version of Cocoon that can be.
I guess this will be a one man show for now, and others might have
different views of what an example app should be. So I'm not sure about
where to host it, but no one objects I'd like to put it in our
whiteboard for now.
The app uses all ASF components: Hivemind, OJB and Derby, so licenses
are clean (some non-ASL things will be downloaded from ibiblio at build
time, with an appropriate warning).
I know we don't have a precise policy for using the whiteboard, but I
feel better by asking first. Please yell (politely ;-) if you don't
like the idea.
-Bertrand
[1] http://wiki.apache.org/cocoon/YourCocoonBasedProjectAnt16
[2] http://www.cocoongt.org/speakers/bertrand.html
Re: Bricks example app in our whiteboard, WDYT?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 20 sept. 05, à 10:14, Sylvain Wallez a écrit :
> Upayavira wrote:
>> So, you get my vote for putting it into the whiteboard.
>
> +1 also. I'm frequently asked about the recommended practices or
> design patterns for a Cocoon application. So starting to have some
> sample standalone applications in our SVN is a good thing...
Thanks guys for your support!
I've just committed a first skeleton at
whiteboard/example-apps/bricks-cms. It's not much worth looking at it
yet, I'll work on it in the next few days (I have to - the GT papers
have to be ready by Monday ;-)
People shouldn't worry about the CMS bit, this won't be competition to
the established Cocoon-based CMSes, but a toy CMS makes a good example
of where Cocoon shines.
-Bertrand
Re: Bricks example app in our whiteboard, WDYT?
Posted by Upayavira <uv...@odoko.co.uk>.
Sylvain Wallez wrote:
> Upayavira wrote:
>
>>
>> So, you get my vote for putting it into the whiteboard.
>
>
>
> +1 also. I'm frequently asked about the recommended practices or design
> patterns for a Cocoon application. So starting to have some sample
> standalone applications in our SVN is a good thing.
IMO not just a good thing - a necessary thing for Cocoon's future
ecosystem. We need to start having more stuff available that is built
upon Cocoon, smaller scale 'components', and examples for people to use
for learning purposes. It really needs to be the next stage in our
development, to give people higher-level components they can re-use in
their own systems.
Regards, Upayavira
Re: Bricks example app in our whiteboard, WDYT?
Posted by Sylvain Wallez <sy...@apache.org>.
Upayavira wrote:
>
> So, you get my vote for putting it into the whiteboard.
+1 also. I'm frequently asked about the recommended practices or design
patterns for a Cocoon application. So starting to have some sample
standalone applications in our SVN is a good thing.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Bricks example app in our whiteboard, WDYT?
Posted by Upayavira <uv...@odoko.co.uk>.
Bertrand Delacretaz wrote:
> Le 19 sept. 05, à 12:07, Bertrand Delacretaz a écrit :
>
>> ...Yes, but in fact I have maybe jumped to conclusions in thinking
>> that Hivemind depends on code that we couldn't redistribute. It might
>> be that they just use the ibiblio downloads for convenience, I'll
>> have to check this...
>
>
> Looks like what Hivemind uses is indeed ASL-compatible, this is the
> text of the hivemind build time warning:
>
> "Dependent libraries will be downloaded. These are NOT necessarily
> downloaded from apache.org,and may use other licences besides the
> Apache Software License. Dependencies will use an open-source license
> compatible with the ASL, such as Berkeley Software Distribution (BSD)
> or Mozilla Public License (MPL). "
>
> My confusion about javassist was based on [1] which says that it is
> LGPL, but [2] says that it's MPL/LGPL dual-licensed, and inside the
> download from [3] there's a License.html file which is MPL.
>
> To build and run, my example app only needs the hivemind and javassist
> jars (along with some jakarta stuff).
>
> So, it looks like all is well - sorry for the noise about this license
> stuff.
Thanks for checking. Good to hear it was simpler than it sounded.
So, you get my vote for putting it into the whiteboard.
Regards, Upayavira
Re: Bricks example app in our whiteboard, WDYT?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 19 sept. 05, à 12:07, Bertrand Delacretaz a écrit :
> ...Yes, but in fact I have maybe jumped to conclusions in thinking
> that Hivemind depends on code that we couldn't redistribute. It might
> be that they just use the ibiblio downloads for convenience, I'll have
> to check this...
Looks like what Hivemind uses is indeed ASL-compatible, this is the
text of the hivemind build time warning:
"Dependent libraries will be downloaded. These are NOT necessarily
downloaded from apache.org,and may use other licences besides the
Apache Software License. Dependencies will use an open-source license
compatible with the ASL, such as Berkeley Software Distribution (BSD)
or Mozilla Public License (MPL). "
My confusion about javassist was based on [1] which says that it is
LGPL, but [2] says that it's MPL/LGPL dual-licensed, and inside the
download from [3] there's a License.html file which is MPL.
To build and run, my example app only needs the hivemind and javassist
jars (along with some jakarta stuff).
So, it looks like all is well - sorry for the noise about this license
stuff.
-Bertrand
[1]http://www.jboss.org/products/list/downloads#javassist
[2] http://www.jboss.org/products/javassist
[3]
https://sourceforge.net/project/showfiles.php?
group_id=22866&package_id=80766&release_id=354770
Re: Bricks example app in our whiteboard, WDYT?
Posted by Upayavira <uv...@odoko.co.uk>.
Bertrand Delacretaz wrote:
> Le 19 sept. 05, à 11:47, Upayavira a écrit :
>
>> Bertrand Delacretaz wrote:
>>
>>> ...That's what I mean by "semi-automatic", people have to explicitely
>>> agree before the download proceeds.
>>
>>
>> I find that surprising - given the current ambiguity with 'linking' to
>> code in Java, there is a danger that you taint yourself simply by
>> having import statements in your code.
>>
>> In that case, a build time disclaimer doesn't help you at all...
>
>
>> Secondly, using this technique makes something of a farce of the ASL,
>> IMO. If your ASL licenced code won't work at all without some
>> incompatibly licenced code, how can you _honestly_ argue that your
>> code is ASL licensed?...
>
>
> I see what you mean - it is indeed weird.
>
>> ...But, this is something that I should, if I feel so inclined, take
>> up with the HiveMind folks, not yourself, as, if they resolved their
>> issue, yours would be resolved too...
>
>
> Yes, but in fact I have maybe jumped to conclusions in thinking that
> Hivemind depends on code that we couldn't redistribute. It might be that
> they just use the ibiblio downloads for convenience, I'll have to check
> this.
I suspect you are right - they wouldn't have graduated from incubator
otherwise. I look forward to hearing what you find out.
>>> ...Sure, hence my intention to mimick what hivemind does and not put
>>> the libraries that it requires in SVN.
>>
>>
>> But we'd be putting code that 'links' to it, which is just as
>> dangerous (at least until the board makes any statements to the
>> contrary)...
>
>
> Ok, I'll make sure the code that I put in the whiteboard doesn't contain
> import statements for non-ASF stuff.
>
> If there's a problem inside Hivemind (but I have no reason to think
> there is one), it won't be "imported" in our SVN. The Hivemind jars
> themselves are on ibiblio, so I can get them there as well.
well...
That would just push the problem one level deeper for the user of your
code, but it would still be there!
Let's see what you find out from HiveMind - this will probably turn out
to be a huge red-herring [1]
Regards, Upayavira
[1] red herring - A distractor that draws attention away from the real
issue. (from http://csmp.ucop.edu/crlp/resources/glossary.html)
Re: Bricks example app in our whiteboard, WDYT?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 19 sept. 05, à 11:47, Upayavira a écrit :
> Bertrand Delacretaz wrote:
>> ...That's what I mean by "semi-automatic", people have to explicitely
>> agree before the download proceeds.
>
> I find that surprising - given the current ambiguity with 'linking' to
> code in Java, there is a danger that you taint yourself simply by
> having import statements in your code.
>
> In that case, a build time disclaimer doesn't help you at all...
> Secondly, using this technique makes something of a farce of the ASL,
> IMO. If your ASL licenced code won't work at all without some
> incompatibly licenced code, how can you _honestly_ argue that your
> code is ASL licensed?...
I see what you mean - it is indeed weird.
> ...But, this is something that I should, if I feel so inclined, take
> up with the HiveMind folks, not yourself, as, if they resolved their
> issue, yours would be resolved too...
Yes, but in fact I have maybe jumped to conclusions in thinking that
Hivemind depends on code that we couldn't redistribute. It might be
that they just use the ibiblio downloads for convenience, I'll have to
check this.
>> ...Sure, hence my intention to mimick what hivemind does and not put
>> the libraries that it requires in SVN.
>
> But we'd be putting code that 'links' to it, which is just as
> dangerous (at least until the board makes any statements to the
> contrary)...
Ok, I'll make sure the code that I put in the whiteboard doesn't
contain import statements for non-ASF stuff.
If there's a problem inside Hivemind (but I have no reason to think
there is one), it won't be "imported" in our SVN. The Hivemind jars
themselves are on ibiblio, so I can get them there as well.
-Bertrand
Re: Bricks example app in our whiteboard, WDYT?
Posted by Upayavira <uv...@odoko.co.uk>.
Bertrand Delacretaz wrote:
> Le 19 sept. 05, à 11:27, Upayavira a écrit :
>
>> Bertrand Delacretaz wrote:
>>
>>> ...The app uses all ASF components: Hivemind, OJB and Derby, so
>>> licenses are clean (some non-ASL things will be downloaded from
>>> ibiblio at build time, with an appropriate warning).
>>
>>
>> What non-ASL things?
>
>
> Those that hivemind requires, and which it downloads in the same way
> already.
>
> Actually I'm not even sure if any of these dependencies have licenses
> that we couldn't distribute, I was thinking about javassist but I just
> checked and it's MPL/LGPL dual-license
> (http://www.jboss.org/products/javassist).
>
> But I think I'm going to do as hivemind does and download these things
> at build time for convenience and to avoid any legal problems.
>
>> ...I don't believe we're yet in a position to supply software which
>> downloads non-ASF components from elsewhere...
>
>
> We have a few cases already (mail block for example) where users must
> download non-ASL stuff themselves, so what's the problem with making
> this semi-automatic, as long as we don't distribute these things ourselves?
>
> This is what hivemind does (http://jakarta.apache.org/hivemind/), but
> with a very prominent warning at build time: a disclaimer is displayed
> and the build only continues if you type the word "continue". That's
> what I mean by "semi-automatic", people have to explicitely agree before
> the download proceeds.
I find that surprising - given the current ambiguity with 'linking' to
code in Java, there is a danger that you taint yourself simply by having
import statements in your code.
In that case, a build time disclaimer doesn't help you at all.
Secondly, using this technique makes something of a farce of the ASL,
IMO. If your ASL licenced code won't work at all without some
incompatibly licenced code, how can you _honestly_ argue that your code
is ASL licensed?
But, this is something that I should, if I feel so inclined, take up
with the HiveMind folks, not yourself, as, if they resolved their issue,
yours would be resolved too.
> IMHO this is in line with our current policies, don't you think so?
:-) Actually, I don't!
>> ...Having said that, putting something into SVN isn't strictly
>> "releasing" software, but we do need to be aware of what we're putting
>> in....
> Sure, hence my intention to mimick what hivemind does and not put the
> libraries that it requires in SVN.
But we'd be putting code that 'links' to it, which is just as dangerous
(at least until the board makes any statements to the contrary).
>> ...I am keen to see stuff put onto the whiteboard - I'm curious to see
>> where it takes us from here...
>
> Thanks, so am I of course ;-)
I still stick by the above statement, even if I am being difficult in
relation to licencing!
Regards, Upayavira
Re: Bricks example app in our whiteboard, WDYT?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 19 sept. 05, à 11:27, Upayavira a écrit :
> Bertrand Delacretaz wrote:
>> ...The app uses all ASF components: Hivemind, OJB and Derby, so
>> licenses are clean (some non-ASL things will be downloaded from
>> ibiblio at build time, with an appropriate warning).
>
> What non-ASL things?
Those that hivemind requires, and which it downloads in the same way
already.
Actually I'm not even sure if any of these dependencies have licenses
that we couldn't distribute, I was thinking about javassist but I just
checked and it's MPL/LGPL dual-license
(http://www.jboss.org/products/javassist).
But I think I'm going to do as hivemind does and download these things
at build time for convenience and to avoid any legal problems.
> ...I don't believe we're yet in a position to supply software which
> downloads non-ASF components from elsewhere...
We have a few cases already (mail block for example) where users must
download non-ASL stuff themselves, so what's the problem with making
this semi-automatic, as long as we don't distribute these things
ourselves?
This is what hivemind does (http://jakarta.apache.org/hivemind/), but
with a very prominent warning at build time: a disclaimer is displayed
and the build only continues if you type the word "continue". That's
what I mean by "semi-automatic", people have to explicitely agree
before the download proceeds.
IMHO this is in line with our current policies, don't you think so?
> ...Having said that, putting something into SVN isn't strictly
> "releasing" software, but we do need to be aware of what we're putting
> in....
Sure, hence my intention to mimick what hivemind does and not put the
libraries that it requires in SVN.
> ...I am keen to see stuff put onto the whiteboard - I'm curious to see
> where it takes us from here...
Thanks, so am I of course ;-)
-Bertrand
Re: Bricks example app in our whiteboard, WDYT?
Posted by Upayavira <uv...@odoko.co.uk>.
Bertrand Delacretaz wrote:
> Hi community,
>
> I'm working on my "Bricks" example application for the GT [2] and I was
> thinking of putting the source code in our whiteboard, if people don't
> mind.
>
> I don't want to make it a block as it contains the full source code of a
> (very simple) standalone application built on Cocoon, including a build
> system based on [1], and it's important to show how independent from a
> particular version of Cocoon that can be.
>
> I guess this will be a one man show for now, and others might have
> different views of what an example app should be. So I'm not sure about
> where to host it, but no one objects I'd like to put it in our
> whiteboard for now.
>
> The app uses all ASF components: Hivemind, OJB and Derby, so licenses
> are clean (some non-ASL things will be downloaded from ibiblio at build
> time, with an appropriate warning).
What non-ASL things?
I don't believe we're yet in a position to supply software which
downloads non-ASF components from elsewhere. Having said that, putting
something into SVN isn't strictly "releasing" software, but we do need
to be aware of what we're putting in.
> I know we don't have a precise policy for using the whiteboard, but I
> feel better by asking first. Please yell (politely ;-) if you don't like
> the idea.
I've always thought we need to be broadening out beyond the core Cocoon,
and our current blocks system has become decidedly cumbersome for new
stuff like this. So I am keen to see stuff put onto the whiteboard - I'm
curious to see where it takes us from here.
Regards, Upayavira