Ivy and Snapshots (Nexus) - build

I'm using ant, ivy and nexus repo manager to build and store my artifacts. I managed to get everything working: dependency resolution and publishing. Until I hit a problem... (of course!).
I was publishing to a 'release' repo in nexus, which is locked to 'disable redeploy' (even if you change the setting to 'allow redeploy' (really lame UI there imo). You can imagine how pissed off I was getting when my changes weren't updating through the repo before I realised that this was happening.
Anyway, I now have to switch everything to use a 'Snapshot' repo in nexus. Problem is that this messes up my publish. I've tried a variety of things, including extensive googling, and haven't got anywhere whatsoever. The error I get is a bad PUT request, error code 400.
Can someone who has got this working please give me a pointer on what I'm missing.
Many thanks,
Alastair
fyi, here's my config:
Note that I have removed any attempts at getting snapshots to work as I didn't know what was actually (potentially) useful and what was complete guff. This is therefore the working release-only setup.
Also, please note that I've added the XXX-API ivy.xml for info only. I can't even get the xxx-common to publish (and that doesn't even have dependencies).
Ant task:
<target name="publish" depends="init-publish">
<property name="project.generated.ivy.file" value="${project.artifact.dir}/ivy.xml"/>
<property name="project.pom.file" value="${project.artifact.dir}/${project.handle}.pom"/>
<echo message="Artifact dir: ${project.artifact.dir}"/>
<ivy:deliver
deliverpattern="${project.generated.ivy.file}"
organisation="${project.organisation}"
module="${project.artifact}"
status="integration"
revision="${project.revision}"
pubrevision="${project.revision}" />
<ivy:resolve />
<ivy:makepom
ivyfile="${project.generated.ivy.file}"
pomfile="${project.pom.file}"/>
<ivy:publish
resolver="${ivy.omnicache.publisher}"
module="${project.artifact}"
organisation="${project.organisation}"
revision="${project.revision}"
pubrevision="${project.revision}"
pubdate="now"
overwrite="true"
publishivy="true"
status="integration"
artifactspattern="${project.artifact.dir}/[artifact]-[revision](-[classifier]).[ext]"
/>
</target>
Couple of ivy files to give an idea of internal dependencies:
XXX-Common project:
<ivy-module version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd">
<info
organisation="com.myorg.xxx"
module="xxx_common"
status="integration"
revision="1.0">
</info>
<publications>
<artifact name="xxx_common" type="jar" ext="jar"/>
<artifact name="xxx_common" type="pom" ext="pom"/>
</publications>
<dependencies>
</dependencies>
</ivy-module>
XXX-API project:
<ivy-module version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd">
<info
organisation="com.myorg.xxx"
module="xxx_api"
status="integration"
revision="1.0">
</info>
<publications>
<artifact name="xxx_api" type="jar" ext="jar"/>
<artifact name="xxx_api" type="pom" ext="pom"/>
</publications>
<dependencies>
<dependency org="com.myorg.xxx" name="xxx_common" rev="1.0" transitive="true" />
</dependencies>
</ivy-module>
IVY Settings.xml:
<ivysettings>
<properties file="${ivy.project.dir}/project.properties" />
<settings
defaultResolver="chain"
defaultConflictManager="all" />
<credentials host="${ivy.credentials.host}" realm="Sonatype Nexus Repository Manager" username="${ivy.credentials.username}" passwd="${ivy.credentials.passwd}" />
<caches>
<cache name="ivy.cache" basedir="${ivy.cache.dir}" />
</caches>
<resolvers>
<ibiblio name="xxx_publisher" m2compatible="true" root="${ivy.xxx.publish.url}" />
<chain name="chain">
<url name="xxx">
<ivy pattern="${ivy.xxx.repo.url}/com/myorg/xxx/[module]/[revision]/ivy-[revision].xml" />
<artifact pattern="${ivy.xxx.repo.url}/com/myorg/xxx/[module]/[revision]/[artifact]-[revision].[ext]" />
</url>
<ibiblio name="xxx" m2compatible="true" root="${ivy.xxx.repo.url}"/>
<ibiblio name="public" m2compatible="true" root="${ivy.master.repo.url}" />
<url name="com.springsource.repository.bundles.release">
<ivy pattern="http://repository.springsource.com/ivy/bundles/release/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
<artifact pattern="http://repository.springsource.com/ivy/bundles/release/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
</url>
<url name="com.springsource.repository.bundles.external">
<ivy pattern="http://repository.springsource.com/ivy/bundles/external/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
<artifact pattern="http://repository.springsource.com/ivy/bundles/external/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
</url>
</chain>
</resolvers>
</ivysettings>

w00h00t.
(There's something cathartic about asking the world for help. Usually you fix the problem much faster, even without a response).
Anyway, for the interested it came down to a couple of things:
a) the addition of -SNAPSHOT to all revisions. This involved forking a second ivy.xml -> ivy.SNAPSHOT.xml and referencing that explicitly in the ivy ant tasks.
b) given that this is a manual addition I had to go through my entire tree of build files and provide parallel paths for release and snapshot flows. This, in my opinion, is lame. But, as I guess we're extremely unlikely to invent any other type of flow, this probably won't bloat, and 2 parallel flows is where it will stay.
c) I specified various hints to ivy to check for updates to the snapshots. e.g. checkUpdated="true" and changePattern=".*-SNAPSHOT" on the resolver. And the addition of
<modules org="myorg" name=*" resolveMode="dynamic" />
Still, it'd be nice if there had been automatic integration with snapshot stuff. A bit of (optional) cleverness on the part of ivy. Let's face it, maven repos like nexus ARE really useful and I'm certainly using ivy only to get round maven's crappy build process. I like using nexus.
Anyway. If anyone ever wants to question further on this, feel free.

