Shared publicly  - 
Calling for use cases for Dart package system

What do you need a package system to do? What problems do you have? What would you like to accomplish? The Dart team wants to know!

Please don't say "build npm or bundler", instead, let us know what problems you need solving. We'll collect your feedback and look at the existing systems out there for inspiration and familiarity.

I deliberately left "package system" vague in the hopes of catching a wide array of use cases. Use your imaginations. :)

Thanks in advance, your input is important to us.

#dartlang #dartpackage
Stefan Hoth's profile photoTyler Van Gorder's profile photocesar abril's profile photoLuigi Agosti's profile photo
We were talking about npm at a meetup last night, and one of the challenges that was mentioned with it was that it was server-side only.

Understanding that the server and client are very different environments, it would be interesting if there was a way to specificy something like a Gemfile for a Dart app which worked on both the server and the client. The actual libraries may be loaded differently.
Another issue would be the ability to support loading specific versions of gems so that supported dependency versions could be specified.
Thanks +Mark Bennett, can you elaborate on use cases for a "gemfile for a dart app" would need to do?
+Seth Ladd Well typically I use a Gemfile on the server to a) install my dependencies, b) ensure my dependencies are consistent across platforms and installs, c) make my dependencies available at runtime.

Right now most packaging solutions can satisfy these requirements on the server.

In the case of npm, this is an interesting problem since even though it's JS the libraries load synchronously on the server. In a web client speed is a concern, and blocking JS until all the dependencies are loaded is impractical. Instead an asychronous solution is preferred. These same issues would probably apply to Dart on the client. So having an asychronously loading system would be great.

Another option that would be usefull for the client would be being able to load the dependencies in groups. For example, load a barebones set of dependencies which are needed to display a loader, trigger a callback to render the loader js, then continue loading another group of dependencies.
Also, is there any interest in a general resource loader that could be used to load packages of application resources (images, textures, sounds, etc.)

I would be more in favour of keeping the design simple, but if a general purpose resource loader was possible it would be a useful model for web applications which depend on resources as much as code.
1. Once your project reaches a certain size, you have no choice but to start using strange naming conventions to avoid name collisions. Packages, at least from what I've seen for decently sized projects, solve this problem.

Lua has the same problem with _G, ActionScript 1 had the same problem with _global, ActionScript 2 and JavaScript had the same problem with Object.prototype (or even some whack closure solution).

While Python's flexibility with functions/packages is nice, I'd argue on the client, you tend to have a lot more code, especially once you start using something like Dart.

2. Libraries. Talk to +Cliff Hall , or read some of his posts on here. The whole naming prefix, etc. just doesn't scale, and is a burden on the developer to learn. It's worse in team environments, especially if someone fails to enforce it.

Example, would you rather learn this:

or this:

(open class list on top left):

It's also called "f'ing stupid" just in case you were curious.

When distrubiting code, there are 3 things you're concerned about.

A) ensuring it works, without muss/fuss in any project, configurations, etc. Drop the code in, import it, go to town.
B) you can copy pasta the code w/o worrying about folders. On PC this is easy, on Mac, it's a manual process. Either way, with Java packages, it's easy to organize this ( at the beginning of a project anyway ).
C) Branding. Having your name/company/project embedded in the package name itself is huge. For example, most Flash Developers worth their salt know Greensock merely from the package name.

Object models are one thing (like Ext JS's recent switch from 3 to 4 to abandon prototype and ensure they don't pollute it + support multiple app instances on the same page).

However, actual files + libs are huge here.

3. Segregation.

On multi-team projects, you need to organize code. Whether this is MVC/MVP/MVVM/YourMom, at a framework level is a large swath of folders.

Secondly, types of View's. When doing GUI work, you tend to have a steady growth of GUI code; forms, components, item renderers, util classes, etc. These are also segregated out into sections, and sometimes entire teams just remain there.

Third, this segregation helps architects and build masters do manual diffing and testing.

4. Privacy

For some libraries, they need to hide certain packages; whether from the IDE, the developer, and/or the runtime. These are usually like helper/final/private functions, classes, etc. that all live in a private package. The vendor can thus keep their public API the same, but change their internal application within a team environment using the above.

I abhor this practice, but understand people need it, so....


1. Large project code organization
2. Libraries: usage & deployment
3. Segregation: team focus & easier diffing/source control/team management
4. Privacy: <-- dumb, but people will buy it
Something like Maven... An opportunity to declare libs on which the project depends, fetch them automatically if they haven't been fetched yet, and store them in an project-independent directory (to share w/ other projects).

