You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Rick Hillegas <ri...@oracle.com> on 2010/11/15 17:26:14 UTC
Eclipse ui plugin for 10.7.1.0
I need a volunteer to build the Eclipse ui plugin for Derby 10.7.1.0.
Thanks,
-Rick
Re: Eclipse ui plugin for 10.7.1.0
Posted by Rick Hillegas <ri...@oracle.com>.
Myrna van Lunteren wrote:
> On Mon, Nov 15, 2010 at 1:42 PM, Kathey Marsden
> <km...@sbcglobal.net> wrote:
>
>> On 11/15/2010 1:31 PM, Myrna van Lunteren wrote:
>>
>>>> If this artifact doesn't change much, would it make sense to check it
>>>> into
>>>> the Derby codeline?
>>>>
>> I don't have a hard time with just copying the ui plugin over between
>> maintenance releases, and I don't want to make work for anyone, but since I
>> think it has an external build dependency on Eclipse, it seems like it
>> would make sense to make sure it still builds periodically and releases off
>> the trunk seem like a good time to do that. Alternately, there could be
>> some other schedule. If we do use the old binary, the version shouldn't
>> change.
>>
>> Just an opinion though, not a really strong one.
>>
>> Kathey
>>
>>
> Actually, the version of the ui/doc plugin is independent and thus has
> a different number from the apache derby release. So, it doesn't
> change, and shouldn't unless the source of the plugin(s) changes.
> The core plugin includes derby.jar, derbyclient.jar, derbynet.jar and
> derbytools.jar, and so needs to, and does, match the derby release.
>
> Myrna
>
>
Thanks for the discussion, Myrna and Kathey. I won't check in the built
artifact, then. I'll just give the master ant script a variable which
can be pointed at a local copy of the ui/doc zip. That will satisfy my
need to generate and sign all artifacts at once.
Thanks,
-Rick
Re: Eclipse ui plugin for 10.7.1.0
Posted by Myrna van Lunteren <m....@gmail.com>.
On Mon, Nov 15, 2010 at 1:42 PM, Kathey Marsden
<km...@sbcglobal.net> wrote:
> On 11/15/2010 1:31 PM, Myrna van Lunteren wrote:
>>
>>> If this artifact doesn't change much, would it make sense to check it
>>> into
>>> the Derby codeline?
>
> I don't have a hard time with just copying the ui plugin over between
> maintenance releases, and I don't want to make work for anyone, but since I
> think it has an external build dependency on Eclipse, it seems like it
> would make sense to make sure it still builds periodically and releases off
> the trunk seem like a good time to do that. Alternately, there could be
> some other schedule. If we do use the old binary, the version shouldn't
> change.
>
> Just an opinion though, not a really strong one.
>
> Kathey
>
Actually, the version of the ui/doc plugin is independent and thus has
a different number from the apache derby release. So, it doesn't
change, and shouldn't unless the source of the plugin(s) changes.
The core plugin includes derby.jar, derbyclient.jar, derbynet.jar and
derbytools.jar, and so needs to, and does, match the derby release.
Myrna
Re: Eclipse ui plugin for 10.7.1.0
Posted by Kathey Marsden <km...@sbcglobal.net>.
On 11/15/2010 1:31 PM, Myrna van Lunteren wrote:
>
>> If this artifact doesn't change much, would it make sense to check it into
>> the Derby codeline?
I don't have a hard time with just copying the ui plugin over between
maintenance releases, and I don't want to make work for anyone, but
since I think it has an external build dependency on Eclipse, it
seems like it would make sense to make sure it still builds periodically
and releases off the trunk seem like a good time to do that.
Alternately, there could be some other schedule. If we do use the old
binary, the version shouldn't change.
Just an opinion though, not a really strong one.
Kathey
Re: Eclipse ui plugin for 10.7.1.0
Posted by Myrna van Lunteren <m....@gmail.com>.
On Mon, Nov 15, 2010 at 10:40 AM, Rick Hillegas
<ri...@oracle.com> wrote:
> Myrna van Lunteren wrote:
>>
>> On Mon, Nov 15, 2010 at 8:26 AM, Rick Hillegas <ri...@oracle.com>
>> wrote:
>>
>>>
>>> I need a volunteer to build the Eclipse ui plugin for Derby 10.7.1.0.
>>>
>>> Thanks,
>>> -Rick
>>>
>>>
>>
>> I've been thinking about this - knew it was coming, of course.
>>
>> But neither the ui nor doc plugin source has changed in more than 2
>> years, so there really is no need to make a new plugin - it's just
>> going to be the same as the older one (except the files will have a
>> newer date...).
>> The *core* plugin is what has the derby jars in it, and thus needs to
>> be build for each release, and you took care of that.
>>
>> I propose that I will test the old ui/doc plugin with the new core
>> plugin, and if it works fine, we can just change the name of the zip
>> file, and then you sign it, of course, to give a stamp of approval for
>> 10.7.
>>
>
> Thanks, Myrna. This sounds like a great plan.
>
> If this artifact doesn't change much, would it make sense to check it into
> the Derby codeline? Then the release manager would just pick up the
> checked-in version when building a release. The release manager would just
> assume that Eclipse enthusiasts in the community had kept the checked-in
> version evergreen. I don't think there should be any licensing problems
> here, for the following reasons:
>
> o I cracked open this artifact. It already claims to be licensed under
> Apache v2.0. Individual pieces of text-based content in the artifact also
> have the Apache copyright header.
>
> o The remaining bits seem to be executable code. I assume that code was
> produced from some combination of Derby and Eclipse sources. According to
> this web page, the Apache license is compatible with compiled forms of code
> if the source itself was open-sourced under EPL, the Eclipse license:
> http://www.apache.org/legal/resolved.html#category-b
>
> Does this sound like a good approach for the future?
>
> Thanks,
> -Rick
>>
>> Let me know if you still want a new zip file, I volunteer to make one
>> if you want.
>>
>> Myrna
>>
>>
>
>
Well...The source for the ui and doc plugins is what lives in
(trunk/branch)/plugins/eclipse/org.apache.*... It's completely
contributed to the derby project, (see e.g. revision 178020) and thus
completely under Apache license.
It follows an (old?) eclipse API for plugins, so, it imports and
extends eclipse classes - similarly to how our junit framework imports
and extends junit classes. There is *no* eclipse source at all.
The code is not likely to change as the original contributors (Susan
and Rajesh) have not contributed to derby for a long time and short of
fixing glaring/horrible reproducible troubles (preferably if someone
else suggests a solution) I don't intend to do much myself.
So..sure, we could check in the ui/doc plugin zipfile somewhere...I
thought it was easy enough to access it from the saved location of the
older distributions, but I imagine it's easier to automate the signing
if the zip file lives also somewhere in the tree...
Myrna
Re: Eclipse ui plugin for 10.7.1.0
Posted by Rick Hillegas <ri...@oracle.com>.
Myrna van Lunteren wrote:
> On Mon, Nov 15, 2010 at 8:26 AM, Rick Hillegas <ri...@oracle.com> wrote:
>
>> I need a volunteer to build the Eclipse ui plugin for Derby 10.7.1.0.
>>
>> Thanks,
>> -Rick
>>
>>
> I've been thinking about this - knew it was coming, of course.
>
> But neither the ui nor doc plugin source has changed in more than 2
> years, so there really is no need to make a new plugin - it's just
> going to be the same as the older one (except the files will have a
> newer date...).
> The *core* plugin is what has the derby jars in it, and thus needs to
> be build for each release, and you took care of that.
>
> I propose that I will test the old ui/doc plugin with the new core
> plugin, and if it works fine, we can just change the name of the zip
> file, and then you sign it, of course, to give a stamp of approval for
> 10.7.
>
Thanks, Myrna. This sounds like a great plan.
If this artifact doesn't change much, would it make sense to check it
into the Derby codeline? Then the release manager would just pick up the
checked-in version when building a release. The release manager would
just assume that Eclipse enthusiasts in the community had kept the
checked-in version evergreen. I don't think there should be any
licensing problems here, for the following reasons:
o I cracked open this artifact. It already claims to be licensed under
Apache v2.0. Individual pieces of text-based content in the artifact
also have the Apache copyright header.
o The remaining bits seem to be executable code. I assume that code was
produced from some combination of Derby and Eclipse sources. According
to this web page, the Apache license is compatible with compiled forms
of code if the source itself was open-sourced under EPL, the Eclipse
license: http://www.apache.org/legal/resolved.html#category-b
Does this sound like a good approach for the future?
Thanks,
-Rick
> Let me know if you still want a new zip file, I volunteer to make one
> if you want.
>
> Myrna
>
>
Re: Eclipse ui plugin for 10.7.1.0
Posted by Myrna van Lunteren <m....@gmail.com>.
On Mon, Nov 15, 2010 at 8:26 AM, Rick Hillegas <ri...@oracle.com> wrote:
> I need a volunteer to build the Eclipse ui plugin for Derby 10.7.1.0.
>
> Thanks,
> -Rick
>
I've been thinking about this - knew it was coming, of course.
But neither the ui nor doc plugin source has changed in more than 2
years, so there really is no need to make a new plugin - it's just
going to be the same as the older one (except the files will have a
newer date...).
The *core* plugin is what has the derby jars in it, and thus needs to
be build for each release, and you took care of that.
I propose that I will test the old ui/doc plugin with the new core
plugin, and if it works fine, we can just change the name of the zip
file, and then you sign it, of course, to give a stamp of approval for
10.7.
Let me know if you still want a new zip file, I volunteer to make one
if you want.
Myrna