I'm not sure if this would help with the problem of having 2 sets of configurations, but at least the build.xml would be a little bit simpler.
You can define the revision attribute on the info element in ivy.xml as ${project.revision}.
You can then omit the revision="${project.revision}" attributes on ivy elements in build.xml.
See my answer on this another question for example:
https://stackoverflow.com/a/8853823/1148030

It should be noted, the only necessary step is to include the '-SNAPSHOT' to revision when publishing to Nexus. The other steps listed in the answer are optional/improvements. To pull the published item down, you need to add '-SNAPSHOT' to the revision as well.

Related

Veins: How to verify if rerouting is using user set algorithm

I'm using veins 4.6 and trying to evaluate the change in emissions due to different routing protocols. By exploring SUMO site I have managed to set base for the experiment. For now I'm using veins demo application with minor configurations changes. Here is content of my erlangen.sumo.cfg file:
<?xml version="1.0" encoding="iso-8859-1"?>
<configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://sumo.sf.net/xsd/sumoConfiguration.xsd">
<input>
<net-file value="erlangen.net.xml"/>
<route-files value="erlangen.rou.xml"/>
<additional-files value="erlangen.poly.xml"/>
</input>
<time>
<begin value="0"/>
<end value="400"/>
<step-length value="1"/>
</time>
<routing>
<routing-algorithm value="CHWrapper"/>
<device.rerouting.probability value="1"/>
</routing>
<emissions>
<device.emissions.probability value="1"/>
</emissions>
<report>
<no-step-log value="true"/>
</report>
<gui_only>
<start value="true"/>
</gui_only>
<output>
<fcd-output value="erlangen.fcd.xml"/>
<emission-output value="erlangen.emission.xml"/>
<tripinfo-output value="erlangen.trip_info.xml"/>
<vehroute-output value="erlangen.route_followed.xml"/>
<summary value="erlangen.summary.xml" />
</output>
</configuration>
Routes file (erlangen.rou.xml) content is as follows:
<routes xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://sumo.dlr.de/xsd/routes_file.xsd">
<vType id="passenger" vClass="passenger" accel="2.6" decel="4.5" sigma="0.5" length="2.5" minGap="2.5"
maxSpeed="120" guiShape="passenger/sedan" color="1,0,0" emissionClass="HBEFA3/LDV_G_EU4">
<param key="has.emission.device" value="true"/>
<param key="has.rerouting.device" value="true"/>
<param key="device.fcd.probability" value="1"/>
</vType>
<flow id="flow0" type="passenger" from="3013106#1" to="29900564#1" begin="0" period="3" number="30" />
erlangen.net.xml is unchanged and in omnetpp.ini I have changed *.connectionManager.maxInterfDist from 2600m to 100m only.
Using these configurations I have ran the simulation using A* and CHWrapper algorithm but output of both is ditto copy. In below image it is visible that node 25 - 29 followed a different path after rerouting, but these are same in both cases.
Tripinfo results are given below, as discussed here "tripinfo_rerouteNo" clearly shows that nodes have been rerouted.
Now following is revolving in my mind:
Are routing algorithms applied successfully (set in erlangen.sumo.cfg) or in both cases default Dijkstra was used?
Routing algorithms applied successfully but results are same because network was not congested enough / don't have enough alternate paths to follow. So I should have change network, with multiple accident count etc.
I'm not getting how rerouting is working here.
I'm stuck here, any directions will be highly appreciated.
It is not easy to say from the outside which routing algorithm has been applied, but I would assume 2. is the correct solution. The different algorithms are basically different in the way they can handle dynamic changes to the edge weight vs. the calculation speed but in most cases they should give the same result. You might wish to try the scale option to increase traffic easily or set device.rerouting.period to a value like 10 (seconds) to enable periodic rerouting of the vehicles to see more effects. Also setting weights.random-factor to a large value can help.
One can verify using a sample network like following:
In my test case I set starting position of vehicles as left most edge bottom lane and destination was upper lane of same edge. No uTurn was implemented therefore vehicles had to pass through junction, and FCD for every algorithm was significantly different.