When you declare lib dependencies of your project, one should be able to determine:

* a specific lib version or
* a lib version range or
* a min lib version.
A HUGE +1 for Maven. If Dart is done in the "Maven way", I'll be completely sold and start using and advocating it TODAY.
Friends don't let friends use Maven.
+Alexander Orlov Dart libraries are already fetchable by URI, and importable by URI. Does this change your vision?
Thanks for all the feedback everyone. Try to think outside of the system you are using today. Go back to use cases, what are you trying to accomplish?
While I like the concept of Maven, please don't adopt it's massive XML syntax. I still really like the simple syntax of Gemfiles and have found them much easier than Maven to troubleshoot and maintain.
+Alexander Orlov I support your idea but I doubt a "min lib version" dependency specifier is useful. This could break your application sometime in the future when your dependency's API changes. Because you are saying "take any version of this dependency equal or greater than what I have specified". npm has this problem with fuzzy version specifiers and they are thinking about dropping this feature in favor of reduced complexity.
Packaging in my mind is the intersection between the folder structure of an app or library and the namespacing used to fully qualify classes at runtime.

Folder structure allows us to make important organizational separations on our codebase. All the files in one big folder doesn't cut it. For instance, if you're writing an application according to MVC principles (regardless of the enabling framework) you should be able to take all the Model-related classes and move them to a separate library so that they can serve different applications, such as mobile, web, and desktop variations of the same app.

Namespacing of classes at runtime allows us to make important qualifications about the code being referenced in the current scope, so that we can use the class:
and the class:
in the same scope.

Fully qualifying a class with its package should only be required if you're using two classes with the same name from different packages in the same scope.

For instance if I were writing a PureMVC Proxy subclass, and it created a Flash Proxy class, then I would import flash.utils.Proxy and when I create a new one, I'd qualify it: new flash.utils.Proxy(). However if that same PureMVC Proxy subclass were to use a flash.utils.ByteArray, I would import flash.utils.ByteArray, but I would not have to qualify it because it doesn't conflict with any other ByteArray class I have imported. So I'd just do new ByteArray().

