Re: Using WO with modern dependency management

[Faizel Dakri]

> On 2015-May-06, at 12:34 PM, Ramsey Gurley  wrote:
> 
> Two questions (at the moment). 
> 
> In [3] it seems bundles are required. Does using maven preclude using 
> bundleless builds? That would be a real downer.

In my experience, yes, bundles are required. I have never been successful 
running with bundle-less builds. If I were to venture a guess, it would be that 
bundle-less builds depend on the Fluffy Bunny layout, whereas the standard 
Maven layout is different. 

> Is it possible to have maven use local changes to Wonder in the workspace? 
> Like, I find a bug in ERXExtensions, I fix that bug locally, then run my 
> application dependent on ERXExtensions to test that the bug is indeed fixed 
> before pushing it to the main wonder repo.

Yes, this is possible. I don’t have Wonder in my workspace, but I do have other 
frameworks in there that are dependencies for other apps in the same workspace. 
I am able to edit a framework within Eclipse and run an app against those 
changes without having to deploy to my local maven repo first. I’m not entirely 
clear on the mechanism, but I believe that the incremental builder is used 
while in Eclipse and dependencies are resolved from the workspace before the 
local maven repo (there is a setting in a project’s properties where you can 
toggle this behavior; I believe it defaults to workspace resolution). 

F

-- 
Faizel Dakri
list...@dakri.com



> 
> On May 6, 2015, at 12:47 AM, Faizel Dakri  > wrote:
> 
>> Accidentally hit send too soon…
>> 
>> In defense of Maven, I don’t think you have to be an expert, but you do have 
>> to be willing to give in to the maven way of doing things and go the whole 
>> hog (for me, that also meant abandoning Fluffy Bunny and adopting the maven 
>> layout, something I actually had no problem with). I currently have a 
>> development environment built on maven that I’m happy with. It took a little 
>> while to get my head around maven and lots of reading and re-reading the 
>> wiki and the Wonder POMs (thanks to all that contributed), but it is now a 
>> relatively predictable environment. I don’t know if what I’m doing is the 
>> ideal way of doing things, but it does work well for me. There are a couple 
>> of idiosyncrasies to deal with, but nothing serious. Granted, I haven’t yet 
>> had to deal with the maven deployment end of things (e.g. incrementing 
>> version numbers) for a production rollout, but I’m pretty confident that 
>> I’ll be able to jump that hurdle when the time comes.
>> 
>> What I like:
>> 
>>- quickly adding a new library by adding a dependency to a POM file
>>- overriding a Wonder dependency in a local POM file
>>- building a true war that I can test with “mvn jetty:run-war”
>>- creating a fully contained war file with static resources bundled (via 
>> a custom assembly)
>> 
>> 
>> Stumbling blocks I encountered:
>> 
>>- initial setup
>>- creating projects using the m2e plugin
>>- launching from within Eclipse
>>- embedding all resources in the final product
>> 
>> For the initial setup, once I got the right settings.xml [1] and 
>> archetype-catalog.xml [2] installed in my local repo things ran much more 
>> smoothly. I also ended up installing Maven 3, although I initially started 
>> with Maven 2. For the archetype-catalog.xml, I pruned it so that it only had 
>> the version 2.1 archetypes. After that, I setup a launch configuration 
>> following the wiki instructions [3]. For my project repo, I ended up with 
>> the following structure (I follow the Wonder style where my repo contains 
>> many frameworks and apps):
>> 
>> project_root/
>>pom.xml
>>frameworks/
>>pom.xml
>>framework1/
>>pom.xml
>>framework2/
>>pom.xml
>>applications
>>pom.xml
>>app1/
>>pom.xml
>>app2/
>>pom.xml
>> 
>> In this layout, dependencies are declared in the root POM, including version 
>> info (this allows me to control which versions of which libraries are used), 
>> along with any properties that are to be pushed to child POMs. All 
>> lower-level POMs are descendants of the root POM (in a parent-child 
>> hierarchy). This is directly inspired by the way the Wonder POMs are 
>> structured. Most of the complexity is in the root POM and in the 
>> frameworks/pom.xml and applications/pom.xml (through pluginManagement and 
>> dependencyManagement sections). The individual app and framework POMs are 
>> pretty simple and are basically just dependency declarations (versions are 
>> inherited from the root POM by default) plus some workarounds for flattening 
>> resources, which is one of the idiosyncrasies I was referring to. Using this 
>> setup, it has become trivial to try out new libraries by declaring the full 
>> dependency coordinate in the root POM and then just referring to it in the 
>> specific project th

Re: Using WO with modern dependency management

[Henrique Prange]

When people start looking into an alternative to Ant, it's usually because of 
the lack of dependency management. Not having dependency management for 
libraries nowadays is as bad as not having a VCS for source code. Ant+Ivy, 
Maven and Gradle offer this feature in a very similar way. The problem is: none 
of then offer a complete solution to the dependency management problem. They 
solve half of the problem and that is where developers start to complain about 
the tool. Even worse, some developers start to look for the wrong means to 
manage dependencies with those tools.

Dependency management is a way of consuming libraries and its dependencies in a 
declarative manner. Nothing new here. However, it's also a way of producing 
dependencies. The question is: where do you put a library developed to be 
consumed by other projects and by other developers? A dependency management 
repository is required to solve the problem. My recommendation to anyone 
interested in using Ant+Ivy, Maven or Gradle is to take the time to analyze one 
of the main Repository Managers available: Archiva, Artifactory or Nexus.

Also there are other topics that make a build tool excel.
  -Integration (IDE, build server, editors, frameworks and etc)
  -Plugin ecosystem

I've been using the combo Maven + Nexus for a long time. Maven is a mature 
tool. It integrates very well with a wide range of tools. I've been solving all 
my needs using existing plugins. It's also the de facto build tool for a lot of 
open source projects. Specifically for WO development, I have less problems now 
than 5 years ago, but of course there are still problems.

For anyone trying an alternative to Ant, don't be fooled. In the end, every 
build tool requires time and configuration.

Cheers,

Henrique

