why does the lib folder in the framework have a flat directory structure?

[Brian Nesbitt]

When you look at all of the jars in the lib folder I wonder why they aren't organized into subfolders and only maybe the shared jars in the root.

I can see how the current flat directory structure makes it easy to upgrade a package, just copy and paste it in and don't worry about conflicts.

I thought about this when I was actually about to submit a patch that built the classpath properly but still allowed the application_path/lib folder to be organized into sub-directories. 

Thoughts?

[grandfatha]

What I am missing is a folder "lib/managed" which only contains the
jars downloaded by the dependency management tool, so that it wont
complain about non-managed, unsynced dependencies in the base lib
folder that I put there (local jar files not contained in any repo).

[GrailsDeveloper]

+1
Sounds like a good improvement for me.
Niels

[Brian Nesbitt]

After reading more about the dependencies.xml system I am not sure if this is an issue for most people managing their external jar files in their own application/lib directory.  The other thing I personally do is like to have the source zip for code browsing when necessary in the IDE.  Of course when you run play dependencies --sync it deletes these.

What I would like to see in the application/lib folder is the following structure:

application

   app

   conf

   lib

      commonfile.jar

      commonfile2.jar

      dep1

         d1.jar

         d2.jar

         srcfiles.zip

      dep2

         d3.jar

         srcfiles.zip

I have a path for application.py that recursively adds jar files to the classpath so it works with the current "put all jars in the lib folder" and works with this more custom style of managing external libs.

I guess I'll submit it as a patch and see what the play team thinks.

[Brian Nesbitt]

Seems as though the flat directory in a /lib is part of the J2EE deployment BluePrint guidelines.  I can see how it helps prevent duplicates/conflicts from happening and how the dependencies.yml system tries to correct this but I still think makes it harder to upgrade packages.

Doubt this matters anyway since not much in play follows J2EE standards... thank god !  :-)

[Nicolas Leroux]

This should be fixed in the master and 1.2.x branch.

Nicolas

On Aug 31, 2011, at 6:17 PM, Brian Nesbitt wrote:

Seems as though the flat directory in a /lib is part of the J2EE deployment BluePrint guidelines.  I can see how it helps prevent duplicates/conflicts from happening and how the dependencies.yml system tries to correct this but I still think makes it harder to upgrade packages.

Doubt this matters anyway since not much in play follows J2EE standards... thank god !  :-)

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/L4GZ0eIzB-wJ.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

[grandfatha]

On Aug 31, 10:28 pm, Nicolas Leroux <leroux.nico...@gmail.com> wrote:
> This should be fixed in the master and 1.2.x branch.
>

What exactly? The nested folders? The source/doc attachments?

[Nicolas Leroux]

The nested folders.

Nicolas

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.

[Brian Nesbitt]

Ya the patch creates the classpath by searching recursively in the application/lib folder for jar's rather than just in the root of that folder.

[hyder]

Hi, 

Would we still need to specify the deps in the dependencies file? 

Please advise.

[Brian Nesbitt]

Ya, this is only for jars you want to manage yourself.  It allows you to organize your jars into subfolders rather than just in the root.