From: "Brett Porter" <[EMAIL PROTECTED]> > > 1) Project xml and Project properties. > Utilising certain plugins requires properites, > and we can only get around that by making the POM extensible. I think this > might be a good long term goal, but for now explaining what goes where is > done reasonably well by the individual plugin docs. Actually, just unifying the design of certain properties, like communication will help greatly.
> > 3) No mid-level repository > > A corporate environment wants three levels of repository, not > > I have no problems using 2 remotes (one intranet, one internet) + a per-user > local for our environment. > Deployments are all done to the intranet version, which are controlled by > separate properties at the moment. Finding this info out is difficult. What properties should be used to jar:deploy to one repo and not the other? > > 5) Assumptions from OSS > > Too much assumes the OSS model, where deployments are via > > scp/ssh. A corporate environment will use file copies far > > more often. I suggest that each place where communication > > takes place should use a uniform definition of communication. > > I think you are assuming a lot about a typical corporate environment :) I > would think most have separate networks and machines for building, > deploying, developing, and they have to get around either by ftp or ssh. > Both are available in the aritfact plugin, as well as file. Obviously you work for companies with lots of money. I would suggest that there are more places around the 100 developer mark than the 1000 developer mark. And the smaller ones don't have dedicated networks for building and deploying! Anyway, if the artifact plugin is the solution, thats great, although it is unclear from the docs as to how that plugin is to be used. I assume the idea is that it works behind the scenes, defining the communication stuff and called by other targets.... > > 7) Plugin documentation > > There is lots of documentation in terms of pages, but often > > very little real information of value. The plugin pages are > > often very weak. I suggest some redesign is needed. > > Volunteering? :) Sadly, Jakarta Commons is a full time occupation. > > 8) Getting started/User guide are too complex > > The Maven concept isn't that hard really. But the > > documentation makes it seem hard. A document that says how > > you should layout your files and what the 5 or 6 basic plugin > > calls are would make a great difference. It should also link > > to other docs for more info. > > Fair comment. Often it is better to get someone new in to write these sorts > of docos as they are more in tune to what is needed starting out (I've > forgotten after just 8 months...) If at the end of this I get a chance, I just might write a draft. But don't bank on that. > > - copy the zips to a file location of my choosing > > Does maven.repo.central=file:///path/to/new/repo work? > Otherwise you may need to go to maven.xml to do this as a goal after "dist" But I don't want the zip files in the repository. I want to use a different directory and only put the jar file in the repository. Maybe I'll have to review that at my end. > Thanks for sharing your experience Stephen, its rare to see something > written well and 99% anti-inflammatory about what may have been a > frustrating experience. I hope I've cleared a few things up for you. I think thats my OSS knowledge. I'll try the scm and using a remote shared repository and see what happens. Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