Google Glass XE 17.3 - Multiple Actions From One Voice Trigger Broken?

One of my pairs of Glass updated itself to XE 17.3 this morning, and now, any Voice Triggers I have defined that are used for more than one activity no longer work. On previous versions, (and I've tested my code on an XE 17.2 pair I have to make sure I didn't break anything today), if multiple activities were set to use the same Voice Trigger, the system would prompt you to select from a list upon hearing that voice trigger. This is expected behavior (in case two applications use the same trigger), and actually was quite useful for creating a sub-launcher for your application (which is what I was using it for...say main launch name -> get a list of activities to choose from within the app, all automatic and handled by the system).
Now, however, if my Voice Trigger is assigned to two or more activities within my manifest, it will show up in the list, but will never trigger when you say "OK Glass - [voice trigger]" (it does still work with taps, however). As I mentioned, I tested the exact same code on a pair running XE 17.2 and it worked fine. I also removed the trigger from all but one activity, and it works on 17.3 when you do that...so the problem is when you have more than one possible activity that handles a given voice trigger.
The way I have my manifest set up seems correct to me (and works on older versions of the firmware):
<uses-permission android:name="com.google.android.glass.permission.DEVELOPMENT" />
...
<!-- one of the activities. this is inside the application element, of course -->
<activity
android:name="com.someapp.MainActivity"
android:label="Option 1" >
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<action android:name="com.google.android.glass.action.VOICE_TRIGGER" />
</intent-filter>
<meta-data
android:name="com.google.android.glass.VoiceTrigger"
android:resource="#xml/voiceinput_main" />
</activity>
<!-- another activity, again inside the application element, sharing the same trigger -->
<activity
android:name="com.someapp.AnotherActivity"
android:label="Option 2" >
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<action android:name="com.google.android.glass.action.VOICE_TRIGGER" />
</intent-filter>
<meta-data
android:name="com.google.android.glass.VoiceTrigger"
android:resource="#xml/voiceinput_main" />
</activity>
And, this manifest works fine on XE 17.2. Anyone know of something that has changed in 17.3 that would break this, or see anything that looks wrong? I know that the <action android:name="android.intent.action.MAIN" /> line isn't necessary, but removing it doesn't fix the problem.
Thanks!
in my case, I change my voice trigger string "all in lower case" thing solved my problem, maybe you could give it a try, custom Voice trigger command XE17.31
This seems to only affect custom voice triggers. I'm seeing the same thing with an app I'm developing where I use "Debug ..." as a trigger to let me do a number of things to reset state or launch test actions.
If you change the trigger to an existing command listed here then it should start working again. If you're using the mechanism in the same way I am, you can probably just pick an obscure existing command to use for testing purposes (I'm using FIND_A_DOCTOR, which seems apropos for debugging purposes).
If you're simply using a custom command as part of normal flow, presumably it will either become an accepted command, or you'll have to switch to an existing command eventually, since the custom commands only work in debugging anyway.

Multi-step config in logback with clojure tools.logging