The namespacing I just described (ActionScript's) is different from Dart prefixes because you only have to fully qualify a class if it conflicts. With Dart prefixes, you have to use that prefix on every class in library whether it conflicts with any other imported classes or not.

To bring this home: by marrying folder structure with namespacing, you can easily enable the IDE to give you auto complete on package declarations, since the package should match up with the folder hierarchy.

Consider this class:

It lives in this folder in my project:

And has this package declaration the top of the class:
package org.puremvc.as3.multicore.patterns.proxy

It's pretty easy for the IDE to give me autocomplete so that I don't have to type that long (but unique and appropriate) package declaration. And it's also pretty easy in a large app for me to find my classes in the filesystem.

Also, it has a unique package structure that I control, because it uses a domain I own. No one else would have reason to use that folder structure. Of course you don't have to use 'reverse domain'-style namespacing in your app or library, but it helps and is a common idiom in Java and other languages.

- Marry folder structure to namespacing for IDE (and mental) autocomplete.
- Don't require fully-qualified classnames except where there is a collision between imported classes in the current scope.
- Also, classes in the same package should not have to import each other for use.
I would really like some dependency managment/fetching solution.
I would really like to say (in a json? format)

This folder contains project
dart-hbase version 0.9

it depends on
dart-thrift version 0.8
someother library version 0.3

and for development/building i also need
some-awesome-dev-library 0.3

and then the package management can go ahead and put them into some folder local to my project so that the vm/browser can look them up.
+Seth Ladd Yes, this changes my vision in respect to fetching. But when there are huge libs, they should be cached/"stored" in some way locally but I guess it's a general Dart lib caching problem.

But the lib version constraints (a particular version & a version range) proposal remains.

Your problem-driven resp. use case driven questioning is right. What we're using today isn't always exactly what solve the problems we have. Actually many additional problems are created by the tools we use today, incl. Maven.

+Sven Jacobs Agree. An implicit "min version" is set once your app works. And this "min version" is mostly the version of the last "release". But if any future lib release breaks the API, you can use the version range.

+Jesse Warden Any real arguments against Maven? Once it's set up and running, it's a huge time-saver.
+Alexander Orlov Tongue in cheek, bro. As a consultant, I got 99 problems and Continuous Integration ain't one.
I think there are two levels on which packaging issues come up.
The micro level is inside an application or library. I want to develop the different parts of an application independently from each other. I want to define what the public interface is a part provides to other parts of the application and I want to define what it needs to deliver it's services.
On the macro level are the dependencies of an application to the world outside. Since different parts of the application may need different versions of the same library, it somehow has to handle that versioning clash.
Also interesting is how I can configure a package with another package. As an example take the unittesting framework from the bleeding_edge branch. I want to run tests in Dart VM and in a browser. Could there be some standard for pluging the chosen runner into the testing library. What if I wanted to develop an own runner for it.
So far, it seems there are two different idea groups forming that seem unrelated, but really just reflect at what 'level' where your focus lies in the organizational continuum of a large-scale project.

1. At the Micro level is...
Organization of the classes within a library, and how code referring to imported classes is written. This is about folder organization and namespaces. It probably needs addressing with changes or additions to the language e.g., a package keyword for declaring what package a class or method is in. Also changes in the Editor to give you auto-complete and show actual complete folder structures.

2. At the Macro level is...
Management of dependencies between all the bundles of software that are needed to build a given app. Those can be installed 3rd party libraries, or in-house libraries in your workspace that are used by one or more apps. This also logically touches on versioning and ensuring that the right versions of all dependencies are kept straight for each version of the app. This will probably need addressing with tooling, and project descriptor / metadata files of some sort. And changes to the editor to integrate the build system and allow recompilation of dependent projects on the fly when say, a library project has changed, and you compile an app that requires that project.

These are both very important, and I hope they're both identified and addressed, though I'm not sure they have to be coupled together as one problem to be solved. It could be done incrementally.

I believe the Micro level would probably be easiest to implement, and the logical place to start. Before building the machinery to ship and store crates, figure out how to make the crates themselves. The unwieldiness of building reusable libraries right now (like naming Proxy 'MVCProxy' to avoid namespace collision) will limit developers coming to the platform to build those libraries, so it won't matter how shiny and awesome your build process is.

The Macro level would require a lot of moving parts and serious thought given to scope and metadata expression, not to mention whether to integrate/leverage popular tools like Maven (or at least Ant) or just to be informed by them and build from scratch. Only once there are lots of libraries available for Dart, devs are going to flood into the platform, and build big stuff. They will need - and expect - this tooling.

IMHO, the pioneers who are building the early libraries and demos to attract the dev community (and eventually the enterprise) need to be convinced that the language will hold water. And if they have to prepend every class in their library with an acronym to avoid collisions with other classes that may use the same common names, then they're not going to be convinced and the critical mass necessary to pull in the masses will not be achieved.
+Seth Ladd

My desires:
* It should be easy for someone expose their library to the masses for consumptions ( package manager that can grab from github, package list providers, etc)
* It should be easy for someone to add metadata to a project for package aggregators to find, show up on a web page, and search through ( don't do some complicated XML format, it should be simple enough to open in notepad and be human readable)
* I really want to know how well packages have been maintained, I want to be able to determine crap projects from the good maintained ones.
* I want to be able to easily get to the library makers website to know how to use a package
* I really want an easy way to grab common sets of packages I use in projects both narrowly and broadly ( npm link is a great example, just define what I want in a .json file, specific versions or latest versions, npm link, and its grabbed locally for use)

That's all for now
+Robert Beeger Funny, I totally missed your comment before posting mine, but we were on the same wavelength to the nanometer :)
One of the BEST things Sonatype recently did with making submissions to maven central was the requirement to have valid metadata in your packages - such as URLs, authors, license, and also having the package GPG signed so you know who submitted a package. This is assuming you're wanting to build a "central repository".
This is a very hard question that amounts to discussing and comparing the objectives of modularity devices in programming languages. It would be nice if unification of modularity devices was a main objective in the design of programming language. In ADA the concepts of package and task were not unified. In Smalltalk the category and class were not unified. The class mechanism is also a modularity device usually not integrated with other ones. In summary, unification of modularity mechanisms has been a failure since the first work of D. Parnas. Even N. Wirth could not find a suitable solution in his Modula language. The concept of aspect in AOP was a complete failure, even if it helped to show the need for non-standard modular devices in addition to standard class inheritance. Is there a possible solution or are we doomed to see a number of poorly composable modularity devices (package, class, method, function, process, closure, etc.) proposed in each new programming language?
Packages would need to be able to be easily accessed through a HTTP proxy.
Just thinking out loud (not all things bellow may make sense).
- It should mprove readability. For eg. one should be able to write, s = new http.Server() or t = new tcp.Socket() or i = new svg.Element().
- The import statement should also say where to find the package. This will avoid any needs for extra files(xml or others) required to build the code.
- It can help making code implementation independent. For eg: There might be different gui packages for web and native desktop. Some how the language should be able to figure out which one is meant depending on the platform.
I have three different use cases, and a general note. I think much of this has been said in some way or another by other posters, but here goes:

Namespaces for Code

Importing all symbols from a library into the local scope is dangerous - changes in the upstream library can break your code, in possibly very hard to detect ways (e.g. superclass method shadowed by a newly added function in some library you import). Make it easy to explicitly import the particular symbols that your code uses - this also makes it much easier to find out which library that "foo()" function came from.

Prefixes are problematic - different code units that use the same code look different, because the author decided to use different prefixes. This makes it much harder to read other peoples (and sometimes your own) code. Code that uses the same library should look the same. Have the library author define how people should refer to his code. Possibly allow optional renaming if there's a name clash, or just require fully qualified names for that.

Imports should be explicitly stated in every compilation unit (source file). Reading source code is hard, and first having to find the file that #source's this particular file, to then find out what that file imports, just to find out where that "foo()" function came from makes it much, much harder.

All of these more or less cover the same use case: I want to write code, be sure it doesn't break because of an upstream library change, make sure it's easy to read and understand locally, and also make sure it's compatible across different files. Having the same names in all code also makes it much easier to transport code from one library to another. E.g., if someone imports dart:html with prefix "h" (because it's shorter), and I import it with "html" (because it's clearer), our code not only looks different, it's also much harder to copy whatever I did into his library.

Imports should be independent of physical location

Project layouts differ, even in one project, for example when I have different ways of checking out the same code, possibly only partially. Code should not be coupled to a local environment of physical file locations. I want to import a library by some name, or some canonical path, but be able to move my source files around freely without having to adjust all imports in every file. It'd actually be preferable to not have relative imports, i.e. always having to spell out "import net.rpc.blah", even if the code that's importing is already in "net.rpc"; it's not much typing and makes things much more explicit and readable (another indirection step saved when reading code).

This also touches import compatibiltiy between different projects. If I have some code in project A which has it's libraries in "/lib/", and someone else has his libraries in "/third_party/", I should still be able to use his code, independent of the difference in project layout. I also don't want to have to understand someone else's project layout to be able to understand his code.

This is also important for imports. I don't want to import files off some location on the net; it's much too fragile for my nightly builds, it gets hard together with versioning (see below), and of coure it's a huge security risk - I cannot audit the code and be sure my local copy is ok. So I will have to download the files and copy them somewhere. Now if the imports in the library are physical file locations, I will have to adjust all of them to fit my local project layout. This is not only work, it also makes upgrading much harder than it should be. This is also important for package managers - they'll have code in some location, e.g. in "~/.dartlibs/...". Now if there are multiple package managers, or code wants to be usable without a package manager, physical imports break - the imports would need to be adjusted.

Dart also needs to support multiple "root locations" for imports. If my project uses some package manager, but also has its own libraries, it must be possible to e.g. first search $project/lib, then search ~/.dartlibs for an imported library.

Versioning / Dependencies

Dart currently supports running different versions of a library in one "binary". I think this is very dangerous; if your code ends up passing objects from library A v1 to library A v2, random breakage might occur, and it will be extremely hard to debug and trace. I'd rather have my code fail fast and hard if the same symbol is imported from multiple locations; I think it's safe to assume that this is always a bug.

I'd love if we had some declarative way to express dependencies on other libraries with versions, but I would absolutely keep it out of the source code itself. If I upgrade from some library in version 1 to version 2 and have to adjust all my imports for that, it's not only a lot of work and version control noise, it's also quite easy to forget one place and end up in version hell, see the previous paragraph about that.

Developer Productivity

All of this should work without any mandatory preprocessing/build step. Triggering a compile run after every change just kills productivity, and it's IMHO even problematic if you have an IDE that constantly compiles in the background (also, it should be possible to program Dart just using plain vanilla vim, or even Emacs if it's absolutely necessary).