> On 04/05/2015, at 13:43, Chuck Hill  wrote:
> 
> I think that “Maven expert” is the key here.  This is not a trivial thing to 
> setup correctly and maintain.  It is trivial to setup and use incorrectly and 
> I have seen the pain resulting from that.  To benefit from Maven you need to 
> really deeply understand Maven and its approach to dependancy management.  
> And you need to ensure that the whole team plays by The Maven Rules, even if 
> it makes more work short term and a bit of cheating does not seem that bad at 
> the moment.
> 
> Chuck
> 
> 
> 
> On 2015-05-04, 8:29 AM, "Jean-François Veillette" wrote:
> 
> At my previous workplace, we did the switch to Maven.  Luckily we had a real 
> maven expert to drive the move.
> We started with around 50+ projects, all ant based, using the ‘standard’ 
> fluffy-bunny layout.  He added pom.xml here and there, and everything just 
> started working with maven.  We had choice to build/run with maven and/or ant 
> and it was (almost) transparent.  The only exception was that if you decided 
> to use in maven, you had to change the class path to remove everything but 
> the maven and java dependencies (2 lines left), a simple .classpath that was 
> standard and could be copied from one project to the other.
> The maven build was then integrated with Jenkins (CI) and SonarQube (so that 
> future ‘JF’ is happy with old ‘JF’, and all the team's work are standardized 
> a bit) with ease.
> 
> From my experience, the team was happy with the Maven switch, none of us had 
> to become an expert (because we had one already).
> Maven help a lot on easing the dependency management of your apps (a building 
> block only declare his direct dependency).  Once you remove the noise of 
> declaring dependencies, you will be left with a clear graph of dependent 
> block.  You will then have to tackle the real problem of incompatible 
> dependencies (A need B and Xv1, but B need Xv2).  Maven will make the graph 
> simple and clear, it will try to provide helper but can’t really help much 
> after that.
> 
> jfv
> 
> 
>> On May 4, 2015, at 5:09 AM, David Avendasora > > wrote:
>> 
>>> On May 1, 2015, at 6:35 PM, Chuck Hill >> > wrote:
>>> 
>>> Maven seems like a better thought out and implemented solution.
>> 
>> …
>> 
>> Have you ever had one of those moments where things just seem so off-kilter 
>> you’re sure you’re having a dream, but no matter how many times you cry out 
>> for mommy you are left sitting there slowly realizing that there’s been some 
>> fundamental shift in the universe that you missed out on. (And your wife is 
>> slowly picking up her phone and dialing your therapist. Again.)
>> 
>> —
>> WebObjects - so easy that even Dave Avendasora can do it!™
>> —
>> David Avendasora
>> Senior Software Abuser
>> Nekesto, Inc.
> ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/h

Re: Using WO with modern dependency management

[Fabian Peters]

> Two questions (at the moment). 
> 
> In [3] it seems bundles are required. Does using maven preclude using 
> bundleless builds? That would be a real downer.

I think I've tried at some point and it didn't work. Might not mean much…

> Is it possible to have maven use local changes to Wonder in the workspace? 
> Like, I find a bug in ERXExtensions, I fix that bug locally, then run my 
> application dependent on ERXExtensions to test that the bug is indeed fixed 
> before pushing it to the main wonder repo.

That works, you just have to right-click your projects and enable workspace 
resolution:




One thing that I find annoying are the additional steps you have to take for 
the debugger to correctly identify framework classes: 


Fabian

> 
> 
> On May 6, 2015, at 12:47 AM, Faizel Dakri  wrote:
> 
>> Accidentally hit send too soon…
>> 
>> In defense of Maven, I don’t think you have to be an expert, but you do have 
>> to be willing to give in to the maven way of doing things and go the whole 
>> hog (for me, that also meant abandoning Fluffy Bunny and adopting the maven 
>> layout, something I actually had no problem with). I currently have a 
>> development environment built on maven that I’m happy with. It took a little 
>> while to get my head around maven and lots of reading and re-reading the 
>> wiki and the Wonder POMs (thanks to all that contributed), but it is now a 
>> relatively predictable environment. I don’t know if what I’m doing is the 
>> ideal way of doing things, but it does work well for me. There are a couple 
>> of idiosyncrasies to deal with, but nothing serious. Granted, I haven’t yet 
>> had to deal with the maven deployment end of things (e.g. incrementing 
>> version numbers) for a production rollout, but I’m pretty confident that 
>> I’ll be able to jump that hurdle when the time comes.
>> 
>> What I like:
>> 
>>- quickly adding a new library by adding a dependency to a POM file
>>- overriding a Wonder dependency in a local POM file
>>- building a true war that I can test with “mvn jetty:run-war”
>>- creating a fully contained war file with static resources bundled (via 
>> a custom assembly)
>> 
>> 
>> Stumbling blocks I encountered:
>> 
>>- initial setup
>>- creating projects using the m2e plugin
>>- launching from within Eclipse
>>- embedding all resources in the final product
>> 
>> For the initial setup, once I got the right settings.xml [1] and 
>> archetype-catalog.xml [2] installed in my local repo things ran much more 
>> smoothly. I also ended up installing Maven 3, although I initially started 
>> with Maven 2. For the archetype-catalog.xml, I pruned it so that it only had 
>> the version 2.1 archetypes. After that, I setup a launch configuration 
>> following the wiki instructions [3]. For my project repo, I ended up with 
>> the following structure (I follow the Wonder style where my repo contains 
>> many frameworks and apps):
>> 
>> project_root/
>>pom.xml
>>frameworks/
>>pom.xml
>>framework1/
>>pom.xml
>>framework2/
>>pom.xml
>>applications
>>pom.xml
>>app1/
>>pom.xml
>>app2/
>>pom.xml
>> 
>> In this layout, dependencies are declared in the root POM, including version 
>> info (this allows me to control which versions of which libraries are used), 
>> along with any properties that are to be pushed to child POMs. All 
>> lower-level POMs are descendants of the root POM (in a parent-child 
>> hierarchy). This is directly inspired by the way the Wonder POMs are 
>> structured. Most of the complexity is in the root POM and in the 
>> frameworks/pom.xml and applications/pom.xml (through pluginManagement and 
>> dependencyManagement sections). The individual app and framework POMs are 
>> pretty simple and are basically just dependency declarations (versions are 
>> inherited from the root POM by default) plus some workarounds for flattening 
>> resources, which is one of the idiosyncrasies I was referring to. Using this 
>> setup, it has become trivial to try out new libraries by declaring the full 
>> dependency coordinate in the root POM and then just referring to it in the 
>> specific project that needs it.
>> 
>> I still do my development in Eclipse/WOLips running with direct connect and 
>> then deploy to Tomcat (running behind Apache) when I’m ready to test by just 
>> copying over a single war file. Again, this is just in my development 
>> environment—I haven’t yet attempted a full production install—and there is 
>> some runtime hackery going on to use the appropriate context class depending 
>> on whether or not we’re running in a servlet. One of the shortcomings that 
>> I’ve encountered is that I do have to do some setup for my launch 
>> configurations to set up the buil

