it's just a two step process to deploy, and there's an up-to-one-hour sync to live delay. I think liit is still deploying the plugin snapshot docs, but the main site is up. Anyway, the 1.2 docs should be fine for normal use.
- Brett On 21/01/2011, at 9:59 PM, Henning Gross wrote: > Actually the plugins-link is dead there as well... > Or am I the only one with this problem? > > Zitat von Adelita Padilla <[email protected]>: > >> >> >> I've deployed a more updated documentation here -> >> http://incubator.apache.org/npanday/docs/1.3-incubating-SNAPSHOT/index.html >> >> >> Thanks, >> >> -- >> >> liit >> >> >> ----- "Henning Gross" <[email protected]> wrote: >> >>> Zitat von Brett Porter <[email protected]>: >>> >>> > >>> > On 21/01/2011, at 9:52 AM, Henning Gross wrote: >>> > >>> >> Can anyone gelöscht me, why there are npanday plugins for install >>> >>> >> and deploy? I think it would be good to use standart maven plugins >>> >>> >> whenever possible. And in this case i do not see a reason why not >>> >>> >> simply put them in the lifecycle. They have less bugs and do the >>> >> job pretty good. >>> > >>> > I agree! https://issues.apache.org/jira/browse/NPANDAY-233 >>> > >>> > They still have a small amount of custom functionality that we're >>> > trying to remove by streamlining the rest of the code. >>> > >>> > We'd welcome a patch :) >>> >>> Unfortunately I have exams right now and my company wont let me do it >>> >>> in the worktime. Also I dont see test cases in the sources and I dont >>> >>> know much about all the project types build with npanday. Thats the >>> reason why I dont feel confident about moving functionality. For me, >>> >>> install-plugin could simply be removed as the maven plugin does all i >>> >>> need. >>> Also do the clean, deploy and release plugins. Maybe you should at >>> least remove the plugins from the lifecycle. Then people can choose >>> whatever plugins they want to execute during those phases, either >>> maven or npanday. >>> >>> > >>> >> Actually the npanday install plugin has a bad bug deleting bin >>> >> folder making it impossible to release a dll using vs standart >>> >> build dir. >>> > >>> > Do you have an issue for that? >>> >>> I am sorry but I havent filed one as I only just found it yesterday >>> and I was in a hurry. I have tracked it down though. Its in >>> components/dotnet-artifact/src/main/java/npanday/artifact/impl/ArtifactInstallerImpl.java >>> which is called by >>> install-plugin. >>> There is a method called deleteTempDir(). This method contains these >>> lines: >>> >>> File binDir = new File(pomDir, "bin"); >>> >>> try >>> { >>> FileUtils.deleteDirectory(binDir); >>> >>> As you can see there is a string "bin" hardcoded. From pomDir, the >>> folder bin is exactly what visual studio uses as target folder. >>> WSPBuilder does expect dlls to be stored there - that is why we need >>> >>> to use the bin folder too. >>> I cant see why the ArtifactInstaller should do a clean job. >>> If this is about cleaning up the stuff ArtifactInstaller needed as >>> temp files, the artifact should use something like >>> maven.build.dir/temp. If this is changed im fine with deleting the >>> folder. I dont think its nessecary though. The clean plugin will >>> delete the build.dir anyway. I think the hardcoded /bin folder is >>> something that is here by mistake (maybe something the developer tried >>> >>> during debug?). >>> As I said, I need the bin folder to remain to be able to release the >>> project. >>> >>> > >>> >> Btw... anyone holds a plugin reference? Codeplex is down and >>> >> incubator links broken... >>> > >>> > Sorry about that... we're deploying the latest snapshot now, but in >>> >>> > the mean time I've moved the old docs over: >>> > http://incubator.apache.org/npanday/docs/1.2/plugins/index.html >>> > >>> >>> Actually, that link doesnt work either... >>> >>> Regards, Henning. >> > > -- Brett Porter [email protected] http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