I think it'd be absolutely ok to require running a simple server that serves Dart libraries by searching through some lookup path, though.
A meta request- A website hosting a registry of Dart libraries available with their API documentation generated from dartdoc. I'm thinking something like the Chrome Web Store focused on Dart libraries and frameworks.
Just as I've stated in the group discussion..

"It would be nice to support profiles for creating the strucutre of the
most common applications out there. For instance:
* dart pm create-new-project -profile=server-side-with-database-and
* ... --profile=json-client-with-templates
* ... --profiles=templates, maps, html, json
This would:
1) Ease the way developers start to learn/build their Dart apps (does
anyone remember when they started to learn Maven or Ant? :-s)
2) Fasten project initial structure by Nfold by eliminating the burden
of finding all dependencies to satisfy a project needs.
One could also add a profile to a current app. "
Educational use case (virtual labs, etc):
* one file package - easy distribution
* contains code + multimedia
* one click launch on desktops
* easy integrates in web page with ability to develop external interface for communicating with LMS, etc
Something similar to swf (forgive me for mentioning flash :) )
Ignoring the issue of namespaces for the time being, I'd like to focus on the social side of a package management system.

IMO, one of the most successful aspects of +node.js and +Ruby is that they both have a single central repository for sharing a unit of code in a well understood way (npm and RubyGem respectively.) These are successful because they make it simple to share and depend on code written by others, and allow best-practices and code to quickly disseminate across the developer base. In turn, this has lead to an explosion of interest in these platforms as the tools to build awesome apps become easily and quickly accessible.