Re: Using WO with modern dependency management

[Ramsey Gurley]

Two questions (at the moment). 

In [3] it seems bundles are required. Does using maven preclude using 
bundleless builds? That would be a real downer.

Is it possible to have maven use local changes to Wonder in the workspace? 
Like, I find a bug in ERXExtensions, I fix that bug locally, then run my 
application dependent on ERXExtensions to test that the bug is indeed fixed 
before pushing it to the main wonder repo.



On May 6, 2015, at 12:47 AM, Faizel Dakri  wrote:

> Accidentally hit send too soon…
> 
> In defense of Maven, I don’t think you have to be an expert, but you do have 
> to be willing to give in to the maven way of doing things and go the whole 
> hog (for me, that also meant abandoning Fluffy Bunny and adopting the maven 
> layout, something I actually had no problem with). I currently have a 
> development environment built on maven that I’m happy with. It took a little 
> while to get my head around maven and lots of reading and re-reading the wiki 
> and the Wonder POMs (thanks to all that contributed), but it is now a 
> relatively predictable environment. I don’t know if what I’m doing is the 
> ideal way of doing things, but it does work well for me. There are a couple 
> of idiosyncrasies to deal with, but nothing serious. Granted, I haven’t yet 
> had to deal with the maven deployment end of things (e.g. incrementing 
> version numbers) for a production rollout, but I’m pretty confident that I’ll 
> be able to jump that hurdle when the time comes.
> 
> What I like:
> 
>- quickly adding a new library by adding a dependency to a POM file
>- overriding a Wonder dependency in a local POM file
>- building a true war that I can test with “mvn jetty:run-war”
>- creating a fully contained war file with static resources bundled (via a 
> custom assembly)
> 
> 
> Stumbling blocks I encountered:
> 
>- initial setup
>- creating projects using the m2e plugin
>- launching from within Eclipse
>- embedding all resources in the final product
> 
> For the initial setup, once I got the right settings.xml [1] and 
> archetype-catalog.xml [2] installed in my local repo things ran much more 
> smoothly. I also ended up installing Maven 3, although I initially started 
> with Maven 2. For the archetype-catalog.xml, I pruned it so that it only had 
> the version 2.1 archetypes. After that, I setup a launch configuration 
> following the wiki instructions [3]. For my project repo, I ended up with the 
> following structure (I follow the Wonder style where my repo contains many 
> frameworks and apps):
> 
> project_root/
>pom.xml
>frameworks/
>pom.xml
>framework1/
>pom.xml
>framework2/
>pom.xml
>applications
>pom.xml
>app1/
>pom.xml
>app2/
>pom.xml
> 
> In this layout, dependencies are declared in the root POM, including version 
> info (this allows me to control which versions of which libraries are used), 
> along with any properties that are to be pushed to child POMs. All 
> lower-level POMs are descendants of the root POM (in a parent-child 
> hierarchy). This is directly inspired by the way the Wonder POMs are 
> structured. Most of the complexity is in the root POM and in the 
> frameworks/pom.xml and applications/pom.xml (through pluginManagement and 
> dependencyManagement sections). The individual app and framework POMs are 
> pretty simple and are basically just dependency declarations (versions are 
> inherited from the root POM by default) plus some workarounds for flattening 
> resources, which is one of the idiosyncrasies I was referring to. Using this 
> setup, it has become trivial to try out new libraries by declaring the full 
> dependency coordinate in the root POM and then just referring to it in the 
> specific project that needs it.
> 
> I still do my development in Eclipse/WOLips running with direct connect and 
> then deploy to Tomcat (running behind Apache) when I’m ready to test by just 
> copying over a single war file. Again, this is just in my development 
> environment—I haven’t yet attempted a full production install—and there is 
> some runtime hackery going on to use the appropriate context class depending 
> on whether or not we’re running in a servlet. One of the shortcomings that 
> I’ve encountered is that I do have to do some setup for my launch 
> configurations to set up the build path when running in Eclipse, but this is 
> a one-time thing and is addressed in the wiki [3].
> 
> To package the war file for Tomcat, I use a custom assembly that takes static 
> resources and adds them to the war file, but this was pretty trivial to 
> create (basically just some xml files, packaged as a maven project), however 
> the assembly does make some assumptions about which Wonder frameworks have 
> static resources that are to be bundled (more for my convenience) and does 
> require me to de

Re: Using WO with modern dependency management

[Faizel Dakri]

Accidentally hit send too soon…

In defense of Maven, I don’t think you have to be an expert, but you do have to 
be willing to give in to the maven way of doing things and go the whole hog 
(for me, that also meant abandoning Fluffy Bunny and adopting the maven layout, 
something I actually had no problem with). I currently have a development 
environment built on maven that I’m happy with. It took a little while to get 
my head around maven and lots of reading and re-reading the wiki and the Wonder 
POMs (thanks to all that contributed), but it is now a relatively predictable 
environment. I don’t know if what I’m doing is the ideal way of doing things, 
but it does work well for me. There are a couple of idiosyncrasies to deal 
with, but nothing serious. Granted, I haven’t yet had to deal with the maven 
deployment end of things (e.g. incrementing version numbers) for a production 
rollout, but I’m pretty confident that I’ll be able to jump that hurdle when 
the time comes.

What I like:

- quickly adding a new library by adding a dependency to a POM file
- overriding a Wonder dependency in a local POM file
- building a true war that I can test with “mvn jetty:run-war”
- creating a fully contained war file with static resources bundled (via a 
custom assembly)


Stumbling blocks I encountered:

- initial setup
- creating projects using the m2e plugin
- launching from within Eclipse
- embedding all resources in the final product

For the initial setup, once I got the right settings.xml [1] and 
archetype-catalog.xml [2] installed in my local repo things ran much more 
smoothly. I also ended up installing Maven 3, although I initially started with 
Maven 2. For the archetype-catalog.xml, I pruned it so that it only had the 
version 2.1 archetypes. After that, I setup a launch configuration following 
the wiki instructions [3]. For my project repo, I ended up with the following 
structure (I follow the Wonder style where my repo contains many frameworks and 
apps):

project_root/
pom.xml
frameworks/
pom.xml
framework1/
pom.xml
framework2/
pom.xml
applications
pom.xml
app1/
pom.xml
app2/
pom.xml

