I was dealing with one drl earlier , now I want multiple in the same package.Can anyone please guide me step by step how to do this?
What I have tried yet:
I have specified package in changeset file using webdav
<add>
<resource source="address/guvnor/org.drools.guvnor.Guvnor/webdav/packages/Name" type="DRL"/>
</add>
In my code m using
ResourceFactory.newClassPathResource("changeset.xml").
Where am I doing it wrong? Do I have to build or deploy package or somethng else in guvnor?
I have done it in another way now instead of specifying package I specified all the files name in changeset:
add>
resource source="address/guvnor/org.drools.guvnor.Guvnor/webdav/packages/Name/File1.drl" type="DRL"/>
resource source="address/guvnor/org.drools.guvnor.Guvnor/webdav/packages/Name/File2.drl" type="DRL"/>
/add>
The main issue was when knowledge base was forming from different drl files , rules name were same in them.
Related
I am currently working on changing our codebase to use Nuget. As part of the process the copying of ressources to the output directory should be moved from postbuild events in the projects to the files tag in the .nuspec file.
For the particular project the ressource was called Resources.resx and is renamed to something more specific during the copy (yes I know great programming - not mine and not my place to change it).
Is it possible to change the filename using the file node in nuspec or do I need to keep a postbuild in this case?
My attemp of renaming it with the target property fails:
< file src="foo/bar.resx" target="foo/foobar.resx"/>
creates the following output:
"foo/foobar.resx/bar.rex"
I found a familiar problem on github but it was rejected due to being posted on a dead branch and not trying to rename a file but change its type.
https://github.com/NuGet/Home/issues/2019
Thanks for the help
This functionality is not built into NuGet. The only conceivable way to do this would be to implement a powershell script (install.ps1) that would handle the rename of both the file and the csproj.
Late to the party, but this looks like it could work:
From: https://learn.microsoft.com/en-us/nuget/reference/nuspec
Renaming a content file in the package
Source file:
ie\css\style.css
.nuspec entry:
<file src="ie\css\style.css" target="Content\css\ie.css" />
Packaged result:
content\css\ie.css
Edit:
I found this post (https://stackoverflow.com/a/45601252/182888) where it says:
Note: The File extension in src and target must match or the specified target will be treated like a directory.
So keep that in mind or it might trip you up.
I am attempting to migrate a CCNET based build script to a F# Fake based one. I am having difficulty understanding how to modify the RestorePackages method to honor the NuGet.config file that instructs NuGet to place the packages in a folder named 'External' several layers deep in our repository.
NuGet.config Example:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositoryPath" value="Code\DotNet\External\" />
</config>
</configuration>
NuGET CCNET Example:
<exec executable="Tools\NuGet\nuget.exe">
<buildArgs>restore $[$CCNetWorkingDirectory]\Code\DotNet\Web\All.sln</buildArgs>
</exec>
In the above examples I am simply telling NuGet to restore packages for all the projects in the solution. This honors the settings in NuGet.config.
NuGet Fake Example:
Target "RestorePackages" (fun _ ->
RestorePackages()
)
However, calling RestorePackages() does not honor NuGet.config (as this method simply uses default parameters) and so my packages are updated in the wrong location.
Ideally I would like to instruct RestorePackages to look specifically at the Visual Studio solution file as I do with CCNET. Is this possible?
If that is not doable, I would like to instruct RestorePackages to honor the settings in the NuGet.config file.
However, if neither are doable, I'll need to be able to override the Output path. Unfortunately, I am having difficult time understanding the documentation and I am not sure how to construct this.
I have been reading over the documentation and the source code for the RestorePackagesHelper module and found that it does not support what I want to acheive, at least not directly due to two limitations.
Limitation 1: No Solution File Support - The current RestorePackage implementation uses the NuGet Install Command which does not support passing in a solution file. In order to pass in a solution file one would need to use the NuGet Restore Command. Therefore this is not a direct Fake equivalent for what the CCNET snippet listed in the question.
Limitation 2: No ConfigFile Support - Further, the RestorePackageParams type does not have a ConfigFile parameter so I am unable to specify the ConfigFile that I want to use in for the NuGet restoration.
These are current limitations of Fake. Not NuGet.
A Reasonable Solution - However, I can achieve a similar effect with Fake by scanning for all packages.config files in a given directory and calling RestorePackage for each one; each time specifying the OutputPath as shown below.
Fake NuGet RestorePackages Example
Target "RestorePackages" (fun _ ->
!! "./**/packages.config"
|> Seq.iter (RestorePackage (fun p ->
{ p with
OutputPath = "./Code/DotNet/External"}))
)
We're using nugetter to make a nupkg as part of our build process for a solution that only builds occasionally, and that we want to distribute in the future. We also want to use this package in other solutions we have. So far, I've been able to generate a package that we can install. Now, I want to be sure that this package updates its version every time it's built so we can update the package easily. I'm thinking that using the build number would be a good way to do this, but I'd be willing to use just about any incrementing scheme if I don't have to start writing a powershell script to update the nuspec for package on every build.
Is there a way to do this automatically in nugetter?
If not, is there something easier than modifying the nuspec with powershell?
We're trying to do the same thing. NuGetter ships with a build process template that builds on top of TfsVersioning. Are you using that already? If so, all you have to do is add a special element for your NuGet package ID to the VersionSeed.xml file.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VersionSeed>
<Solution name="Your Solution Name">
<!-- This is the pattern used to replace the AssemblyVersion value. -->
<AssemblyFileVersionPattern>1.0.J.B</AssemblyFileVersionPattern>
<!-- This is the pattern used to replace the AssemblyVersion value. -->
<AssemblyVersionPattern>1.0.0.0</AssemblyVersionPattern>
</Solution>
<NuGetPackage id="Your NuGet Package ID">
<!-- This is the pattern used to replace the version attribute in the NuSpec file. -->
<VersionPattern>1.0.J.B</VersionPattern>
</NuGetPackage>
</VersionSeed>
It's not a very well documented NuGetter feature, but it's in their help file somewhere.
Also, you still have to set the <version> attribute in the NuSpec file. Currently, I force it to 0.0.0.0 because it is overridden by the build process anyway. Removing the <version> element completely seems to always result in a crash.
Has anybody been able to successfully use the Replace dependency filter in the CQ5 Package Manager to uninstall/delete old code? http://dev.day.com/docs/en/crx/current/how_to/package_manager.html
I've recently restructured my directories and I'm trying to find an easy way to uninstall the old branches.
In other words, I am currently working with:
/apps/myproject/old_directory
but want to transition to:
/apps/myproject/new_directory
Like I said, I tried setting the Replace Dependency Filter with the old package name. It appears to be working because it says "Replaces my_packages:oldPackage:1" which is a valid link. However, running the install does nothing to the pre-existing code base.
I realize that I can just uninstall the original package manually, but this will be added to the Package Share, so I'd like to ensure that any current users can just install the upgrade without worrying about unused code.
I'm currently using CQ 5.4
To remove a content branch using a CQ5 package you need a package:
with a filter definition pointing at the content branch to be removed
without any content in that branch
In other words, you can create an empty package with filter definition pointing to areas you want removed. You can do that either on an empty instance, or by manually editing the filter.xml entry to something like:
<?xml version="1.0" encoding="UTF-8"?>
<workspaceFilter version="1.0">
<filter root="/apps/myproject/new_directory"/>
</workspaceFilter>
Installing such package wipes content under the specified path(s). This operation cannot be undone. This works consistently on all CQ5 versions.
We have two solutions: foo.sln and bar.sln
I have a common library that is used by both foo and bar. Common.csproj is used by both.
If I open foo and update nuget references, all references in Common.csproj point to foo/packages/. If I later open bar and update nuget references, all references get set to those in bar/packages/. Naturally, this pisses off the foo team as it can cause incompatibilities between Common.csproj and Foo-specific stuff like Foo.Data.csproj, which still points to foo/packages.
There must be some obvious solution other than: "create a huge solution that contains all your projects, and if you need to touch nuget, only do it from that solution."
There seems to be an issue on codeplex, (the top voted issue, incidentally), but evidently I'm too thick to understand how this issue is resolved. Can someone explain how to fix this?
This problem preceeds NuGet. If you have a project referenced in two solutions, and change assembly references in the project when it is open in one solution, of course it will change the reference path for that project when it is open in the other solution. This has always been the case, regardless of how the reference was changed (with NuGet or otherwise).
But the real problem is that when you do an update, the updated packages do not appear in the foo/packages directory right?
The simple solution is to move Common.csproj into a solution of its own, with its own references, packages folder, build and release process. Then create a NuGet package of your own with any relevant dependencies built into it. Then you can install your Common package into both Foo and Bar and then the Foo team is free to update to the latest version of Common as and when they are ready.
The main argument that I have heard against this is that you might want to step through the Common code while debugging, but this is no longer an issue with Visual Studio 2010.
The fundamental question you need to ask is who owns Common.csproj? Is it the Foo team or the Bar team?
I fix the problem by changing the hint path in the project fil to contain the $(SolutionDir) variable:
Reference Include="EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
<HintPath>$(SolutionDir)packages\EntityFramework.6.1.3\lib\net40\EntityFramework.dll</HintPath>
Why not have common.csproj as a separate assembly that you reference and has its own dependencies rather than those of the solution its in.
By doing that you protect common from either foo or bar updating the referenced package and breaking it.
In our case, many developers and solutions with tfs, and multiple versions of it in different branches ...
and each developer their understanding of where the source must lie.
Relative path in this case not work, absolute paths in case of coincidence disc are replaced by relative and also did not work.
Our solution consists in getting rid of the relative path.
You can do it if you put NuGetPackages on a separate disk.
like so:
net use /persistent:yes p: \\localhost\C$\NuGetPackagesDiskFolder
Any folder name you wont
After that, you can specify realy absolute path in the NuGet.Config
<config>
<add key="repositorypath" value="p:\NuGetPackages" />
</config>
<packageRestore>
<add key="enabled" value="True" />
</packageRestore>
After all delete suo files
ps: Will a little trouble with the alteration of exsisting solutions, if they live in sourcecontrol
easiest way is to correcting the path to p:\NuGetPackages in each .csproj
Otherwise it is necessary to reinstall all the refs and manually undo all packages.config marked as deleted in the sourcecontrol