Eclipse Plugin Users

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Eclipse Plugin Users

Mark_Melvin

Hi There,

Is anyone currently using the Eclipse plugin with AnthillPro to actually resolve their dependencies?  I am in a bit of a conundrum because I have all of my Anthill projects configured to build Eclipse plugins using a fairly specific directory structure, but it involves staging dependencies to specifically-structured temporary staging area first, then copying them to the appropriate locations (some located in the plugin itself) at build time.  I then tried to use the Urbancode-provided Eclipse plugin in my development workbench, but this resolves the plugin dependencies to the temporary staging area, not the final location.  And it also resolves all dependencies - some of which are common build scripts used for building Eclipse plugins - into my plugin (including all the digest and bom files), which results in a big mess of files.

I had a brain wave and thought OK, I'll just create a second Anthill project - one for staging the plugin source, and dependencies that go into the plugin itself (like .dlls that must go in <plugin>/os/win32/x86/xxx.dll), and then publish all of that as artifacts to use in the actual plugin build in a second Anthill project.  I could then link my Eclipse workspace projects via the Urbancode plugin to the first Anthill project.  I did this and the resolve works great.  However, it seems I can't create an originating workflow-based Anthill build without specifying a source checkout - so I can't cleanly implement the second Anthill project (which consumes the artifacts of the first project) unless I set up a dummy CVS checkout or something.  Ick.

Anyway, if anyone is still following this - my second idea was to create a custom build script in my Eclipse plugins that fetches and copies dependencies using the Ant codestation tasks.  This allows the developer to run the script from within Eclipse to update any dependencies in the project by downloading the latest from the Anthill server, and copy them to the appropriate location, deleting any staging area when it is done.  It also can be used in the actual build on the Anthill server (avoiding the fetch/resolve, as that is already done by Anthill) with some property overrides to copy the latest dependencies into the plugin at build time.  This works, but feels a little awkward because I am going to be duplicating this script a lot, and it also means I am not using the Urbancode Eclipse plugin at all.

Is anyone using the Eclipse plugin?  Does anyone know if it has it changed at all in 3.6?  It would be really cool if you could select exactly which dependencies to resolve, and where to put them.  Or perhaps hook it to a script to copy stuff around after the resolve occurs.  If I could do that, then I could use the plugin without jumping through all of these hoops.

Thanks,
Mark.

_______________________________________________
Anthill-pro mailing list
[hidden email]
http://lists.urbancode.com/mailman/listinfo/anthill-pro
Reply | Threaded
Open this post in threaded view
|

RE: Eclipse Plugin Users

Mikal Todd

Hi Mark,

 

Yes we have been using the Codestation Eclipse plugin for over a year now. We’ve brought this up previously with Urbancode I believe, the architecture does need some tweaking, but the concepts are sound.

 

We too would like to be able to only specify certain dependant artifacts for codestation to resolve. We’ve tried the dummy project approach and got thwarted the same way.

 

Another real pain is that you cannot resolve previous artifacts from the same workflow. We have a process that is incremental, producing database upgrades. We want to be able to daisy chain them, so that when you run an upgrade it can get all the patch files from previous builds on the same workflow, then prepare an upgrade based on these and the current code. Because you can’t resolve against yourself we have to store the patches on an ftp site and have written our own resolver. Yuck!

 

The other main gripe I have is that codestation update checking should be autonomous. Developers shouldn’t have to regularly click update – the system should asynchronously speak to the AHP server and if there are new updates, prompt the developer and offer them up in the IDE, or at least fire an alert into the status window (an option to select notifications would be good).

 

Cheers,

Mike

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Thursday, 8 January 2009 4:50 a.m.
To: [hidden email]
Subject: [Anthill-pro] Eclipse Plugin Users

 


Hi There,

Is anyone currently using the Eclipse plugin with AnthillPro to actually resolve their dependencies?  I am in a bit of a conundrum because I have all of my Anthill projects configured to build Eclipse plugins using a fairly specific directory structure, but it involves staging dependencies to specifically-structured temporary staging area first, then copying them to the appropriate locations (some located in the plugin itself) at build time.  I then tried to use the Urbancode-provided Eclipse plugin in my development workbench, but this resolves the plugin dependencies to the temporary staging area, not the final location.  And it also resolves all dependencies - some of which are common build scripts used for building Eclipse plugins - into my plugin (including all the digest and bom files), which results in a big mess of files.

I had a brain wave and thought OK, I'll just create a second Anthill project - one for staging the plugin source, and dependencies that go into the plugin itself (like .dlls that must go in <plugin>/os/win32/x86/xxx.dll), and then publish all of that as artifacts to use in the actual plugin build in a second Anthill project.  I could then link my Eclipse workspace projects via the Urbancode plugin to the first Anthill project.  I did this and the resolve works great.  However, it seems I can't create an originating workflow-based Anthill build without specifying a source checkout - so I can't cleanly implement the second Anthill project (which consumes the artifacts of the first project) unless I set up a dummy CVS checkout or something.  Ick.