In this layout, dependencies are declared in the root POM, including version 
info (this allows me to control which versions of which libraries are used), 
along with any properties that are to be pushed to child POMs. All lower-level 
POMs are descendants of the root POM (in a parent-child hierarchy). This is 
directly inspired by the way the Wonder POMs are structured. Most of the 
complexity is in the root POM and in the frameworks/pom.xml and 
applications/pom.xml (through pluginManagement and dependencyManagement 
sections). The individual app and framework POMs are pretty simple and are 
basically just dependency declarations (versions are inherited from the root 
POM by default) plus some workarounds for flattening resources, which is one of 
the idiosyncrasies I was referring to. Using this setup, it has become trivial 
to try out new libraries by declaring the full dependency coordinate in the 
root POM and then just referring to it in the specific project that needs it.

I still do my development in Eclipse/WOLips running with direct connect and 
then deploy to Tomcat (running behind Apache) when I’m ready to test by just 
copying over a single war file. Again, this is just in my development 
environment—I haven’t yet attempted a full production install—and there is some 
runtime hackery going on to use the appropriate context class depending on 
whether or not we’re running in a servlet. One of the shortcomings that I’ve 
encountered is that I do have to do some setup for my launch configurations to 
set up the build path when running in Eclipse, but this is a one-time thing and 
is addressed in the wiki [3].

To package the war file for Tomcat, I use a custom assembly that takes static 
resources and adds them to the war file, but this was pretty trivial to create 
(basically just some xml files, packaged as a maven project), however the 
assembly does make some assumptions about which Wonder frameworks have static 
resources that are to be bundled (more for my convenience) and does require me 
to declare which of my frameworks need to have their static resource 
dependencies bundled. I would like to improve on the assembly by expanding the 
resources before the war file is created, but for now it involves manipulating 
the war file after the fact, which does take a non-trivial amount of time. 
However, it does work and it is extremely satisfying to see a single file with 
all of my classes, dynamic and static resources (static resources are served by 
Tomcat, not Apache). 

F

[1] 
https://wiki.wocommunity.org/download/attachments/2623477/settings.xml?version=2&modificationDate=1239236585000&api=v2
[2] http://maven.wo

Re: Using WO with modern dependency management

[Faizel Dakri]

I don’t think you have to be a maven expert, but you do have to be willing to 
give in to the maven way of doing things and go the whole hog. I currently have 
a development environment built on maven that I’m happy with, even though I 
started with no maven knowledge. It took a little while to get my head around 
maven, but in the end I like being able to quickly add a new library by adding 
a dependency to my pom.xml file, or even override a Wonder dependency in my 
local POM file. Granted, I haven’t yet had to deal with the maven deployment 
end of things, but I’m pretty confident that I’ll be able to jump that hurdle 
when the time comes. There are a couple of idiosyncrasies that I have to deal 
with, but overall, it is a very predictable environment.

I’m targeting my builds to run as true wars in a servlet container and it is 
extremely nice to be able to “mvn jetty:run-war” to see that it launches in a 
container. Mind you, I do my development in Eclipse with WOLips and I run with 
direct connect from within Eclipse. From my perspective, this gives me the best 
of both worlds: I can develop rapidly in WOLips and then deploy to Tomcat when 
I’m ready by just copying over a single war file.

-- 
Faizel Dakri
list...@dakri.com



> On 2015-May-04, at 11:43 AM, Chuck Hill  wrote:
> 
> I think that “Maven expert” is the key here.  This is not a trivial thing to 
> setup correctly and maintain.  It is trivial to setup and use incorrectly and 
> I have seen the pain resulting from that.  To benefit from Maven you need to 
> really deeply understand Maven and its approach to dependancy management.  
> And you need to ensure that the whole team plays by The Maven Rules, even if 
> it makes more work short term and a bit of cheating does not seem that bad at 
> the moment.
> 
> Chuck
> 
> 
> 
> On 2015-05-04, 8:29 AM, "Jean-François Veillette" wrote:
> 
> At my previous workplace, we did the switch to Maven.  Luckily we had a real 
> maven expert to drive the move.
> We started with around 50+ projects, all ant based, using the ‘standard’ 
> fluffy-bunny layout.  He added pom.xml here and there, and everything just 
> started working with maven.  We had choice to build/run with maven and/or ant 
> and it was (almost) transparent.  The only exception was that if you decided 
> to use in maven, you had to change the class path to remove everything but 
> the maven and java dependencies (2 lines left), a simple .classpath that was 
> standard and could be copied from one project to the other.
> The maven build was then integrated with Jenkins (CI) and SonarQube (so that 
> future ‘JF’ is happy with old ‘JF’, and all the team's work are standardized 
> a bit) with ease.
> 
> From my experience, the team was happy with the Maven switch, none of us had 
> to become an expert (because we had one already).
> Maven help a lot on easing the dependency management of your apps (a building 
> block only declare his direct dependency).  Once you remove the noise of 
> declaring dependencies, you will be left with a clear graph of dependent 
> block.  You will then have to tackle the real problem of incompatible 
> dependencies (A need B and Xv1, but B need Xv2).  Maven will make the graph 
> simple and clear, it will try to provide helper but can’t really help much 
> after that.
> 
> jfv
> 
> 
>> On May 4, 2015, at 5:09 AM, David Avendasora > > wrote:
>> 
>>> On May 1, 2015, at 6:35 PM, Chuck Hill >> > wrote:
>>> 
>>> Maven seems like a better thought out and implemented solution.
>> 
>> …
>> 
>> Have you ever had one of those moments where things just seem so off-kilter 
>> you’re sure you’re having a dream, but no matter how many times you cry out 
>> for mommy you are left sitting there slowly realizing that there’s been some 
>> fundamental shift in the universe that you missed out on. (And your wife is 
>> slowly picking up her phone and dialing your therapist. Again.)
>> 
>> —
>> WebObjects - so easy that even Dave Avendasora can do it!™
>> —
>> David Avendasora
>> Senior Software Abuser
>> Nekesto, Inc.
> ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/listfez%40dakri.com
> 
> This email sent to list...@dakri.com

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Using WO with modern dependency management

[Fabian Peters]

As far as Wonder is concerned, the maven setup is already there, mostly thanks 
to Henrique, Ulrich and Andrus (and anybody else I forgot to mention). And it 
certainly works. I used maven to set up integration-testing of 
ERModernMoviesDemo. Works on travis-ci.org as well, except for the integration 
part, which would require the webobjects jars – which is another topic.

