[ jEdit-devel ] Few thoughts on the new plugin release process, and an error.

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[ jEdit-devel ] Few thoughts on the new plugin release process, and an error.

Eric Berry
Administrator
Hi Jarek,
   First and foremost. I really appreciate all the work you've put into the new process. I'm having troubles setting it up locally, which I'll get to later, but first I have some thoughts on what you've done that I'd like to bring them up for conversation.

There are some things you do in the instructions found here that go against the conventions of the technologies we're using:
http://sourceforge.net/apps/mediawiki/jedit/index.php?title=Conventions,_procedures#Releasing_a_plugin_part_II

First, NONE of the commands will work out of the box. This is due to the build file being named "custom_build.xml". You need to tell Ant to use that file specifically, or rename the file to "build.xml".
Eg. All the commands look like this out of the box "ant -f custom_build.xml pf.foo".

Second, I understand what you were trying to do here, but asking people to download the source into a temp directory, then delete everything else is misleading and dangerous. A. This should be an export, not a checkout (more on this later), B. You're custom_build.xml script is just going to checkout the whole directory again for the user - I followed your instructions and when I saw it downloading the source again, I asked "Why, I just did that to get the custom_build.xml?".

Third, having the user modify the custom_build.xml file for each plugin is very anti-Ant, and very anti-VersionControl. That's the whole reason for build.properties. This way you don't muck with the actual build process, just with the build parameters. Another issue with this is mentioned above. If you "checkout" this file and then modify it you can no longer "update" to the latest version of it without overwriting all your customizations. Which is why either, the initial "checkout" should actually be an "export" because that removes all SVN-ness associated with the file - OR the build.properties should be used and the custom_build.xml should be left untouched. My original Ant scripts included an example build.properties file, and a task to copy that over into the real thing. This gives people a working base of build parameters, and just requires them to supply the plugin name and version.

Lastly, I mentioned this in another thread, but in the future, it would be really great if when you're introducing new stuff like this if you could take care not to break the existing stuff that we know works. This is exactly the reason why I didn't touch the pjo.py scripts and created whole new ones - yes, they're completely different technologies, but I consciously didn't want to break the stuff that Alan and Dale were already using for plugin releases. Just in case there's something wrong with what I'm doing (no one is perfect), there's always a backup. You created the custom_build.xml which is great, but you made my existing scripts dependent on build-helper.xml, breaking them in the process.

All of that said, I really do like what you were trying to do. The SVN checkout of build-support and the rest of the Ant stuff is really cool. I could see this extending to downloading and installing the jEdit installations themselves. Considering that the custom_build.xml file delegates mostly to my existing scripts, this would have been a great addition to them.

Now, to my error, so that I can get back to helping do plugin releases.

I get a macrodef error when I try to run any of the pf.download/build/view targets. The error is generated from like 204 of build-helper.xml:
<local name="ivy.dir" />

I get an error saying that the name is not defined.

I've tried setting -Divy.dir=some/path but it doesn't work.

Any ideas as to why this doesn't work?

Thanks for your time.
Eric

--
Learn from the past. Live in the present. Plan for the future.
Blog: http://eric-berry.blogspot.com
jEdit <http://www.jedit.org> - Programmer's Text Editor

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
--
-----------------------------------------------
jEdit Developers' List
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jedit-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ jEdit-devel ] Few thoughts on the new plugin release process, and an error.

Jarekczek
Administrator
Hi Eric

Thanks for your feedback. I have to admit that you are right, especially
in problematic custom_build script updates. But since many things in the
whole process are not handled automatically, I don't consider it a
serious disadvantage. And as you probably know, for months no-one tried
to apply any of those scripts. Even though I was encouraging many times
to doing that. Finally Alan did, but now I see he used the oldest
version. Since no-one was interested in testing it and sending the
feedback, now I think it's to late for general changes from my side. But
I'm still ready to correct any reported error. This is open source, feel
free to improve it. I did all my best to make it good. When I do plugin
releases from time to time, I'm still satisfied with the way it works.

I think I'll try to analyze if the customization cannot be handled by
properties files, for those willing to use them. It may really be better
considering updating the environment. But definitely the environment is
not updated frequently. And the file is divided into sections commented:
"adjust once", "adjust per plugin". If you do an upgrade some time,
maybe you'll find it not really cumbersome.