Anyway, if anyone is still following this - my second idea was to create a custom build script in my Eclipse plugins that fetches and copies dependencies using the Ant codestation tasks.  This allows the developer to run the script from within Eclipse to update any dependencies in the project by downloading the latest from the Anthill server, and copy them to the appropriate location, deleting any staging area when it is done.  It also can be used in the actual build on the Anthill server (avoiding the fetch/resolve, as that is already done by Anthill) with some property overrides to copy the latest dependencies into the plugin at build time.  This works, but feels a little awkward because I am going to be duplicating this script a lot, and it also means I am not using the Urbancode Eclipse plugin at all.

Is anyone using the Eclipse plugin?  Does anyone know if it has it changed at all in 3.6?  It would be really cool if you could select exactly which dependencies to resolve, and where to put them.  Or perhaps hook it to a script to copy stuff around after the resolve occurs.  If I could do that, then I could use the plugin without jumping through all of these hoops.

Thanks,
Mark.


_______________________________________________
Anthill-pro mailing list
[hidden email]
http://lists.urbancode.com/mailman/listinfo/anthill-pro
Reply | Threaded
Open this post in threaded view
|

RE: Eclipse Plugin Users

Gurinder.Randhawa

We too would like to be able to only specify certain dependant artifacts for codestation to resolve. We've brought this up with AnthillPro guys, hopefully next release they can improve upon CodeStation plugin functionality.

--Gurinder


From: Mikal Todd <[hidden email]>
To: AnthillPro user and support list. <[hidden email]>
Date: 07/01/2009 12:54 PM
Subject: RE: [Anthill-pro] Eclipse Plugin Users





Hi Mark,
 
Yes we have been using the Codestation Eclipse plugin for over a year now. We’ve brought this up previously with Urbancode I believe, the architecture does need some tweaking, but the concepts are sound.
 
We too would like to be able to only specify certain dependant artifacts for codestation to resolve. We’ve tried the dummy project approach and got thwarted the same way.
 
Another real pain is that you cannot resolve previous artifacts from the same workflow. We have a process that is incremental, producing database upgrades. We want to be able to daisy chain them, so that when you run an upgrade it can get all the patch files from previous builds on the same workflow, then prepare an upgrade based on these and the current code. Because you can’t resolve against yourself we have to store the patches on an ftp site and have written our own resolver. Yuck!
 
The other main gripe I have is that codestation update checking should be autonomous. Developers shouldn’t have to regularly click update – the system should asynchronously speak to the AHP server and if there are new updates, prompt the developer and offer them up in the IDE, or at least fire an alert into the status window (an option to select notifications would be good).
 
Cheers,

Mike

 



From: [hidden email] [[hidden email]] On Behalf Of [hidden email]
Sent:
Thursday, 8 January 2009 4:50 a.m.
To:
[hidden email]
Subject:
[Anthill-pro] Eclipse Plugin Users

 

Hi There,


Is anyone currently using the Eclipse plugin with AnthillPro to actually resolve their dependencies?  I am in a bit of a conundrum because I have all of my Anthill projects configured to build Eclipse plugins using a fairly specific directory structure, but it involves staging dependencies to specifically-structured temporary staging area first, then copying them to the appropriate locations (some located in the plugin itself) at build time.  I then tried to use the Urbancode-provided Eclipse plugin in my development workbench, but this resolves the plugin dependencies to the temporary staging area, not the final location.  And it also resolves all dependencies - some of which are common build scripts used for building Eclipse plugins - into my plugin (including all the digest and bom files), which results in a big mess of files.


I had a brain wave and thought OK, I'll just create a second Anthill project - one for staging the plugin source, and dependencies that go into the plugin itself (like .dlls that must go in <plugin>/os/win32/x86/xxx.dll), and then publish all of that as artifacts to use in the actual plugin build in a second Anthill project.  I could then link my Eclipse workspace projects via the Urbancode plugin to the first Anthill project.  I did this and the resolve works great.  However, it seems I can't create an originating workflow-based Anthill build without specifying a source checkout - so I can't cleanly implement the second Anthill project (which consumes the artifacts of the first project) unless I set up a dummy CVS checkout or something.  Ick.


Anyway, if anyone is still following this - my second idea was to create a custom build script in my Eclipse plugins that fetches and copies dependencies using the Ant codestation tasks.  This allows the developer to run the script from within Eclipse to update any dependencies in the project by downloading the latest from the Anthill server, and copy them to the appropriate location, deleting any staging area when it is done.  It also can be used in the actual build on the Anthill server (avoiding the fetch/resolve, as that is already done by Anthill) with some property overrides to copy the latest dependencies into the plugin at build time.  This works, but feels a little awkward because I am going to be duplicating this script a lot, and it also means I am not using the Urbancode Eclipse plugin at all.


Is anyone using the Eclipse plugin?  Does anyone know if it has it changed at all in 3.6?  It would be really cool if you could select exactly which dependencies to resolve, and where to put them.  Or perhaps hook it to a script to copy stuff around after the resolve occurs.  If I could do that, then I could use the plugin without jumping through all of these hoops.


Thanks,

Mark.
_______________________________________________
Anthill-pro mailing list
[hidden email]
http://lists.urbancode.com/mailman/listinfo/anthill-pro