It would certainly be nice to split things up a bit, one reason being the long 
build time.

Fabian

P.S.: You may even keep the fluffy bunny!

> Am 04.05.2015 um 18:43 schrieb Chuck Hill :
> 
> I think that “Maven expert” is the key here.  This is not a trivial thing to 
> setup correctly and maintain.  It is trivial to setup and use incorrectly and 
> I have seen the pain resulting from that.  To benefit from Maven you need to 
> really deeply understand Maven and its approach to dependancy management.  
> And you need to ensure that the whole team plays by The Maven Rules, even if 
> it makes more work short term and a bit of cheating does not seem that bad at 
> the moment.
> 
> Chuck
> 
> 
> 
> On 2015-05-04, 8:29 AM, "Jean-François Veillette" wrote:
> 
> At my previous workplace, we did the switch to Maven.  Luckily we had a real 
> maven expert to drive the move.
> We started with around 50+ projects, all ant based, using the ‘standard’ 
> fluffy-bunny layout.  He added pom.xml here and there, and everything just 
> started working with maven.  We had choice to build/run with maven and/or ant 
> and it was (almost) transparent.  The only exception was that if you decided 
> to use in maven, you had to change the class path to remove everything but 
> the maven and java dependencies (2 lines left), a simple .classpath that was 
> standard and could be copied from one project to the other.
> The maven build was then integrated with Jenkins (CI) and SonarQube (so that 
> future ‘JF’ is happy with old ‘JF’, and all the team's work are standardized 
> a bit) with ease.
> 
> From my experience, the team was happy with the Maven switch, none of us had 
> to become an expert (because we had one already).
> Maven help a lot on easing the dependency management of your apps (a building 
> block only declare his direct dependency).  Once you remove the noise of 
> declaring dependencies, you will be left with a clear graph of dependent 
> block.  You will then have to tackle the real problem of incompatible 
> dependencies (A need B and Xv1, but B need Xv2).  Maven will make the graph 
> simple and clear, it will try to provide helper but can’t really help much 
> after that.
> 
> jfv
> 
> 
>> On May 4, 2015, at 5:09 AM, David Avendasora  
>> wrote:
>> 
>>> On May 1, 2015, at 6:35 PM, Chuck Hill  wrote:
>>> 
>>> Maven seems like a better thought out and implemented solution.
>> 
>> …
>> 
>> Have you ever had one of those moments where things just seem so off-kilter 
>> you’re sure you’re having a dream, but no matter how many times you cry out 
>> for mommy you are left sitting there slowly realizing that there’s been some 
>> fundamental shift in the universe that you missed out on. (And your wife is 
>> slowly picking up her phone and dialing your therapist. Again.)
>> 
>> —
>> WebObjects - so easy that even Dave Avendasora can do it!™
>> —
>> David Avendasora
>> Senior Software Abuser
>> Nekesto, Inc.
> ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/lists.fabian%40e-lumo.com
> 
> This email sent to lists.fab...@e-lumo.com


 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Using WO with modern dependency management

[Chuck Hill]

I think that "Maven expert" is the key here.  This is not a trivial thing to 
setup correctly and maintain.  It is trivial to setup and use incorrectly and I 
have seen the pain resulting from that.  To benefit from Maven you need to 
really deeply understand Maven and its approach to dependancy management.  And 
you need to ensure that the whole team plays by The Maven Rules, even if it 
makes more work short term and a bit of cheating does not seem that bad at the 
moment.

Chuck



On 2015-05-04, 8:29 AM, "Jean-François Veillette" wrote:

At my previous workplace, we did the switch to Maven.  Luckily we had a real 
maven expert to drive the move.
We started with around 50+ projects, all ant based, using the 'standard' 
fluffy-bunny layout.  He added pom.xml here and there, and everything just 
started working with maven.  We had choice to build/run with maven and/or ant 
and it was (almost) transparent.  The only exception was that if you decided to 
use in maven, you had to change the class path to remove everything but the 
maven and java dependencies (2 lines left), a simple .classpath that was 
standard and could be copied from one project to the other.
The maven build was then integrated with Jenkins (CI) and SonarQube (so that 
future 'JF' is happy with old 'JF', and all the team's work are standardized a 
bit) with ease.

>From my experience, the team was happy with the Maven switch, none of us had 
>to become an expert (because we had one already).
Maven help a lot on easing the dependency management of your apps (a building 
block only declare his direct dependency).  Once you remove the noise of 
declaring dependencies, you will be left with a clear graph of dependent block. 
 You will then have to tackle the real problem of incompatible dependencies (A 
need B and Xv1, but B need Xv2).  Maven will make the graph simple and clear, 
it will try to provide helper but can't really help much after that.

jfv


On May 4, 2015, at 5:09 AM, David Avendasora 
mailto:webobje...@avendasora.com>> wrote:

On May 1, 2015, at 6:35 PM, Chuck Hill 
mailto:ch...@gevityinc.com>> wrote:

Maven seems like a better thought out and implemented solution.

...

Have you ever had one of those moments where things just seem so off-kilter 
you're sure you're having a dream, but no matter how many times you cry out for 
mommy you are left sitting there slowly realizing that there's been some 
fundamental shift in the universe that you missed out on. (And your wife is 
slowly picking up her phone and dialing your therapist. Again.)

-
WebObjects - so easy that even Dave Avendasora can do it!(tm)
-
David Avendasora
Senior Software Abuser
Nekesto, Inc.
 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Using WO with modern dependency management

[Ramsey Gurley]

I’ve been trying maven in the last few days. I haven’t gotten a Hello WOrld to 
run yet. I’m updating the wiki getting started page as I go along. Most of the 
maven pages on the wiki appear to be last edited between 2009-2011.

On May 4, 2015, at 8:29 AM, Jean-François Veillette 
 wrote:

