You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Adrian Wiesmann <aw...@somap.org> on 2007/04/07 20:33:46 UTC
Taking over development of DataViews
Hello
I have a few questions and notes about the DataViews which I would like to
ask and share.
We from SOMAP.org are using DataViews since quite some time and since we
are developing a Swing based application, DataViews really are a time
saver for us. Because of the general focus of the Cayenne project relating
to DataViews, we now decided to take over (or fork) the DataViews.
This was no easy decision for I don't want to anger anybody from the
Cayenne project and on the other hand this means that we will have to make
releases and everything on our own which "distracts" us from our main
application. But IMHO this is the best solution at the moment.
Said that, there are still a few questions open on which I would like to
hear your answers and comments:
- I am no big fan of forks. So if there is some solution in which we do
not fork the DataViews but officially take over the maintenance off-site
or something, I would prefer that. This would also mean we would stay with
the name and don't change it to something else.
- Our SOBF Tool is released under the GPL. I would welcome if we could
change licence for the source code of the DataViews that is already there,
or find some way to dual licence the current version of the DataViews
(Apache Licence and LGPL?). Or perhaps there is another solution. This is
only a question of making our lives easier than of removing anyones
copyright or something.
- We planned to integrate the DataViews into our own project on
SourceForge. But if there are other developers, I think we should start a
new project on SourceForge. But I won't start another project if we from
SOMAP.org are the only ones working on the DataViews. So please raise your
hand if you are interested in helping in the development.
Thats about it. I am looking forward to your answers.
Regards,
Adrian
Re: Taking over development of DataViews
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Apr 7, 2007, at 2:33 PM, Adrian Wiesmann wrote:
> - I am no big fan of forks. So if there is some solution in which
> we do
> not fork the DataViews but officially take over the maintenance off-
> site
> or something, I would prefer that. This would also mean we would
> stay with
> the name and don't change it to something else.
There is definitely a process for doing this within Apache. ASF is a
volunteer organization after all, and commit karma is granted for (a)
code contributions and (b) the ability and desire to work with the
community.
We would definitely welcome your effort at Cayenne. The way it works
- initially you start by submitting patches via Jira, and of the
committers would review and apply them. Once everybody is comfortable
with how this goes, we will vote and grant you committer status,
removing the last obstacle for you doing this work.
> - Our SOBF Tool is released under the GPL. I would welcome if we could
> change licence for the source code of the DataViews that is already
> there,
> or find some way to dual licence the current version of the DataViews
> (Apache Licence and LGPL?). Or perhaps there is another solution.
> This is
> only a question of making our lives easier than of removing anyones
> copyright or something.
I can't advise you on your options if you fork, but if you continue
doing work under the ASF roof, ASF license will definitely be a
requirement. Wouldn't you still be able to use it in a GPL project? I
don't know the answer to that. HTTPD runs on Linux somehow :-)
Andrus
Re: Taking over development of DataViews
Posted by Ahmed Mohombe <am...@yahoo.com>.
> Per recent discussion on Apache Legal list...
There's a nice illustration of OS licenses:
http://blogs.sun.com/chandan/entry/copyrights_licenses_and_cddl_illustrated
It would be nice if Apache would be also there :).
It also explains the "header problem with GPL" :).
Ahmed.
Re: Taking over development of DataViews
Posted by Andrus Adamchik <an...@objectstyle.org>.
I finally split the DataViews in a separate project:
https://svn.apache.org/repos/asf/cayenne/dataviews/trunk/
https://svn.apache.org/repos/asf/cayenne/dataviews/trunk/README.txt
There are two modules - dataview and dvmodeler. README.txt file above
has instructions on how to build them. Also I used JApplication Maven
plugin to assemble cross-platform runnable DVModeler, just like we do
for CayenneModeler. Everything looks nice and clean, waiting for
somebody to take it over ;-)
Andrus
On Apr 15, 2007, at 6:38 PM, Andrus Adamchik wrote:
> Hi Adrian,
>
> Sometimes it is good for everyone just to let it go. Nobody so far
> volunteered to support "Cayenne DataViews", and from this
> discussion it is clear that you sending us contributions doesn't
> fundamentally change this situation.
>
> I'd like to wish you good luck with your project extending
> DataViews. Also I hope that you set it up in a place like
> SourceForge or similar so that current small (although existing)
> DataViews user group could take advantage of your work. That is up
> to you of course. If at some point you consider coming to ASF with
> this code and the intent to develop it under Apache roof, you'll
> definitely be welcomed (although the project will have to go
> through the Incubator in that case).
>
> I'll be happy to see this technology thrive in whatever open source
> form :-)
>
> Good luck
> Andrus
>
>
>
> On Apr 14, 2007, at 12:18 AM, Adrian Wiesmann wrote:
>> Hello Andrus
>>
>> First of all, I can see your viewpoint and your concerns and I
>> respect
>> them. I would probably have the same in your position. Let me tell
>> you
>> that we now decided to create a separate library for the dataviews
>> and
>> leave the licence as it is. We plan to send all our changes back
>> to the
>> Cayenne project as diffs. It is then the Cayenne projects decision
>> if you
>> add our changes to the original or not.
>>
>>
>>> I still have concerns about the code being forked, and then the
>>> diffs
>>> contributed back. As a practical matter, you will be using your
>>> version of code, so no testing of 'Cayenne DataViews' will occur,
>>> leaving the framework in an indeterminate state.
>>
>> Let me say two things here (and I still am not intending to stand on
>> anyones toes, although I may sound direct):
>>
>> First, the DataViews are not actively developed nor maintained at the
>> moment. So speaking of a fork is probably wrong. We just take over
>> the
>> development in a different environment.
>>
>> And second, we don't see our copy as the official version but as
>> work in
>> progress. We create a copy so that we can move forward in our own
>> pace. If
>> somebody is interested to get a copy, fine with us. But we will not
>> advertise our version.
>>
>>
>>> Also after the
>>> initial period of trust-building, I am sure you'll be able to
>>> develop
>>> at your own pace, and there will be more of a community oversight,
>>> rather than interference with the development process.
>>
>> I am sorry, but sending in our changes and then waiting for a new
>> build is
>> currently not an option. We have very limited resources and when
>> one of us
>> has time to develop, we need to move forward.
>>
>> We will see how our approach evolves. We currently need a tool
>> where we
>> can manage our development and changes and I don't expect commit
>> access in
>> your SVN. So look at it as if we would work on something like
>> Debian. Our
>> repository contains the unstable or testing version, the Cayenne
>> repository will contain the stable source for the new dataview
>> library.
>>
>> So if you agree in this, then please extract everything DataView
>> from the
>> bleeding edge of Cayenne. We will then start from your newly created
>> DataView library. Otherwise we will extract the source on our own and
>> start the development with a new namespace to not run into conflicts.
>>
>> Regards,
>> Adrian
>>
>
>
Re: Taking over development of DataViews
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hi Adrian,
Sometimes it is good for everyone just to let it go. Nobody so far
volunteered to support "Cayenne DataViews", and from this discussion
it is clear that you sending us contributions doesn't fundamentally
change this situation.
I'd like to wish you good luck with your project extending DataViews.
Also I hope that you set it up in a place like SourceForge or similar
so that current small (although existing) DataViews user group could
take advantage of your work. That is up to you of course. If at some
point you consider coming to ASF with this code and the intent to
develop it under Apache roof, you'll definitely be welcomed (although
the project will have to go through the Incubator in that case).
I'll be happy to see this technology thrive in whatever open source
form :-)
Good luck
Andrus
On Apr 14, 2007, at 12:18 AM, Adrian Wiesmann wrote:
> Hello Andrus
>
> First of all, I can see your viewpoint and your concerns and I respect
> them. I would probably have the same in your position. Let me tell you
> that we now decided to create a separate library for the dataviews and
> leave the licence as it is. We plan to send all our changes back to
> the
> Cayenne project as diffs. It is then the Cayenne projects decision
> if you
> add our changes to the original or not.
>
>
>> I still have concerns about the code being forked, and then the diffs
>> contributed back. As a practical matter, you will be using your
>> version of code, so no testing of 'Cayenne DataViews' will occur,
>> leaving the framework in an indeterminate state.
>
> Let me say two things here (and I still am not intending to stand on
> anyones toes, although I may sound direct):
>
> First, the DataViews are not actively developed nor maintained at the
> moment. So speaking of a fork is probably wrong. We just take over the
> development in a different environment.
>
> And second, we don't see our copy as the official version but as
> work in
> progress. We create a copy so that we can move forward in our own
> pace. If
> somebody is interested to get a copy, fine with us. But we will not
> advertise our version.
>
>
>> Also after the
>> initial period of trust-building, I am sure you'll be able to develop
>> at your own pace, and there will be more of a community oversight,
>> rather than interference with the development process.
>
> I am sorry, but sending in our changes and then waiting for a new
> build is
> currently not an option. We have very limited resources and when
> one of us
> has time to develop, we need to move forward.
>
> We will see how our approach evolves. We currently need a tool
> where we
> can manage our development and changes and I don't expect commit
> access in
> your SVN. So look at it as if we would work on something like
> Debian. Our
> repository contains the unstable or testing version, the Cayenne
> repository will contain the stable source for the new dataview
> library.
>
> So if you agree in this, then please extract everything DataView
> from the
> bleeding edge of Cayenne. We will then start from your newly created
> DataView library. Otherwise we will extract the source on our own and
> start the development with a new namespace to not run into conflicts.
>
> Regards,
> Adrian
>
Re: Taking over development of DataViews
Posted by Adrian Wiesmann <aw...@somap.org>.
Hello Andrus
First of all, I can see your viewpoint and your concerns and I respect
them. I would probably have the same in your position. Let me tell you
that we now decided to create a separate library for the dataviews and
leave the licence as it is. We plan to send all our changes back to the
Cayenne project as diffs. It is then the Cayenne projects decision if you
add our changes to the original or not.
> I still have concerns about the code being forked, and then the diffs
> contributed back. As a practical matter, you will be using your
> version of code, so no testing of 'Cayenne DataViews' will occur,
> leaving the framework in an indeterminate state.
Let me say two things here (and I still am not intending to stand on
anyones toes, although I may sound direct):
First, the DataViews are not actively developed nor maintained at the
moment. So speaking of a fork is probably wrong. We just take over the
development in a different environment.
And second, we don't see our copy as the official version but as work in
progress. We create a copy so that we can move forward in our own pace. If
somebody is interested to get a copy, fine with us. But we will not
advertise our version.
> Also after the
> initial period of trust-building, I am sure you'll be able to develop
> at your own pace, and there will be more of a community oversight,
> rather than interference with the development process.
I am sorry, but sending in our changes and then waiting for a new build is
currently not an option. We have very limited resources and when one of us
has time to develop, we need to move forward.
We will see how our approach evolves. We currently need a tool where we
can manage our development and changes and I don't expect commit access in
your SVN. So look at it as if we would work on something like Debian. Our
repository contains the unstable or testing version, the Cayenne
repository will contain the stable source for the new dataview library.
So if you agree in this, then please extract everything DataView from the
bleeding edge of Cayenne. We will then start from your newly created
DataView library. Otherwise we will extract the source on our own and
start the development with a new namespace to not run into conflicts.
Regards,
Adrian
Re: Taking over development of DataViews
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Apr 12, 2007, at 7:22 PM, Adrian Wiesmann wrote:
>> We can and should make it a standalone module within Cayenne. This
>> means a standalone Eclipse project, separate from the rest of the
>> framework.
>
> OK, let's make nails with heads (as we say over here). Please make
> this
> split on the Cayenne side. I can then get that new project via SVN.
> Afterwards I will upload the source into our own SVN (and keep
> everything
> under the ASL) and will work on that version. I will do the same
> with the
> dvmodeler.
>
> We can then send patches back to Cayenne relatively easy making a diff
> between the two repositories. Is this OK with you?
Splitting can be done. Not that I have tons of time to do it quickly,
but we can.
I still have concerns about the code being forked, and then the diffs
contributed back. As a practical matter, you will be using your
version of code, so no testing of 'Cayenne DataViews' will occur,
leaving the framework in an indeterminate state.
So would it be possible to make "Cayenne DataViews" the primary
source, with no second SVN, and do the auto-relicensing to ASF/GPL
with a script? Is this bad for any reason?
Of course you'd have to go through the community for all
contributions; but that would be the case even if you submit
patches ... only happen in a different sequence. Also after the
initial period of trust-building, I am sure you'll be able to develop
at your own pace, and there will be more of a community oversight,
rather than interference with the development process.
Andrus
Re: Taking over development of DataViews
Posted by Adrian Wiesmann <aw...@somap.org>.
> We can and should make it a standalone module within Cayenne. This
> means a standalone Eclipse project, separate from the rest of the
> framework.
OK, let's make nails with heads (as we say over here). Please make this
split on the Cayenne side. I can then get that new project via SVN.
Afterwards I will upload the source into our own SVN (and keep everything
under the ASL) and will work on that version. I will do the same with the
dvmodeler.
We can then send patches back to Cayenne relatively easy making a diff
between the two repositories. Is this OK with you?
> More complicated, because you have to install
> those dependencies in the local repo after each change.
Argh.
Regards,
Adrian
Re: Taking over development of DataViews
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Apr 12, 2007, at 6:29 PM, Adrian Wiesmann wrote:
> The legaly easiest solution would be to just extract the DataView from
> Cayenne and create a new lib licenced under the ASL.
We can and should make it a standalone module within Cayenne. This
means a standalone Eclipse project, separate from the rest of the
framework.
> But this is a hassle for the development process which I would
> welcome to not have. Except
> there is some trick to tell Eclipse to handle two separate projects
> as one
> (debugging and compiling).
In fact it is fairly easy to develop two projects in the same
workspace. Adding the M-word to the mix (ok, that's Maven :-)), makes
it both more simple and more complicated. Simple, cause if you have
your dependencies with sources in a local repo, you don't have to
open them in Eclipse. More complicated, because you have to install
those dependencies in the local repo after each change.
> Just a quick question. Is the DataView still in the 3.0 bleeding edge
> build? If so, we have to change the namespace anyway and there
> would be no
> gain in making a new library.
Yes they are (but not the DVModeler). Again, my preference would be
to split that code in a separate module under Cayenne.
Andrus
Re: Taking over development of DataViews
Posted by Adrian Wiesmann <aw...@somap.org>.
Andrus
> Per recent discussion on Apache Legal list [2], it is NOT OK to take
> Apache code and strip the license headers from it and relicense them
> as GPL.
That was not the plan. We would keep the licence an notices on all files
and just put these files directly into our own project. So our project
would contain ASL and GPL code. I thought that if both projects agree this
should not be of a problem. But I agree this solution is not perfect in a
legal view.
The technicaly easiest solution would be if Cayenne agrees in our project
taking exlusively (and only for our SOBF Tool) the data view source code
(and dvmodeler) and relicence it under the GPL. With the condition that we
dual-licence everything we do on the DataViews under the ASL. Like that we
could integrate everything without the need to have a separate lib.
The legaly easiest solution would be to just extract the DataView from
Cayenne and create a new lib licenced under the ASL. But this is a hassle
for the development process which I would welcome to not have. Except
there is some trick to tell Eclipse to handle two separate projects as one
(debugging and compiling).
But I guess we have to go this second way :(
Do the licence requirements concerning the written CLA apply when
submitting back to Cayenne or before? And only if we don't fork?
> So - is there any way you can continue using Apache-licensed
> DataViews (as a library dependency or something? I am not a big
> expert on GPL limitations)? This should be easier from the technical
> POV as well, as you won't need to fork and resubmit patches to keep
> Cayenne in sync.
Just a quick question. Is the DataView still in the 3.0 bleeding edge
build? If so, we have to change the namespace anyway and there would be no
gain in making a new library.
> The GPL/Apache
> license incompatibility hurts everybody, but that's how things are
> until ASF and FSF work it out :-(
I never thought I'd say this. But this licencing stuff turns out to be
royal PITA.
Regards,
Adrian
Re: Taking over development of DataViews
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Apr 12, 2007, at 3:03 PM, Adrian Wiesmann wrote:
> My problem is less in dual licencing our changes than in
> integrating the
> DataViews (which is Apache licence) into our own tool (which is
> GPL). But
> as far as I see nobody from Cayenne has a problem with us doing so and
> therefor I suggest that we integrate the DataView code into our own
> project (because this is easier for us to work on them) and when
> merging
> our changes with Cayenne we licence our changes under the Apache
> licence.
Adrian,
It would be very nice if we can get this going, but let's see if we
have all possible pitfalls covered.
There will be a one-time formality - all developers who will be
working on the code will need to send the CLA forms [1] to the ASF,
and also if the development is financed by your company, the company
will need to send a corporate CLA (also [1]). I don't expect this to
be a showstopper, but we need to discuss the following item.
Per recent discussion on Apache Legal list [2], it is NOT OK to take
Apache code and strip the license headers from it and relicense them
as GPL. Same goes for old ObjectStyle releases of DataViews (as
ObjectStyle license was an Apache license clone). The GPL/Apache
license incompatibility hurts everybody, but that's how things are
until ASF and FSF work it out :-(
So - is there any way you can continue using Apache-licensed
DataViews (as a library dependency or something? I am not a big
expert on GPL limitations)? This should be easier from the technical
POV as well, as you won't need to fork and resubmit patches to keep
Cayenne in sync.
Thanks
Andrus
[1] http://apache.org/licenses/
[2] http://tinyurl.com/2n8ft7
Re: Taking over development of DataViews
Posted by Adrian Wiesmann <aw...@somap.org>.
> You could still do your work in your own svn
> repository until you were ready to merge it if that was easiest for you.
I guess this is the best way. We copy the current status of DataViews into
our own project and feed changes back to Cayenne. There are still some
technical questions concerning how we should integrate the DataView part
of Cayenne into our own project, but the goal is it to keep things as they
are and to stay as "compliant" as possible so that we can feed back our
changes into Cayenne.
> Although I haven't looked
> deeply into DataViews, they appear to offer some of the same promise
> as this approach - in fact to me they look slightly like a GUI for
> creating SQLtemplates.
I see them as an easy way to "paint" a list/table form or edit form during
design time which is interpreted at runtime by the application. So I don't
have to look after the data binding, after basic validation checks,
paging, adding new records etc. The layout is defined by the dataview and
is then interpreted by whatever renderer I prefer.
> If you add GPL/LGPL code to an existing Apache licensed code base,
> then anything you release will be usable only under the more
> restrictive GPL/LGPL license. This means it cannot be merged back
> into Cayenne. If possible, I think the prospect of merging your
> improvements back to Cayenne would be a useful one.
My problem is less in dual licencing our changes than in integrating the
DataViews (which is Apache licence) into our own tool (which is GPL). But
as far as I see nobody from Cayenne has a problem with us doing so and
therefor I suggest that we integrate the DataView code into our own
project (because this is easier for us to work on them) and when merging
our changes with Cayenne we licence our changes under the Apache licence.
We will probably have to change some namespaces, but that can be scripted
and is IMHO no big problem when merging back.
> What would be interesting is if you could clarify what your goals are
> for DataViews. Is it just to get them working against against Cayenne
> 3.0 or do you have some specific features you want to add?
DataViews run without any changes on 3.0. At least in the snapshot I got.
Our problem is that DataViews lack some functionality (no complete list
and we currently don't need everything from here):
- Edit form renderer (single record) instead of a list (table model). I
want to design a DataView and then have a renderer create a form for me.
Much in the way that I can add a DataView to a TableModel.
- Foreign key relation editing. I need a mechanism in which a user can
select a foreign record from a list to set as a foreign key on the current
row.
- Code field resolution. I need comboboxes with some human readable
representations of codes so that I can present those comboboxes to the
user instead of him having to enter a number or some cryptic value.
- Dynamic fields. Sometimes there is the need to have a field which can
only be used on one specific view. Probably some calculation which is
never stored on the database and therefor has no representation on the
DataObject.
- Foreign relations with a filter. Sometimes a list should show a field
from a foreign key relation. But there are multiple records via the
relation. It must then be possible to add a filter to a relation.
- Theoretically DataViews could be used for web development as well and I
wonder why this was not adopted before. A page could define which DataView
to use with what kind of DataSet and a renderer could then render this
specific webpage.
We already added some of those features to our snapshot of Cayenne. But
there is still much to be done and I am not sure if everybody would agree
with our changes. And we would like to regularly switch to a new build of
Cayenne 3.0 so that we stay current. Which means that we either have to go
completely proprietory with our changes or integrate the DataViews and
feed our changes back. I think everybody here agrees that the last
procedure is OK with Cayenne. So let's start :)
Regards,
Adrian
Re: Taking over development of DataViews
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 08/04/2007, at 4:33 AM, Adrian Wiesmann wrote:
> - I am no big fan of forks. So if there is some solution in which
> we do
> not fork the DataViews but officially take over the maintenance off-
> site
> or something, I would prefer that. This would also mean we would
> stay with
> the name and don't change it to something else.
I think that keeping your code integrated with Cayenne would be for
the best. It would make ongoing work easier, ensure that commits to
other parts of Cayenne take your work into account, integrate with
junit tests, tie in with Cayenne documentation and give your changes
the widest audience. You could still do your work in your own svn
repository until you were ready to merge it if that was easiest for you.
I certainly would not worry about stepping on anyone's toes.
DataViews aren't being worked on by anyone right now, and this work
would be a welcome addition to Cayenne. We develop a three tier Swing
application ourselves and were thinking about moving some parts of
the code to DataRows and SQLtemplate for enhanced speed (and
transferring less data across the network). Although I haven't looked
deeply into DataViews, they appear to offer some of the same promise
as this approach - in fact to me they look slightly like a GUI for
creating SQLtemplates.
> - Our SOBF Tool is released under the GPL. I would welcome if we could
> change licence for the source code of the DataViews that is already
> there,
> or find some way to dual licence the current version of the DataViews
> (Apache Licence and LGPL?). Or perhaps there is another solution.
> This is
> only a question of making our lives easier than of removing anyones
> copyright or something.
If you add GPL/LGPL code to an existing Apache licensed code base,
then anything you release will be usable only under the more
restrictive GPL/LGPL license. This means it cannot be merged back
into Cayenne. If possible, I think the prospect of merging your
improvements back to Cayenne would be a useful one.
> - We planned to integrate the DataViews into our own project on
> SourceForge. But if there are other developers, I think we should
> start a
> new project on SourceForge. But I won't start another project if we
> from
> SOMAP.org are the only ones working on the DataViews. So please
> raise your
> hand if you are interested in helping in the development.
What would be interesting is if you could clarify what your goals are
for DataViews. Is it just to get them working against against Cayenne
3.0 or do you have some specific features you want to add?
Ari Maniatis
-------------------------->
Aristedes Maniatis
phone +61 2 9660 9700
PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8