The key characteristics of a package management system would be:

1. Enable sharing of code between projects
2. Facilitate discovery of existing code
3. Eliminate barriers to publishing code

From these three tenants a lot of the other requirements follow, like dependency and version management. Keeping the packaging system simple is also important as it makes publishing and sharing accessible to the broadest possible audience.

The social aspect is also important as it's a showcase for the successes of the Dart community. Imagine a site which combines RubyGems, RubyToolbox, and GitHub into a single Dart community. You could follow and connect with your favorite dart packages and authors. Discovery would be enabled through search and a system for rating and tagging related packages. The site could include help documents to smooth first time publishers through getting started.

In terms of verbage, I was thinking the public repo could be called "The Dartboard' and each package could be called a "dart".

I recognize this may be less technical than what you're looking for, but I strongly believe that sharing, discovery, and publishing should be the key principals guiding the design of the packaging system.
Most people have covered the basics but I would like to emphasize the core functionality of searching, acquiring and managing 3rd-party libraries. This covers version and dependency resolution and goodies like search functionality which doesn't suck.


* Built-in bug reporting and management. If something goes wrong, I want to have the ability to report it easily or, at the very least, ask the package management tool for info on how to get in contact with maintainers.

* Sensible tools for building production software bundles which include dependencies and the like for self-contained apps where needed and easy deploys. Using 3rd-party libraries should not mean headaches when it comes time to push software into production. This implies build-tool integration and the like.

* Baked-in test support. When I install a library, I would love the ability to run its unit tests both as sanity check for my environment in general as well as in the context of my actual project! I idealize a world in which I could run the full test suite of not only my app but also the libraries on which it depends. I have no idea if such a thing could work but I feel it might help me as the developer catch bugs but also might provide very valuable feedback to maintainers as different tests fail under in different circumstances.
+Jonathan Magen totally agree. Those are all great suggestions, especially the ability to run the tests for my dependencies.
Client side "library designer" use cases:
- Publish my client side lib as a specific version
- my lib is made up from .dart files, template files and other resources (css, png any other arbitary fileetc...)