> At my previous workplace, we did the switch to Maven.  Luckily we had a real 
> maven expert to drive the move.
> We started with around 50+ projects, all ant based, using the ‘standard’ 
> fluffy-bunny layout.  He added pom.xml here and there, and everything just 
> started working with maven.  We had choice to build/run with maven and/or ant 
> and it was (almost) transparent.  The only exception was that if you decided 
> to use in maven, you had to change the class path to remove everything but 
> the maven and java dependencies (2 lines left), a simple .classpath that was 
> standard and could be copied from one project to the other.
> The maven build was then integrated with Jenkins (CI) and SonarQube (so that 
> future ‘JF’ is happy with old ‘JF’, and all the team's work are standardized 
> a bit) with ease.
> 
> From my experience, the team was happy with the Maven switch, none of us had 
> to become an expert (because we had one already).
> Maven help a lot on easing the dependency management of your apps (a building 
> block only declare his direct dependency).  Once you remove the noise of 
> declaring dependencies, you will be left with a clear graph of dependent 
> block.  You will then have to tackle the real problem of incompatible 
> dependencies (A need B and Xv1, but B need Xv2).  Maven will make the graph 
> simple and clear, it will try to provide helper but can’t really help much 
> after that.
> 
> jfv
> 
> 
>> On May 4, 2015, at 5:09 AM, David Avendasora  
>> wrote:
>> 
>>> On May 1, 2015, at 6:35 PM, Chuck Hill  wrote:
>>> 
>>> Maven seems like a better thought out and implemented solution.
>> 
>> …
>> 
>> Have you ever had one of those moments where things just seem so off-kilter 
>> you’re sure you’re having a dream, but no matter how many times you cry out 
>> for mommy you are left sitting there slowly realizing that there’s been some 
>> fundamental shift in the universe that you missed out on. (And your wife is 
>> slowly picking up her phone and dialing your therapist. Again.)
>> 
>> —
>> WebObjects - so easy that even Dave Avendasora can do it!™
>> —
>> David Avendasora
>> Senior Software Abuser
>> Nekesto, Inc.
> ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com
> 
> This email sent to rgur...@smarthealth.com

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Using WO with modern dependency management

[Ângelo Andrade Cirino]

So it seems we have a starting point.

> Em 04/05/2015, à(s) 05:36, Dennis Bliefernicht 
>  escreveu:
> 
> It's definitely a possibility and exactly what we did at Xyrality (after 
> going through a lot of pain trying to migrate to maven). We did a talk about 
> that at WOWODC 2015, if you have access to that; otherwise check out 
> https://github.com/Xyrality/gradle-wonder-plugin 
>  which is a basic plugin 
> implementation for WOnder development. You need to clone that repo and run 
> "gradle build publishToMavenLocal" in there to install it to your local 
> installation for now. After that you should be able to use it for your 
> projects. A basic example, we did, was to convert the Moves project from the 
> wonder/Examples/misc repository. Basically you just need to add the 
> build.gradle with these contents and run "gradle woapplication":

Ângelo Andrade Cirino
aacir...@gmail.com

"O homem sensato se adapta ao mundo. O insensato insiste em tentar adaptar o 
mundo a ele. Todo o progresso depende, portanto, do homem insensato"
Sir George Benard Shaw

"The reasonable man adapts himself to the world: the unreasonable one persists 
in trying to adapt the world to himself. Therefore all progress depends on the 
unreasonable man."
Sir George Benard Shaw


 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Using WO with modern dependency management

[Jean-François Veillette]

At my previous workplace, we did the switch to Maven.  Luckily we had a real 
maven expert to drive the move.
We started with around 50+ projects, all ant based, using the ‘standard’ 
fluffy-bunny layout.  He added pom.xml here and there, and everything just 
started working with maven.  We had choice to build/run with maven and/or ant 
and it was (almost) transparent.  The only exception was that if you decided to 
use in maven, you had to change the class path to remove everything but the 
maven and java dependencies (2 lines left), a simple .classpath that was 
standard and could be copied from one project to the other.
The maven build was then integrated with Jenkins (CI) and SonarQube (so that 
future ‘JF’ is happy with old ‘JF’, and all the team's work are standardized a 
bit) with ease.

From my experience, the team was happy with the Maven switch, none of us had to 
become an expert (because we had one already).
Maven help a lot on easing the dependency management of your apps (a building 
block only declare his direct dependency).  Once you remove the noise of 
declaring dependencies, you will be left with a clear graph of dependent block. 
 You will then have to tackle the real problem of incompatible dependencies (A 
need B and Xv1, but B need Xv2).  Maven will make the graph simple and clear, 
it will try to provide helper but can’t really help much after that.

jfv


> On May 4, 2015, at 5:09 AM, David Avendasora  
> wrote:
> 
>> On May 1, 2015, at 6:35 PM, Chuck Hill > > wrote:
>> 
>> Maven seems like a better thought out and implemented solution.
> 
> …
> 
> Have you ever had one of those moments where things just seem so off-kilter 
> you’re sure you’re having a dream, but no matter how many times you cry out 
> for mommy you are left sitting there slowly realizing that there’s been some 
> fundamental shift in the universe that you missed out on. (And your wife is 
> slowly picking up her phone and dialing your therapist. Again.)
> 
> —
> WebObjects - so easy that even Dave Avendasora can do it!™
> —
> David Avendasora
> Senior Software Abuser
> Nekesto, Inc.
 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Using WO with modern dependency management

[Chuck Hill]

I was wondering if anyone would notice that.  I am not saying that I am a Maven 
fanboy now, just that Ivy may be worse.  Or at least have some more 
questionable design decisions.   There is nothing in this world so bad that a 
few software engineers can't make worse.

Chuck


On 2015-05-04, 5:09 AM, "David Avendasora" wrote:

On May 1, 2015, at 6:35 PM, Chuck Hill 
mailto:ch...@gevityinc.com>> wrote:

Maven seems like a better thought out and implemented solution.

...

Have you ever had one of those moments where things just seem so off-kilter 
you're sure you're having a dream, but no matter how many times you cry out for 
mommy you are left sitting there slowly realizing that there's been some 
fundamental shift in the universe that you missed out on. (And your wife is 
slowly picking up her phone and dialing your therapist. Again.)

-
WebObjects - so easy that even Dave Avendasora can do it!(tm)
-
David Avendasora
Senior Software Abuser
Nekesto, Inc.





 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Using WO with modern dependency management

[David Avendasora]

> On May 1, 2015, at 6:35 PM, Chuck Hill  wrote:
> 
> Maven seems like a better thought out and implemented solution.

…

Have you ever had one of those moments where things just seem so off-kilter 
you’re sure you’re having a dream, but no matter how many times you cry out for 
mommy you are left sitting there slowly realizing that there’s been some 
fundamental shift in the universe that you missed out on. (And your wife is 
slowly picking up her phone and dialing your therapist. Again.)

—
WebObjects - so easy that even Dave Avendasora can do it!™
—
David Avendasora
Senior Software Abuser
Nekesto, Inc.





 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Using WO with modern dependency management

[Dennis Bliefernicht]

HI,