If you know a better way of obtaining the custom_build file, please
update the wiki. I presented the way I discovered, possibly not the best
one.

As you said: this improvement (or "improvement") should not collide with
previous way of doing things. And it does not. I didn't break the old
process. If you could send me the exact error message that you get, I
could say this for sure. But now I'm pretty sure that you use an old ant
version. Jedit requires 1.8.2. Using that version should make your
problem go away.

Regards
Jarek

W dniu 2012-11-12 20:33, Eric Berry pisze:

> Hi Jarek,
>    First and foremost. I really appreciate all the work you've put
> into the new process. I'm having troubles setting it up locally, which
> I'll get to later, but first I have some thoughts on what you've done
> that I'd like to bring them up for conversation.
>
> There are some things you do in the instructions found here that go
> against the conventions of the technologies we're using:
> http://sourceforge.net/apps/mediawiki/jedit/index.php?title=Conventions,_procedures#Releasing_a_plugin_part_II
>
> First, NONE of the commands will work out of the box. This is due to
> the build file being named "custom_build.xml". You need to tell Ant to
> use that file specifically, or rename the file to "build.xml".
> Eg. All the commands look like this out of the box "ant -f
> custom_build.xml pf.foo".
>
> Second, I understand what you were trying to do here, but asking
> people to download the source into a temp directory, then delete
> everything else is misleading and dangerous. A. This should be an
> export, not a checkout (more on this later), B. You're
> custom_build.xml script is just going to checkout the whole directory
> again for the user - I followed your instructions and when I saw it
> downloading the source again, I asked "Why, I just did that to get the
> custom_build.xml?".
>
> Third, having the user modify the custom_build.xml file for each
> plugin is very anti-Ant, and very anti-VersionControl. That's the
> whole reason for build.properties. This way you don't muck with the
> actual build process, just with the build parameters. Another issue
> with this is mentioned above. If you "checkout" this file and then
> modify it you can no longer "update" to the latest version of it
> without overwriting all your customizations. Which is why either, the
> initial "checkout" should actually be an "export" because that removes
> all SVN-ness associated with the file - OR the build.properties should
> be used and the custom_build.xml should be left untouched. My original
> Ant scripts included an example build.properties file, and a task to
> copy that over into the real thing. This gives people a working base
> of build parameters, and just requires them to supply the plugin name
> and version.
>
> Lastly, I mentioned this in another thread, but in the future, it
> would be really great if when you're introducing new stuff like this
> if you could take care not to break the existing stuff that we know
> works. This is exactly the reason why I didn't touch the pjo.py
> scripts and created whole new ones - yes, they're completely different
> technologies, but I consciously didn't want to break the stuff that
> Alan and Dale were already using for plugin releases. Just in case
> there's something wrong with what I'm doing (no one is perfect),
> there's always a backup. You created the custom_build.xml which is
> great, but you made my existing scripts dependent on build-helper.xml,
> breaking them in the process.
>
> All of that said, I really do like what you were trying to do. The SVN
> checkout of build-support and the rest of the Ant stuff is really
> cool. I could see this extending to downloading and installing the
> jEdit installations themselves. Considering that the custom_build.xml
> file delegates mostly to my existing scripts, this would have been a
> great addition to them.
>
> Now, to my error, so that I can get back to helping do plugin releases.
>
> I get a macrodef error when I try to run any of the
> pf.download/build/view targets. The error is generated from like 204
> of build-helper.xml:
> <local name="ivy.dir" />
>
> I get an error saying that the name is not defined.
>
> I've tried setting -Divy.dir=some/path but it doesn't work.
>
> Any ideas as to why this doesn't work?
>
> Thanks for your time.
> Eric
>
> --
> Learn from the past. Live in the present. Plan for the future.
> Blog: http://eric-berry.blogspot.com <http://eric-berry.blogspot.com/>
> jEdit <http://www.jedit.org <http://www.jedit.org/>> - Programmer's
> Text Editor
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
>
>


------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
--
-----------------------------------------------
jEdit Developers' List
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jedit-devel
Loading...