Client side "User" use cases:
For "dartium"
- Retrieval of a specific version of a lib by URI
- Retrieval of the "most recent" version by URI
- Specification of a version by range, gt or lt
Additionally, for "dart2js"
- Download and locally cache (treat as server side).
- When I deploy my dart2js converted lib, it should make resources that were part of the original library either available somewhere in the output .js path, or refer to the original locations of the resource (I'm not sure which)

Server side "library designer" use cases:
- Publish my server side lib
- my lib is made up from .dart files, template files and other resources (any arbitary file)

Server side "user" use cases:
- Retrieval of a specific verison of a lib by URI
- Retrieval of a most recent version by URI
- Specification of a version by range, gt or lt.

In terms of retrieving a lib by URI, I'd expect it to be cached locally on my machine when developing (to aid debugging etc) - I don't always have internet access.

Profiles of some kind would be good, such that you flick a switch (or some config setting), and I would get a different (compatible) library across the system (eg, for mocking and unit testing) - maybe something like
(this is something that I use a lot in Java, when we are building against "corporate enterprise" systems - we'll develop against mocks, and releast for test against the real version) - it is also useful for unit testing. Imagine being able to switch dart:html with mock:dart:html to run unit tests

Supporting different versions of a library as a "library user":
I would like to be able to import Library-2.0 into my app, even if some dependency uses Library-1.0 internally (ie, Library-2.0 and Library-1.0 are treated as different libraries - but I'd expect the tools to be able to provide an indication that I have different versions of the same library).

I'd also expect that if Library-2.0 is imported by a dependency, and directly by my app, then it would only be imported once.
(This means that there should be some way to uniquely identify libraries - we can't have 10 libraries all called "logger" from different location)

I'd would like the library version to be specified as part of the #import statement, rather than in some separate config file - this is fine if different versions of libraries are treated as different libraries - (but again, I'd expect the tools to be able to provide an indication that I have different versions of a library).

Not too much to ask I hope! :)
Hi all,
sorry this is not a real use case ... but I don't see here anything referring on something like OSGi (or the ability to provide bundles of libraries, declaring dependencies inside and what is exported to the outside), useful to reduce the risk of the famous "jar hell" when using many different libraries (with related dependencies) that in big projects happens many times ... unless Dart solved this at language level.
Capabilities. I want to say: import http://service...
As i do now with javascripttags.
But with customisable sandbox. And this should be declared in the package manager.
Link http://... as gplus allow, local store.
Should also include quota for mem/cpu, so that such services can be importet serverside.
+Jesse Warden True that. But, Dart folks take note, at least you only have to fully qualify if you use both classes in the same scope, and you don't have to fully qualify every class in the library. That is still better than Dart prefixes. This is worst case name collision handling with ActionScript/Java style packaging.
The goal I would ask my self is; Can I put my project in an repository and have another download/clone it with out having to make any modifications and run it. I think when you accomplish this goal, everything could fall into place.

The major downside to Java projects is it has a classpath and this classpath is OS specific (having absolute paths). Maven saves the day with this although I wish it could be a default. A similar system would be nice in Dart.
The two conceptual areas I think of when someone mentions "package system":

"Packages/Name Spaces"

The use of packages/name spaces to organize both code and other resources in a
hierarchical structure.

In the enterprise applications that I have worked on, one thing I have really
grown to appreciate is when name space organization matches that of the
structure on the file system. There is something to be said when I can reliably
browse a code base outside the context of an IDE and the file structure matches
the structure defined by the language's "package system". I do not like having
to "search" for keywords in a project to find the damn source.

Being able to define the dependent packages/name spaces, allows better tooling
support and code insight. The thing that drives me crazy about Javascript is
that I have yet to see a reliable IDE experience that allows for code insight,
refactoring, and code navigation. These are things I have grown to expect when
working with Java or .NET and I understand that those features can be harder
with a loosely typed language. However, if Dart is going to allow for the
optional use of stronger typing, why not take advantage of that in the tools. I
do NOT want to do my coding in notepad, ultra edit, vi... (or insert any other
of your favorite text editors + plug-in crap here) The DART editor needs to
feel like an IDE....period. And having a good package/name space system will
greatly improve this experience.


Given the above description of "Packages/Name Spaces", libriaries are collections
of those packages as a bundle. The packaging of a library should be formal and
any of the meta-data used to describe a library should be available at both
build time and runtime.

- A library will explicitly define any dependencies it has with other libraries.
A dependency must be expressed as an ID + version range. The OSGI module system
is a good example of this.
- A library must explicitly define which packages it exposes to "down stream"
dependents. Again, the OSGI module system provides an example of this. This
allows a libary to encapsulate resources it has no intention of allowing
external libraries to see. I don't like reading "don't use any classes in the
org.apache.coolproject.internal package." If its not intended for external use
then a library should have the ability to explicitly hide those types of
resources. I think this sort of meta-data should live at the "library" level
and is different then declaring a class "private"
- A federated repository system that allows libraries to be published for others
to consume. I know that this can get messy and I would like to avoid having
to define mutliple repositories in some silly XML configuration file. (Like a
POM). Or having a default POM, and extend that with a project POM which contains
other repository definitions, and a dependent POM with yet more respository
definitions. Bleh. It would be much nicer to to point to a single repository and
have it figure out which other repositories need to be consulted to find the
library dependencies.
- First class tooling to enforce the formal definition of a library
- The ability to enforce the langauge rules for a library at build time.
- The ability to search for 3rd party dependencies from the tooling. "Hey
Repostitories, go find 'logj4 version 1.blah' and download load it for me."
Add a comment...