> On 02 May 2015, at 02:52, Ângelo Andrade Cirino  wrote:
> 
> Gradle has been mentioned a couple of times in the list. Would Gradle be a 
> definitive approach to modernize the whole build process?

It's definitely a possibility and exactly what we did at Xyrality (after going 
through a lot of pain trying to migrate to maven). We did a talk about that at 
WOWODC 2015, if you have access to that; otherwise check out 
https://github.com/Xyrality/gradle-wonder-plugin 
 which is a basic plugin 
implementation for WOnder development. You need to clone that repo and run 
"gradle build publishToMavenLocal" in there to install it to your local 
installation for now. After that you should be able to use it for your 
projects. A basic example, we did, was to convert the Moves project from the 
wonder/Examples/misc repository. Basically you just need to add the 
build.gradle with these contents and run "gradle woapplication":

> buildscript {
>   repositories {
>   mavenLocal()
>   mavenCentral()
>   }
> 
>   dependencies {
>   classpath 'com.xyrality.gradle:gradle-wonder-plugin:1.0.0'
>   }
> }
> 
> version = '1.2.3'
> 
> apply plugin: 'woapplication'
> 
> wonder {
>   wonderVersion = '6.1.2'
>   webobjectsVersion = '5.4.3'
>   applicationClass = 'er.movies.Application'
> 
>   deploymentServers = ['localhost']
>   deploymentSSHUser = 'wouser'
>   deploymentPath = '/home/wouser/apps'
>   deploymentSSHPort = 
>   deploymentMonitorBounceTasks = ['localhost':'Movies']
>   deploymentSSHIgnoreHostKey = true
> }
> 
> dependencies {
>   compile group: 'wonder.core', name: 'WOOgnl', version: 
> wonder.wonderVersion
>   compile group: 'com.webobjects', name: 'JavaXML', version: 
> wonder.webobjectsVersion
>   compile group: 'wonder.misc', name: 'ERChronic', version: 
> wonder.wonderVersion
>   compile group: 'wonder.ajax', name: 'Ajax', version: 
> wonder.wonderVersion
>   compile group: 'wonder.businesslogic', name: 'ERTaggable', version: 
> wonder.wonderVersion
>   compile group: 'wonder.businesslogic', name: 'ERAttachment', version: 
> wonder.wonderVersion
>   compile group: 'wonder.businesslogic', name: 'ERMoviesLogic', version: 
> wonder.wonderVersion
>   compile group: 'wonder.eof', name: 'ERRest', version: 
> wonder.wonderVersion
>   compile group: 'wonder.plugins', name: 'H2PlugIn', version: 
> wonder.wonderVersion
> }

Feel free to have a look at the plugin and file issues and pull requests, if 
something doesn't work out :-) It also features test support and some basic 
deployment via SSH and JavaMonitor.

We have been using this for about a year now successfully in building and 
continuous integration. The Gradle STS plugin for eclipse plays nice with 
WOLips as far as we can tell; you can import the converted project directly as 
a Gradle project. Multi-build should work as well (currently working on a 
15-subproject build).

If something breaks, go ahead and ask some more :-)
Greetings
Dennis

--
XYRALITY GmbH • Friedensallee 290 • 22763 Hamburg
Dennis Bliefernicht • Backend Development
Mail: dennis.blieferni...@xyrality.com 
Tel: +49 (0) 40 35 73 001 - 62
Fax: +49 (0) 40 35 73 001 - 99
Web: http://www.xyrality.com/ 
Registergericht: Hamburg HRB 115332
Geschäftsführer: Sven Ossenbrüggen


 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Using Ivy to manage dependencies in WO [was: Using WO with modern dependency management]

[Paul Hoadley]

On 3 May 2015, at 1:45 am, Hugi Thordarson  wrote:

> Since I started nagging I had to try out Ivy. My first impression is that it 
> works quite well and is easy to integrate with WO. Hope this helps someone, 
> I’m really enjoying my new dependency managed WO life so far.
> 
> https://www.youtube.com/watch?v=DtkgAAT91E0 
> 
Fantastic!  Thanks for that.


-- 
Paul Hoadley
http://logicsquad.net/


 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Using Ivy to manage dependencies in WO [was: Using WO with modern dependency management]

[Hugi Thordarson]

Since I started nagging I had to try out Ivy. My first impression is that it 
works quite well and is easy to integrate with WO. Hope this helps someone, I’m 
really enjoying my new dependency managed WO life so far.

https://www.youtube.com/watch?v=DtkgAAT91E0

——

** 1: Install Ivy for Eclipse. The URL for the update site is: 
http://www.apache.org/dist/ant/ivyde/updatesite/ . Make sure you only select 
the most recent versions of Ivy and IvyDE when installing.

** 2: Add a file called ivy.xml to the root of your project. This file contains 
information about your Ivy module and declares dependencies. Paste in the 
following code (I included a dependency on Gson so we can quickly ensure Ivy is 
working):








** 3: Right click the WO project you want to add dependency management to. 
Select “Properties -> Java Build Path -> Add Library -> IvyDE Managed 
Dependencies” and click “Finish”. Ivy is now in your Eclipse project and 
dependencies declared in ivy.xml will appear in the “Ivy" classpath container 
of your project. In oter words; you can start using Gson while developing 
within Eclipse. But we still have a couple of things to do to make Ivy work in 
your ant-builds.

** 4: Modify your build.xml to use Ivy for resolving dependencies:

a) Define the Ivy namespace declaration in the  tag:



b) Add a target for resolving dependencies using Ivy:





c) Finally, make the "init.build" target depend on the "resolve" target.



** 5: Install the ivy ant-task on your build machine (if you have one). One way 
to do that is to download the .jar from Ivy’s site and put it in ~/.ant/lib

Cheers,
- hugi

// Hugi Thordarson
// http://www.loftfar.is/
// s. 895-6688



> On 1. maí 2015, at 23:28, Paul Hoadley  wrote:
> 
> On 2 May 2015, at 7:52 am, Hugi Thordarson  wrote:
> 
>> Most of our in-house code is written as pure java/scala projects which are 
>> then built, versioned and deployed to a local Maven server using Maven and 
>> SBT.
>> 
>> We use WO a lot but maintaining the WO applications “old style” (by copying 
>> dependencies into “Libraries” every time something changes) is becoming 
>> quite tiresome. So I’m wondering if anyone would care to share success 
>> stories or tips on methodology for dependency management with WO? Some years 
>> ago I heard of people using Ivy for dependency management in the WO ant 
>> scripts, but haven’t heard much about it since.
>> 
>> We did try using Maven for all WO development, but I found that WOLips 
>> didn’t really like it. Perhaps that’s working better now?
> 
> We don’t use Maven, but I’m interested in the topic.  Henrique Prange would 
> be the local expert on this.
> 
> 
> -- 
> Paul Hoadley
> http://logicsquad.net/
> 
> 

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Using WO with modern dependency management