I'm trying to use a custom appender in a clojure application using logback & clojure tools.logging.
My config looks like this:
<appender name="Sentry" class="net.kencochrane.raven.logback.SentryAppender">
<dsn>some-dsn</dsn>
</appender>
This results in the following runtime error:
The following loggers will not work because they were created during the default configuration phase of the underlying logging system.....
A quick google search turns up a document to use a JoranConfigurator programatically to perform a multi-step configuration, but I actually don't see an exposed method in tools.logging to perform multi-step configuration. Any advise other than modifying tools.logging? Am I missing something obvious? Thanks for your time.
tools.logging doesn't do any configuration of the underlying logging system. In the case of logback it just talks to the logging system via slf4j. The configuration of the actual logging is totally on the logback side.
An easy way might be to use a logback.xml config file and Logback dependencies with clojure/tools.logging. Based on Sentry docs it looks like you need the following dependencies:
[org.clojure/tools.logging "0.3.1" :exclusions [org.clojure/clojure]]
[org.slf4j/slf4j-api "1.7.25"]
[org.codehaus.janino/janino "3.0.7"] ; for conditional config processing
[ch.qos.logback/logback-classic "1.2.3"]
[ch.qos.logback/logback-core "1.2.3"]
[com.getsentry.raven/raven-logback "8.0.2"]
The Sentry docs page also has snippets of Logback XML config that you can use. For MDC attributes, you may want to take a look at Cambium.
here's a simple setup using sentry-java-logback,
with deps:
[org.clojure/tools.logging "0.4.1"]
[ch.qos.logback/logback-classic "1.2.3"]
[io.sentry/sentry-logback "3.2.0"]
and logback.xml:
<!-- Sentry -->
<appender name="SENTRY" class="io.sentry.logback.SentryAppender">
<encoder>
<pattern>${defaultPattern}</pattern>
</encoder>
<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
<level>ERROR</level>
</filter>
<options>
<dsn>https://........</dsn>
<release>1.0.0</release>
<serverName>ABCDE</serverName>
<environment>production</environment>
</options>
<minimumBreadcrumbLevel>DEBUG</minimumBreadcrumbLevel>
</appender>
<!-- ....THIS MIGHT CHANGE.... -->
<root level="DEBUG">
<appender-ref ref="STDOUT"/>
<appender-ref ref="SENTRY"/>
</root>
you can read more on Sentry docs

ColdFusion 9 Solr: Can't create/update/refresh collections

I've been having some issues with my Solr collections, and out of frustration I decided to delete all the folders and start from scratch. I did not remove them via CFAdmin, first.
After some searching, I read where someone suggested copying the contents of the /solr/core0 folder into the collections folders under /ColdFusion9/collections. This will at least make them appear in CFAdmin. However, when trying to index the collection(s), I get the following error:
ERROR unknown_field_author ERROR unknown_field_author request:
http:localhost:8983/solr/dtrparti/update?commit=true&waitFlush=false&waitSearcher=false&wt=javabin&version=1
Is this recoverable without having to re-install ColdFusion 9 from scratch?
Thank you,
^_^
YES! IT IS! According to http://www.elliottsprehn.com/cfbugs/bugs/83331, if you add the following to all affected collection/conf/schema.xml:
<field name="author" type="text_ws" indexed="true" stored="true" required="true" />
.. it will now index.
^_^

Multiple artifacts of the module in Ivy

I would like to retrieve jar to a specific folder(like lib) by ivy, below is my retrieve definition in the build.xml:
<ivy:retrieve pattern="lib/[artifact].[ext]" conf="webInfLib" />
And the definition of my ivy.xml like below:
<ivy-module version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd"
xmlns:m="http://ant.apache.org/ivy/maven">
<info organisation="xxxx" module="xxxx" status="integration"/>
<configurations>
<conf name="webInfLib" description="add jar to web-inf/lib folder"/>
</configurations>
<dependencies>
<dependency org="org.springframework" name="spring-beans" rev="2.5.5" transitive="false" conf="webInfLib -> default"/>
<dependency org="net.sf.json-lib" name="json-lib" rev="2.3">
<artifact name="json-lib" type="jar" m:classifier="jdk15"/>
</dependency>
</dependencies>
</ivy-module>
But it always throws:
impossible to ivy retrieve: java.lang.RuntimeException: Multiple artifacts of the module xxxxxx are retrieved to the same file! Update the retrieve pattern to fix this error.
I have read some similar question and their suggest to change the retrieve pattern to a more complex one. I try something like "[artifact]-revision.[ext]", but not help. And when I execute "ivy.resolve", it work fines. Is there any suggestion about this issue?
The retrieve pattern is the problem that's true.
You are trying
[artifact]-[revision].ext
so I would imagine the binary jar and the source jar would be both written on the same location for any arbitrary dependency. But if you add something unique to the case that you are having
[artifact]-[revision](-[classifier]).[ext]
In the case of a source or doc, the classifier would have a value and therefore would have a different name. In case of no classifier (like the case of the binary compiled jar) there won't be any classifier and this is dealt with by the parentheses ( )