_______________________________________________
Anthill-pro mailing list
[hidden email]
http://lists.urbancode.com/mailman/listinfo/anthill-pro
Reply | Threaded
Open this post in threaded view
|

RE: Eclipse Plugin Users

Mark_Melvin

Thanks for the replies, guys.  Mike - your reply was very detailed - thanks!  I agree that the plugin concept is sound, but could use some tweaks.  Hopefully 3.6 may improve things somewhat.  For now I may resort to my custom build script.

Mark.
----------------------------------------------------------



[hidden email]
Sent by: [hidden email]

01/07/2009 03:58 PM

Please respond to
"AnthillPro user and support list." <[hidden email]>

To
"AnthillPro user and support list." <[hidden email]>
cc
Subject
RE: [Anthill-pro] Eclipse Plugin Users






We too would like to be able to only specify certain dependant artifacts for codestation to resolve.
We've brought this up with AnthillPro guys, hopefully next release they can improve upon CodeStation plugin functionality.

--Gurinder


From: Mikal Todd <[hidden email]>
To: AnthillPro user and support list. <[hidden email]>
Date: 07/01/2009 12:54 PM
Subject: RE: [Anthill-pro] Eclipse Plugin Users






Hi Mark,

 
Yes we have been using the Codestation Eclipse plugin for over a year now. We’ve brought this up previously with Urbancode I believe, the architecture does need some tweaking, but the concepts are sound.

 
We too would like to be able to only specify certain dependant artifacts for codestation to resolve. We’ve tried the dummy project approach and got thwarted the same way.
 
Another real pain is that you cannot resolve previous artifacts from the same workflow. We have a process that is incremental, producing database upgrades. We want to be able to daisy chain them, so that when you run an upgrade it can get all the patch files from previous builds on the same workflow, then prepare an upgrade based on these and the current code. Because you can’t resolve against yourself we have to store the patches on an ftp site and have written our own resolver. Yuck!
 
The other main gripe I have is that codestation update checking should be autonomous. Developers shouldn’t have to regularly click update – the system should asynchronously speak to the AHP server and if there are new updates, prompt the developer and offer them up in the IDE, or at least fire an alert into the status window (an option to select notifications would be good).

 
Cheers,

Mike

 





From:
[hidden email] [
[hidden email]] On Behalf Of [hidden email]
Sent:
Thursday, 8 January 2009 4:50 a.m.
To:
[hidden email]
Subject:
[Anthill-pro] Eclipse Plugin Users

 

Hi There,


Is anyone currently using the Eclipse plugin with AnthillPro to actually resolve their dependencies?  I am in a bit of a conundrum because I have all of my Anthill projects configured to build Eclipse plugins using a fairly specific directory structure, but it involves staging dependencies to specifically-structured temporary staging area first, then copying them to the appropriate locations (some located in the plugin itself) at build time.  I then tried to use the Urbancode-provided Eclipse plugin in my development workbench, but this resolves the plugin dependencies to the temporary staging area, not the final location.  And it also resolves all dependencies - some of which are common build scripts used for building Eclipse plugins - into my plugin (including all the digest and bom files), which results in a big mess of files.


I had a brain wave and thought OK, I'll just create a second Anthill project - one for staging the plugin source, and dependencies that go into the plugin itself (like .dlls that must go in <plugin>/os/win32/x86/xxx.dll), and then publish all of that as artifacts to use in the actual plugin build in a second Anthill project.  I could then link my Eclipse workspace projects via the Urbancode plugin to the first Anthill project.  I did this and the resolve works great.  However, it seems I can't create an originating workflow-based Anthill build without specifying a source checkout - so I can't cleanly implement the second Anthill project (which consumes the artifacts of the first project) unless I set up a dummy CVS checkout or something.  Ick.


Anyway, if anyone is still following this - my second idea was to create a custom build script in my Eclipse plugins that fetches and copies dependencies using the Ant codestation tasks.  This allows the developer to run the script from within Eclipse to update any dependencies in the project by downloading the latest from the Anthill server, and copy them to the appropriate location, deleting any staging area when it is done.  It also can be used in the actual build on the Anthill server (avoiding the fetch/resolve, as that is already done by Anthill) with some property overrides to copy the latest dependencies into the plugin at build time.  This works, but feels a little awkward because I am going to be duplicating this script a lot, and it also means I am not using the Urbancode Eclipse plugin at all.


Is anyone using the Eclipse plugin?  Does anyone know if it has it changed at all in 3.6?  It would be really cool if you could select exactly which dependencies to resolve, and where to put them.  Or perhaps hook it to a script to copy stuff around after the resolve occurs.  If I could do that, then I could use the plugin without jumping through all of these hoops.


Thanks,

Mark.
_______________________________________________
Anthill-pro mailing list
[hidden email]

http://lists.urbancode.com/mailman/listinfo/anthill-pro

_______________________________________________
Anthill-pro mailing list
[hidden email]
http://lists.urbancode.com/mailman/listinfo/anthill-pro


_______________________________________________
Anthill-pro mailing list
[hidden email]
http://lists.urbancode.com/mailman/listinfo/anthill-pro