[Ângelo Andrade Cirino]

Gradle has been mentioned a couple of times in the list. Would Gradle be a 
definitive approach to modernize the whole build process?

Angelo

> Em 01/05/2015, à(s) 19:22, Hugi Thordarson  escreveu:
> 
> Hi all.
> 
> Most of our in-house code is written as pure java/scala projects which are 
> then built, versioned and deployed to a local Maven server using Maven and 
> SBT.
> 
> We use WO a lot but maintaining the WO applications “old style” (by copying 
> dependencies into “Libraries” every time something changes) is becoming quite 
> tiresome. So I’m wondering if anyone would care to share success stories or 
> tips on methodology for dependency management with WO? Some years ago I heard 
> of people using Ivy for dependency management in the WO ant scripts, but 
> haven’t heard much about it since.
> 
> We did try using Maven for all WO development, but I found that WOLips didn’t 
> really like it. Perhaps that’s working better now?
> 
> Cheers,
> - hugi
> 
> // Hugi Thordarson
> // http://www.loftfar.is/ 
> // s. 895-6688
> 
> 
> 
> ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/aacirino%40gmail.com
> 
> This email sent to aacir...@gmail.com

Ângelo Andrade Cirino
aacir...@gmail.com

"O homem sensato se adapta ao mundo. O insensato insiste em tentar adaptar o 
mundo a ele. Todo o progresso depende, portanto, do homem insensato"
Sir George Benard Shaw

"The reasonable man adapts himself to the world: the unreasonable one persists 
in trying to adapt the world to himself. Therefore all progress depends on the 
unreasonable man."
Sir George Benard Shaw

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Using WO with modern dependency management

[Paul Hoadley]

On 2 May 2015, at 7:52 am, Hugi Thordarson  wrote:

> Most of our in-house code is written as pure java/scala projects which are 
> then built, versioned and deployed to a local Maven server using Maven and 
> SBT.
> 
> We use WO a lot but maintaining the WO applications “old style” (by copying 
> dependencies into “Libraries” every time something changes) is becoming quite 
> tiresome. So I’m wondering if anyone would care to share success stories or 
> tips on methodology for dependency management with WO? Some years ago I heard 
> of people using Ivy for dependency management in the WO ant scripts, but 
> haven’t heard much about it since.
> 
> We did try using Maven for all WO development, but I found that WOLips didn’t 
> really like it. Perhaps that’s working better now?

We don’t use Maven, but I’m interested in the topic.  Henrique Prange would be 
the local expert on this.


-- 
Paul Hoadley
http://logicsquad.net/



 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Using WO with modern dependency management

[Hugi Thordarson]

Well, yes… Maven is probably better thought out since Ivy is basically a hack 
for Ant to implement a tiny part of Maven (the dependency management). And I’d 
definitely like to use Maven to build my WO projects but my experience trying 
to do that was not very nice. Quite a few manual steps involved in getting 
projects to work. If we could fix that, that would most definitely be the 
optimal solution (and I’m definitely willing to pitch in work on WOLips for 
that).

This is the one aspect of WO development that makes me feel like I’m going back 
in time when I open a WO project. Even javascript has decent dependency 
management.

- hugi


> On 1. maí 2015, at 22:35, Chuck Hill  wrote:
> 
> From what I have seen of Ivy, Maven seems like a better thought out and 
> implemented solution.  WO might need better m2e plugin that in WOLips aware.
> 
> Chuck
> 
> 
> On 2015-05-01, 3:22 PM, "Hugi Thordarson" wrote:
> 
> Hi all.
> 
> Most of our in-house code is written as pure java/scala projects which are 
> then built, versioned and deployed to a local Maven server using Maven and 
> SBT.
> 
> We use WO a lot but maintaining the WO applications “old style” (by copying 
> dependencies into “Libraries” every time something changes) is becoming quite 
> tiresome. So I’m wondering if anyone would care to share success stories or 
> tips on methodology for dependency management with WO? Some years ago I heard 
> of people using Ivy for dependency management in the WO ant scripts, but 
> haven’t heard much about it since.
> 
> We did try using Maven for all WO development, but I found that WOLips didn’t 
> really like it. Perhaps that’s working better now?
> 
> Cheers,
> - hugi
> 
> // Hugi Thordarson
> // http://www.loftfar.is/ 
> // s. 895-6688
 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Using WO with modern dependency management

[Chuck Hill]

>From what I have seen of Ivy, Maven seems like a better thought out and 
>implemented solution.  WO might need better m2e plugin that in WOLips aware.

Chuck


On 2015-05-01, 3:22 PM, "Hugi Thordarson" wrote:

Hi all.

Most of our in-house code is written as pure java/scala projects which are then 
built, versioned and deployed to a local Maven server using Maven and SBT.

We use WO a lot but maintaining the WO applications "old style" (by copying 
dependencies into "Libraries" every time something changes) is becoming quite 
tiresome. So I'm wondering if anyone would care to share success stories or 
tips on methodology for dependency management with WO? Some years ago I heard 
of people using Ivy for dependency management in the WO ant scripts, but 
haven't heard much about it since.

We did try using Maven for all WO development, but I found that WOLips didn't 
really like it. Perhaps that's working better now?

Cheers,
- hugi

// Hugi Thordarson
// http://www.loftfar.is/
// s. 895-6688



 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Using WO with modern dependency management

[Hugi Thordarson]

Hi all.

Most of our in-house code is written as pure java/scala projects which are then 
built, versioned and deployed to a local Maven server using Maven and SBT.

We use WO a lot but maintaining the WO applications “old style” (by copying 
dependencies into “Libraries” every time something changes) is becoming quite 
tiresome. So I’m wondering if anyone would care to share success stories or 
tips on methodology for dependency management with WO? Some years ago I heard 
of people using Ivy for dependency management in the WO ant scripts, but 
haven’t heard much about it since.

We did try using Maven for all WO development, but I found that WOLips didn’t 
really like it. Perhaps that’s working better now?

Cheers,
- hugi

// Hugi Thordarson
// http://www.loftfar.is/ 
// s. 895-6688



 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com